gerber

Это, случайно, не для сбора данных с датчиков метеостанций по радиоканалу?

Есть ещё "База Электроники": http://elbase.ru/

Ну, в принципе, если у проводной мыши отрезать провод - она станет беспроводной.

Ставить супервизор с выходом open-drain.

Довольно вредный совет. Во-первых, STM32 уже имеет на борту супервизор питания, удерживающий в сбросе процессор до нужного уровня питания. Во-вторых, линия RST# в определенных случаях (например, при программном сбросе) RST# становится выходом и формирует импульс сброса, которому может помешать внешний супервизор.

Дык на то и опкод, по которому процессор декодирует инструкцию. После декодирования опкода процессор "понимает", что это, к примеру, MOV Rx, #immediate, пересылка immediate value в регистр, в этом случае, часть бит интерпретируется как номер регистра-приемника, а часть бит как собственно immediate value. Другой опкод будет по-другому интерпретировать биты инструкции, и вместо immediate value там окажется, к примеру, смещение относительной адресации.

В теле опкода инструкции, например, из 32-бит опкода часть бит (например, 12 бит) может быть выделено под immediate value, в этом случае с помощью такой инструкции можно работать с константным числом от 0 до 4095, или -2048...2047, если трактуется как знаковое число. В тех архитектурах или режимах, где инструкции короткие, скажем, 16-битные, под immediate value может быть выделено совсем мало бит, в этом случае такие инструкции используются в совсем простых случаях, скажем, для инкремента (a++). В остальных случаях используется смещение относительно PC, и константа забирается с адреса, лежащего в окрестностях текущего выполнения кода.

В опкоде инструкции же, это и есть immediate value.

В таких (простых) случаях компилятор использует инструкции, работающие с immediate value, или же располагает константы в теле кода, где-то "неподалеку" от текущего адреса выполнения (регистр PC) с near-доступом относительно PC. Таким образом, расходования области констант не происходит, к тому же это намного быстрее, чем "лазить" в другой сегмент памяти.

Возможно, cервер интерпретирует число как float 16-bit, с соответствующей потерей точности.

В QNX через Dev-менеджер, в Win - через диспетчер Plug-and-Play (PnP), в Linux - через udev.

stm8

ИМХО, в такую сумму только трафареты и поместятся. Реальный ценник на монтаж таких плат 50-70 тыр.

Не нужно мерять периоды, все гораздо проще - нужно взвести прерывание по фронту, в его обработчике стартует таймер на 480 мкс, по истечении которого уровень на линии определяет информационный бит. При приеме преамбулы с такого декодера пойдут одинаковые биты, после чего прием "плавно" перейдет в накопление ключа, которое стартует при приеме первого бита, отличного от преамбулы. Ещё, как правило, такие посылки содержат контрольный бит (четности или др.), таким образом, событие "принят ключ" наступает после цепочки событий "накоплено N битов преамбулы" -> "накоплено 12 бит" -> "совпал бит четности".

Интересный финт оптимизатора, приводящий к ошибке: предположим, что основная часть функций программы контроллера расположена во флэшке, а некоторым функциям предписано директивами размещение в RAM (такое бывает необходимо, если из функции выполняется запись во внутреннюю флэшь контроллера). При отсутствии оптимизации всё работает, а при включенной оптимизации зависает где-то внутри функции, которая должна быть в RAM. Оказалось, что оптимизатор заинлайнил функции, которые должны были быть в RAM, они слились с телом "обычных" функций и разместились во флэшке. А на первый взгляд и не придерешься - сначала отрабатывает компилятор со своей оптимизацией, потом в дело вступает линкер, которому предписано размещение в RAM функций, которых уже нет после прохода оптимизатора...