Лидеры

Вот, например, схема указателя авиагоризонта АГБ-3: Как видно, корпус используется как минус питания подсветки, а минус питания усилителей сервосистем подается отдельным проводом. А вот кусочек схемы указателя РВ-5М радиовысотомера А-034 (A14, A15 - диодные мосты внутреннего преобразователя напряжения): Как видно, тут корпус используется как минус питания 27 В (это питание используется только для питания электромагнита выпадающего флажка отказа, реле и выдачи наружу сигнала "Высота опасная" для запуска звуковой сигнализации). Вот кусочек схемы индикатора ИДР-1 дальномера СД-67: Тут отдельные контакты для -27 В и корпуса, которые оба внутри посажены на корпус прибора.

По мне, так нет и не было на уровне платы никакого жаргона. Всегда пляшут от названий источника питания. +, -(общий); +,-, общий; Корпус. Открываем ТУ на Наш какой нибудь МДМ и берем за основу. А вот у авиации действительно много жаргонизма. Корпус/обрыв, это с моей точки зрения - жаргон. И подразумевает он как по мне вполне конкретную схемотехнику (так сказать память разъема носителя). Например обрыв. На вход разъема носителя подается 0В. Вход подтянут резистором к питанию платы. Разорвали связь между разъемами - прошла команда обрыв. Если речь о 27В/0В - то тут ОВ - это жаргонный корпус. А может он и соединен с корпусом, Кто знает. Есть ведь еще и СВЧ оборудование , а там железо устройства - это его общий может быть. Поэтому, если есть клемма заземления - Общий узлов соединяют с ней в одной точке, если этой клеммы нет - все эти жаргоны типа корпус - это общий. Простой метод изоляции команды - Оптрон. На выходе сигнал с общим платы. Посмотрите документ HI-8429 AN-800_New HOLT INTEGRATED CIRCUITS. Зайдите на сайт http://www.elcus.ru/. Они в полный рост делают контрольное оборудование для авионики.

Попробуйте найти координаты диодников в НИИПП г.томск. Там классные смесители делают. https://mmic.niipp.ru/ic/subcat/11 . Мы проводили тесты по параметрам и их смесители находятся на уровне AD, и Hittite. Думаю и по одиночным смесительным диодам они смогут подсказать...

Сами STM свои МК делят на высокопроизводительные, широкого применения, малопотребляющие и беспроводные. Как их воспринимают потребители - неопределенный вопрос.

Какой цикл? при чем здесь цикл? Задача говорит системе: "я буду спать до того как произойдет такое-то событие". Шедулер усыпляет задачу и передает ей снова управление только тогда, когда указанное событие произойдет. Если в этот момент выполняется задача с большим приоритетом- то шедулер подождет, пока это высокоприоритетная задача отдаст управление шедулеру, и наконец-то запустит эту задачу. Никаких циклов и поедания ресурсов в этой ожидающей задаче нет. А если Вам нужно просто задержку организовать- так это опять же через RTOS: задача говорит системе "разбуди меня через столько-то системных тиков", и все. Если ожидание меньше системного тика- то задача взводит аппаратный таймер и из прерывания этого таймера посылается сигнал. А задача говорит системе "разбуди меня, когда пришел сигнал от таймера". И Вы как-то зациклились на расходе ОЗУ. Вам действительно настолько критичны те 64 байта на задачу плюс стек, и разово 236 байт на шедулер, которые нужны, например, freeRTOS? Scheduler Itself: 236 bytes (can easily be reduced by using smaller data types). For each queue you create, add: 76 bytes + queue storage area For each task you create, add: 64 bytes (includes 4 characters for the task name) + the task stack size. Про стек на задачу: это зависит. У меня, например, 128 элементов (128*4 байт), но тут можно и оптимизировать.

Это как вообще??? В топку такие считыватели))) Мы лет 5 использовали копеечную плату для мифаре карточек - RC-522, работает как танк, в жару, сырость, холод))) Если сырость, просто нужно облить компаундом...

Фокус не удался пока что ... Попытка залить .elf приводит к ошибке ERROR: XTENSA Unsupported exception architecture configured

дык, оно всегда приятно, когда простые задачи решаются не менее простыми и очевидными решениями без "магических" чисел и бессмысленной "гуру"-оптимизации на абсолютно ровном месте ))

...и таким образом - дважды прибавил ошибку преобразования. На кой??? На кой это надевание трусов через голову? У вас процессор - с FPU или нет? Если с FPU, то почему просто не делать всё во float? Если процессор без FPU, то почему не сдвинуть точку в любую удобную для вычислений позицию 2^n (как советовал выше kolobok0), и не проводить все вычисления в fixed point? Ведь элементарно же все операции можно в fixed point сделать: u32 x = (u32)(458.5 * (1u << 22)); //формат: uq10.22 u32 y = (u32)(385.3 * (1u << 22)); //формат: uq10.22 ... x += (u32)(0.1 * (1u << 22)); //формат: uq10.22 ... u32 result = (u32)(((u64)x << 22) / y); //формат: uq10.22 Здесь у x, y и result точка находится в позиции 1<<22. Но можно выбрать и любую другую, удобную для вычислений позицию точки. Кроме того - в разных местах кода позиция точки может быть разной. Оптимальная позиция точки выбирается исходя из диапазона значений аргументов, диапазона промежуточных и конечных результатов и требуемой точности вычислений. Математика начальных классов школы. PS: Именно отсюда видно - почему во многих случаях оптимальнее позицию точки держать в двоичных разрядах, а не в десятичных. О чём я писал выше. И от чего у некоторых персонажей так подгорало.

Да уж... ведь "миллион мух не могут ошибаться". Если они куда-то летят, то видимо там что-то вкусное лежит.

А вот и "традиционное" хамство, ожидаемо.