Программирование микроконтроллеров *

Когда речь заходит о производительности одноплатных компьютеров, чаще всего внимание уделяют процессору, объему оперативной памяти или системе охлаждения. Однако в реальных сценариях использования скорость работы системы очень сильно зависит от накопителя. Именно накопитель влияет на время загрузки ОС, скорость установки пакетов, работу Docker-контейнеров, баз данных, браузера и общую отзывчивость системы.

Сегодня мессенджеры стали одним из основных каналов общения. Но что, если нужно переписываться с корреспондентом, расположенным на расстоянии, измеряемом километрами, а интернет не работает?

Если речь идёт о текстовых сообщениях, помогут каналы связи, созданные с помощью технологии LoRa.

В этой статье мы разберёмся с темой обмена сообщениями через LoRa. Начнём с простого мессенджера, позволяющего обмениваться сообщениями между двумя компьютерами с разъёмами USB под управлением Windows или Linux. Затем перейдём к мессенджеру с  микрокомпьютером Raspberry Pi.

В итоге мы создадим несложную mesh-сеть с ретрансляцией по принципу флуда и TTL-ограничением на микроконтроллерах ESP32-S3-N16R8 и модулях LoRa E22-900T22D. Каждый узел этой сети будет поднимать собственную точку доступа Wi-Fi с веб-интерфейсом чата. Для подключения к узлу и обмена сообщениями достаточно обычного смартфона с браузером. В качестве дополнения сделаем так, чтобы в этой сети можно было работать и с компьютера под Windows, к которому подключён LoRa USB-донгл E22-900T22U.

Java-синтаксис на 8-битных микроконтроллерах? Без виртуальной машины?

Исторически в эмбеддеде правит Си. Но Си — это вечные malloc/free, утечки памяти, выходы за границы массива и дебаг с осциллографом.

Я разрабатываю vm5277 — монолитный тулкит и язык J8B с Java-подобным синтаксисом. Он компилирует строгий ООП-код напрямую в нативный, оптимизированный ассемблер.

Что под капотом:

Управление памятью: через Reference Counting (new без free и без Garbage Collector).

Полиморфизм интерфейсов: спрятан во Flash (без оверхеда в ОЗУ).

Типы данных: встроенный 16-битный примитив fixed (Q7.8) вместо тяжелого float.

Оптимизация: тотальный Dead Code Elimination (в прошивку идет только то, что реально вызвано).

Проект в стадии суровой Альфы. Код открыт на GitHub, десятки примеров (от мигания диодом до драйверов периферии).

Попросил ИИ написать прошивку для платы с экранчиком. Код идеальный: скомпилировался с первого раза, залился без ошибок. А на экране - цветной шум.

Дело не в коде - модель просто не знает вашей платы. Какие пины чем заняты, какая конфигурация тактирования реально заводится, какие вызовы HAL молча не делают ничего: всё это размазано по даташиту на стопицот страниц, вики производителя и вечеру отладки, который вы на это потратили.

И как это решать?

В последние 5 лет, мы разрабатываем устройства с уровнем функциональной безпосности SIL3 (в части встроенного ПО). Это накаладывает кучу ограничений, например, абсолютно запрет на использование не сертифицированных по функциональной безопасности средст, типа Cube, или компилятров GNU и Clang, только сертифицированные средства типа IAR Workbench Function Safety.

Соотвественно для того, чтобы получить как можно больше баллов по функциональной безопасности необходимо иметь как можно больше диагностик, в том числе и диагности CPU. Сами писать диагностику CPU дело довольно трудемкое, поэтому мы используем сертифицированные библиотеки от производителя.

Embedded Swift — это подмножество Swift, предназначенное для работы с низким потреблением ресурсов, что позволяет ему работать в ограниченных средах, таких как микроконтроллеры. Используя специальный режим компиляции, Embedded Swift создает значительно меньшие исполняемые файлы по сравнению с обычным Swift. Хотя это и подмножество полного языка, подавляющее большинство возможностей Swift работает в Embedded Swift точно так же. Дополнительная информация описана в документе «Видение Embedded Swift».

Embedded Swift быстро развивается. После наших обновлений об улучшениях Embedded Swift в Swift 6.3 в конце прошлого года, этот пост описывает ряд дополнительных улучшений, сделанных в предстоящем выпуске Swift 6.4. Вы можете опробовать их уже сегодня, используя снапшот разработки Swift.

Улучшения языка

Embedded Swift продолжает расширять свое подмножество языка, включая все больше аспектов «полного» Swift, что упрощает обеспечение совместимости существующих кодовых баз Swift с Embedded Swift. Многие из этих функций имеют динамический аспект, что означает их влияние на производительность во время выполнения (например, из-за косвенных вызовов) и размер кода (из-за необходимости дополнительных метаданных). Однако это влияние проявляется только там, где эти динамические функции языка действительно используются: код, критически важный к размеру и производительности, может избегать их, например, включив предупреждения в группе диагностики PerformanceHints.

Обобщенная поддержка экзистенциальных (any) типов

«Управление сложностью — сама суть программирования компьютеров.» — Брайан Керниган

Стадия финального тестирования

Мы находились на этапе финального тестирования проекта IoT‑датчика — устройства для умного дома с 128 КБ ОЗУ, которое отслеживает температуру, влажность и качество воздуха. Прошивка прошла все функциональные тесты. Юнит‑тесты: зелёные. Интеграционные тесты: зелёные. Энергопотребление: в пределах спецификации.

Последним требованием был тест непрерывной эксплуатации в течение 72 часов. Мы подготовили в лаборатории двенадцать устройств, настроив их на отправку данных датчиков каждую секунду, и оставили их работать.

Спустя три дня я пришёл в лабораторию, ожидая собрать логи тестирования и завершить проект.

Но вместо этого выяснилось, что все двенадцать устройств аварийно выключились.

В консоли последовательного порта на каждом устройстве была одна и та же ошибка:

[72:14:23] malloc failed: out of memory
[72:14:23] Fragmentation: 45%
[72:14:23] System halted

У меня cкрутило желудок. Проект планировалось выпустить через две недели. Я в точности знал, что произошло, и понимал, что решать проблему будет очень трудоёмко.

Полный гайд по сборке радара для мониторинга присутствия в помещении человека и даже просто его дыхания.

Общий механизм выглядит так: ESP32-S3 измеряет параметры канала Wi-Fi 100 раз/сек, а Raspberry Pi их анализирует, в реальном времени выводя результат в браузере. Эта система обнаруживает абсолютно неподвижно сидящего человека по одному только движению его грудной клетки во время дыхания — без каких-либо камер, датчиков PIR или носимых устройств.

В картине мира, представляемой школьным образованием, существует «слепое пятно» в области принципов проектирования цифровой электроники, между физикой и программированием. Курсы роботики и ардуино это слепое пятно не закрывают, так как сводятся к программированию готовых чипов и их интеграции с сенсорами и актуаторами, то бишь проектированию систем.

Продолжение первой части, в котором я рассказываю, как прошивать наушники на SoC Bestechnic (soundcore, Nothing, CMF) по воздуху, раскрываю секрет загадочного сервиса BESOTA и показываю процесс портирования DOOM на soundcore Life Q35.

Редактор BlocklyKlik разрабатывается для помощи программирования микроконтроллеров на базе Arduino и ESP32 (эту функцию добавим в будущем) с применением блочного функционала создания кода.

Возможно, вы зададите вопрос: "Так есть же Scratch, mBlock, PictoBlox, да и Arduino ide".

Всё верно, они есть, но в ходе последних лет их использования возникли ряд серьёзных проблем:

Год назад на проекте гуманоида с Jetson Orin на борту меня регулярно спрашивали одно и то же. “Можно ли гонять нашу VLA локально, без сети?” VLA это модель. Она берёт кадр и текст и выдаёт команды на приводы.

Я листал документацию, тикеты PyTorch и чужие статьи, а когда разобрался, ответил пересчётом. “Теоретически да, но от кадра до движения выходит 0,84 с. Робот за это время успеет упасть, а пользователь решит, что он завис.”

После того гуманоида ко мне не раз приходили за помощью в проектировании. Чаще это была детекция на 30 FPS на плате за $10 или передовая LLM на устройстве.

Нужна документация, местами китайская, которую приходится гонять через переводчик, и нужны подробные инженерные расчёты. Пиковые тераоперации из даташита почти не двигают задержку от кадра до движения.

В автомобильной электронике есть отдельный класс устройств, которые называются кузовная электроника. Задача таких плат — управление нагрузками. В качестве нагрузки выступают фары, насосы, бензонасосы, нагреватели, клапаны и прочие маломощные исполнительные механизмы.

В данном тексте я покажу как электронные блоки кузовной электроники могут самостоятельно определить подключенную нагрузку и даже регистрировать короткие замыкания.

На фото: один из пользовательских снимков

Наш спутник ударился о небесную твердь ровно в день открытия публичного доступа к нему. Вы, возможно, уже в курсе. Конкретно атмосфера оказалась куда шершавее, чем в прошлый раз, и он спустился пониже и перестал выходить на связь.

К счастью, у нас есть резервный спутник! Из материнского контейнера он вышел чуть позже и выше. Думаю, у него ещё неделя. Так-то мы рассчитывали на несколько месяцев.

И это далеко не всё, что случилось в этой истории.

Вообще, тут две истории, которые сплелись в небольшой ад. Первая — это ожидание и реальность от софта и связи с наземным гридом. Нам пришлось переписывать стек протоколов, потому что в сыром SSH могла дойти половина команды. Например, мы отправляем rm -rf /home/pi/tmp/cache, а приходит rm -rf /home/pi. Это было бы очень забавно.

Очень много приколов с оптимизацией: например, чтобы сделать фотографию не чёрного экрана, надо как-то попасть в Землю. Спутник неуправляемо вращается, двигателя у него нет — поэтому надо дождаться, пока в кадр попадёт планета, и снимать. Так вот, код там прямо из 90-х — камера делает серию из 5 снимков с паузами, а затем основным считается тот JPG, который больше весит. Это значит, что в нём больше значимых пикселей, и это, вероятно, планета.

А, да, и потом американский NORAD перестал давать нам данные о положении спутника, и пришлось стучать в МГУ за матмоделью орбитальных расчётов, которые корректировались по тому, где мы последний раз видели спутник и куда он ушёл.

Итак, наш первый спутник год назад вышел на орбиту и вещал оттуда веб-страницу по радиоканалу. Этот новый спутник, уже с мини-сервером на борту и с доступом по SSH, должен был стать первым полноценным VDS в космосе.

Естественно, всё, что могло пойти не так, пошло не так!

Меня зовут ZolAnd, я - независимый инженер-разработчик embedded-систем в основном для дома и сельской усадьбы. В какой-то момент мне захотелось собрать под одной крышей разношёрстный парк ZigBee-устройств от разных производителей, работать с ним локально, без обязательной привязки к облаку, и при этом иметь возможность не только интегрировать чужие устройства, но и проектировать свои. Так появился проект ZBFun. Эта статья — про то, с какими вызовами я столкнулся, какие решения уже существуют и почему они мне не подошли, и про архитектуру, к которой я в итоге пришёл.

С чего всё началось

Задача звучала просто: хочу python-библиотеку для ZigBee на ESP32-C6. Готовой не нашлось — есть отличный esp-zigbee-lib от Espressif на C, но ничего сопоставимого на Python или MicroPython для этой платформы не было. Значит, писать самому. И тут выяснилась вторая, более фундаментальная проблема. Чтобы написать библиотеку, нужно понимать, что такое ZigBee Cluster Library (ZCL) — стандарт, который описывает, из чего вообще состоит ZigBee-устройство: кластеры, атрибуты, команды, типы данных, зависимости между ними. Официальный документ Alliance — 1213 страниц PDF, написанный для инженеров, имплементирующих стек с нуля, без какой-либо машиночитаемой версии. Ни JSON, ни XML — только текст, рассчитанный на то, что человек прочитает и перепечатает нужное руками. Дальше — хуже. Когда я стал сверять этот текст с реальными SDK и реальными устройствами, обнаружились расхождения. Причём не косметические, а такие, из-за которых устройство просто не будет работать правильно.

В рамках этой статьи я детально расскажу о разработке драйвера шагового двигателя. Я уже много лет держал в голове этот проект и хотел им заняться. Наконец такая возможность появилась: этот проект стал моей дипломной работой.

В предыдущей статье я рассказывал о том, как предоставить удалённый доступ к данным измерений метеостанции с помощью модулей Heltec Automation HTIT-WB32LAF V3, объединяющих микроконтроллер ESP32-S3FN8 с LoRa-чипом SX1262. При правильной установке антенн и хороших условиях распространения радиоволн возможна передача данных на километры.

Но что, если нужно передавать данные ещё дальше, а возможности антенн с большим коэффициентом усиления исчерпаны и мощность передатчика повышать нельзя? 

Когда я начал работать с CH32V203G6U6 и обнаружил, что там есть 64-битный аппаратный таймер, то подумал: ух, это же отлично, раз таймер аппаратный, то и о чтении/записи заботится сам микроконтроллер. И какое-то время это не вызывало вопросов. А потом…

Сделай сам — покажи другим, как надо. На старте сезона DIY Лемана Тех и Хабр пришли с таким запросом к сообществу авторов, и они не подвели. В рамках сезона вышло множество статей о самых разнообразных проектах, сочетающих работу с железом и софтом. Участники соревновались в том, кто лучше всех владеет отвёрткой, 3D‑принтером, различными языками программирования, у кого самая необычная идея и кто способен максимально хардкорно её воплотить.

В этом материале подводим итоги, делимся лучшими статьями и вновь наблюдаем на множестве примеров, что связь между DIY и разработкой глубока и разнообразна.

Инструмент называется Tymbal.

Характер задаёт учитель — обработанный сигнал, на который натаскивается уточнитель. Смените учителя, и характер сменится целиком, а конструкция останется прежней.

Tymbal — орган звукоизвлечения цикады: ребристая мембрана, которая щёлкает при нелинейном выгибании. Маленький аппарат, громкий и богатый обертонами результат, и весь механизм держится на одной нелинейности. У нас нелинейность учителя переносится сетью на детерминированный скелет, и всё это живёт на одном чипе.

Слово к тому же приходит оттуда же, откуда «тембр». Merriam‑Webster выводит tymbal как изменённое от более раннего timbal (литавра), а timbre — от греческого tympanon, барабана: в старофранцузском это ещё барабан, в среднефранцузском — колокол под молоточком, и лишь потом слово стало означать окраску звука. Имя инструмента и слово «тембр» — родня по барабану.

Первый вариант я написал через i, как в литавре. Пришлось переименовывать: у цикады это tymbal, через y.

N6 ниже по тексту — рабочий индекс по имени чипа, он остался в названиях файлов и веток.