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

В данной статье рассматривается процесс настройки vscode для разработки встроенного ПО на базе ядер cortex-M и процессе превращения редактора в полноценную IDE. При этом большинство представленных расширений являются универсальными и применимы в широком спектре задач программирования.

В отличии от проприетарных решений, таких как Keil, подход использования редактора vscode + компилятор gcc позволяет гибко настроить каждый пункт от начала разработки до релиза продукта. За время своей работы мною было опробованы разные решения: от классического keil до связки sublime и CodeSourcery. В последние годы я перешел на vscode + msys2: практически все ПО Open Source, не требует лицензий, не ограничено 32 Кб кода и может работать без сети интернет.

← Третья часть

Сколько себя помню, я любил играть в LEGO. Больше всего меня восхищало то, что из одного и того же набора типов блоков можно построить что угодно: главными были не блоки, а воображение или план, показывающий, в каком порядке их соединять. Мой проект работает аналогичным образом: один набор исходников, хороший план и множество различных способов собирать и тестировать его.

В этой части я расскажу об окружениях и их взаимосвязи.

Главный принцип этого фреймворка заключается в том, что единственный набор файлов исходников на Verilog можно без изменений использовать в различных средах сборки:

ModelSim для потактово точной симуляции HDL с волновым выводом

Verilator для быстрой симуляции на C++, с тестовой обвязкой (calctest) и другими инструментами

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

Qt WebAssembly для запуска калькулятора в браузере с попиксельной точностью

Quartus для синтеза и записи на физическую плату FPGA

Каждое из окружений позволило выявлять свой класс багов. ModelSim отлавливает проблемы таймингов на уровне сигналов. Verilator обладает достаточной скоростью для проверки тысяч тестовых векторов. Симулятор на Qt позволяет удобно пользоваться интерактивной отладкой. WebAssembly доказывает работоспособность кода в совершенно иной среде исполнения, в которой видением приложения можно поделиться со всем миром. Целевая платформа FPGA, реальная плата — это то, что можно потрогать, окончательная реализация идеи.

В предыдущем посте мы ответили на вопрос о реализуемости проекта: да, tan, ln, exp и sqrt можно при помощи различных трюков вычислить из сложения, вычитания и умножения. В этом посте мы поговорим о том, как делать это корректно с точностью до 16 десятичных разрядов при помощи проверенной эталонной реализации, относительно которой мы будем в дальнейшем тестировать оборудование.

Когда я начинал этот проект в 2021 году, мне нужен был код на C++, который бы реализовывал алгоритмы на основе примитивов BCD и проверял результаты. Этот код превратился в подпроект Methods. Он заработал, но в нём возникли небольшие баги с шириной мантиссы, из-за которых тестовые результаты оказались ненадёжными в пределах одного-двух последних разрядов. Вместо того, чтобы патчить его, я в 2025 году переписал всё с нуля в рамках подпроекта Proto: более чистой архитектуры, правильного эталона и генератора тестовых векторов оборудования, относительно которого можно валидировать микрокод FPGA.

Предыстория

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

Несколько лет назад я участвовал в соревнованиях по электронике и очень вдохновился интересным подходом и вовлеченностью разработчиков заданий. Прошло время, стал ездить на соревнования в качестве эксперта и в какой-то момент решил разработать устройство для одного из этапов соревнований – «программирование».

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

Нашли в сети статью одного автора о том, как он усовершенствовал свою версию часов из вольтметра — перевели её для вас.

В далёком 2019 году я собрал свои первые простые часы с вольтметром.

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

Потом со временем понял, что таких поделок много, и выглядят они плюс-минус как моя. То есть коряво и довольно кустарно. Так что я решил сделать что-то красивое и современное, и задокументировать весь процесс создания. Он под катом.

В области встроенных систем и СВЧ‑электроники применение «тяжёлых» нейросетевых решений (включая TinyML) часто ограничено вычислительными ресурсами и энергопотреблением.

В статье рассматривается альтернативный подход: частотная дискриминация с помощью двух амплитудных детекторов с разной нелинейностью отклика. Разница их выходных напряжений формирует уникальный «отпечаток» частоты. Для классификации используется однослойный перцептрон, реализованный на 8-битном микроконтроллере К1946ВМ014 (аналог ATmega8535) с целочисленной арифметикой.

Представлены схема устройства, алгоритм обучения и экспериментальные результаты распознавания частотных диапазонов. Код (95 строк) и основные технические решения.

Идея этого проекта пришла ко мне в феврале 2021 года, когда в Остине (штат Техас) произошёл сбой энергосистемы. К сожалению, нам надолго запомнилось то, как правительство справлялось с ситуацией. Когда единственным источником тепла и света остался только газовый камин, а единственным окном в мир — слабое телефонное Интернет-соединение, у меня было много времени поразмыслить о том, что бы новое и интересное мне хотелось разработать. Я взял калькулятор HP-41CV и начал нажимать на кнопки. Как обычно, ощущения от этого были самыми приятными. И мне захотелось самому создать нечто подобное!

В начальной школе мне представилась возможность поиграть с HP-41CV. Я наблюдал, как калькулятор загружает программу с магнитной ленты и запускает её. Жужжание считывателя карт и тонкая магнитная лента, втягиваемая в устройство с одной стороны и выходящая с другой, внезапно изменяли поведение калькулятора, что произвело на меня очень сильное впечатление. Я и не подозревал, что оно повлияет на всю мою жизнь. Спустя несколько лет у меня появился Sinclair ZX81, потом ZX Spectrum, на котором я при помощи дизассемблера HiSoft Devpac MONS взламывал разные игры. Эти два устройства (калькулятор HP и микрокомпьютеры Sinclair) подтолкнули меня к разработке, программному обеспечению и исследованию внутренностей разных машин. Во многом я стал разработчиком именно благодаря этому.

Когда-то я изучал сам чип Z80, воссоздав его в виде A-Z80 и написав визуальный инструмент Z80 Explorer, отображающий его список связей. В каком-то смысле это ощущалось как закрытие темы одержимости Sinclair. Проект калькулятора ощущался как закрытие темы HP. Это не клон, не эмуляция, а реализация с нуля на основе тех же принципов. Мне хотелось изнутри разобраться в том, почему эти машины работали именно так.

Как работает научный калькулятор? Не в общих чертах, а в подробностях. Как он хранит числа? Какой алгоритм вычисляет sin(x)? Как функционирует его очень простой CPU?

В серии моих статей мы получим ответы на эти вопросы: в конечном итоге мы получим полностью работающий научный калькулятор, спроектированный и изготовленный с нуля, на собственном CPU, созданном на FPGA, с написанным вручную микрокодом, эталонными реализациями на C++ и физическим «железом», которое лежит у меня на столе и может вычислять точные ответы. И всё это в опенсорсе: вы можете увидеть это и попробовать самостоятельно.

Насколько я понимаю, этот проект уникален: мне неизвестен ни один другой научный калькулятор (с тем же уровнем функциональности), реализованный на FPGA с собственным CPU и оригинальным рукописным ПО для его работы.

Yet another способ сверхбыстрого прототипирования из мелких модулей и печатных плат. Также, рассматривается вопрос вайбкодинга любых шрифтов на основе генерации из ttf для дисплея и вывода рисунка.

3-й этап программы раннего доступа к архитектуре RISC‑V DEVBOARDS на базе отладочной платы Base (EVU‑BA-2.1) на основе микроконтроллера Baikal‑U (BE‑U1000) стал одним из самых насыщенных по составу и содержанию проектов. Более 100 заявок, 32 отобранные команды и широкий отраслевой охват показали устойчивый интерес к этой платформе со стороны разработчиков, университетских команд и инженерных коллективов, работающих в прикладных направлениях. В центре внимания оказались проекты, связанные с промышленной автоматизацией, системами ЧПУ, интерфейсными модулями, контроллерами производственных линий и модульными беспилотными платформами.

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

Мне приходится периодически кататься на велике. В какой‑то момент я решил, что просто кататься — это слишком скучно. Захотелось не просто ездить, но и как‑то исследовать окружающий мир.

Я попробовал исследовать окрестности своего квартала на наличие источников WiFi излучения.

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

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

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

Если коротко, то я собрал из того, что было под рукой (местами буквально "на коленке"), и это неожиданно дало больше понимания, чем ещё одно обучение модели.

«Задача абстракции — не быть расплывчатой, а создать новый семантический уровень, на котором можно достичь абсолютной точности», — Эдсгер Дейкстра

Взрывной рост количества промахов кэша

При определении топологии сети для обхода 500 коммутаторов нашей системе требовалось 37,5 миллисекунды. Вроде бы это не так медленно, если не учитывать количество промахов кэша: 8,5 миллиона. При 500 узлах это 17 тысяч промахов на узел.

Структура данных была фундаментально неподходящей для этой задачи.

Работа инструмента была простой: определение топологии сети при помощи обхода графа соединённых устройств. У каждого коммутатора было до 48 портов, а нам нужно было при помощи поиска в ширину найти все доступные устройства из начальной точки.

Реализация была как по учебнику — список смежности со стандартным BFS. В случае сети из 500 коммутаторов (в среднем по 12 соединений у каждого) статистика была такой: 8,5 миллиона промахов кэша на 500 узлов. Это 17 тысяч промахов кэша на узел!

Я переписал этот код, реализовав графовое представление, учитывающее кэш. Результаты: код стал в 3,75 раз быстрее, а количество промахов кэша уменьшилось в 7 раз.

В этой главе мы поговорим об эффективном описании и обходе графов.

Если вы экспериментировали со встроенными устройствами, такими как Raspberry Pi, или у вас не получалось обновить прошивку маршрутизатора OpenWrt, то вы знаете, что делать: подключите USB-Serial TTL адаптер к трём волшебным контактам на материнской плате, обозначенным как RX, TX и GND.

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

Я задал вопрос про язык описания и верификации аппаратуры SystemVerilog. На это кандидат сказал, что он еще не освоил SystemVerilog, вписал его в резюме на будущее, но вообще использовал Verilog-95 и немного Verilog-2001.

“Нет проблем”, - сказал я и задал вопрос по Verilog-95: “приведите примеры гонок (race conditions) при использовании верилога”.

На это кандидат сказал, что вообще его опыт был больше связан с VHDL. “Блин, как он выкрутился” - подумал я, ведь в VHDL нет гонок как в верилоге из-за дизайна языка.

О себе: бэк-энд разработчик java/kotlin и немножко go, собственно вот профиль.

Работаю программистом я немного более трёх лет. До этого более 10 лет трудился в одной известной газовой компании в сфере электрохимической защиты подземных стальных сооружений от коррозии, также электроснабжения и немного автоматики. Была у меня там специализация на ремонте электронных блоков для эксплуатируемого оборудования.

И вот в начале 2010-х строились новые объекты, а на них появились относительно современные на тот момент так называемые системы коррозионного мониторинга.

Тогда я ещё был «синим воротничком» то есть непосредственно трогал всё своими руками.

Ошибки в заголовке нет: я ведь пришел на Хабр во времена Гиктаймс, не мысля себя ничем большим, кроме как техногиком. Впрочем, и это я себе комплимент сделал, простим меня за нескромность. И пусть GT уже давно нет, но я‑то есть. Что до лунохода, то речь о моей личной версии легендарной игрушки «Модель лунохода программируемая самоходная „Электроника“, он же в девичестве Big Trak, на который у меня ушло, чтоб не соврать, около десяти лет. Эй, подождите, сколько‑сколько?»

Представьте, что вы строите продукт на процессоре, а ключевые правила игры задает один владелец архитектуры. Хотите выпустить свой совместимый чип, добавить нужные расширения или просто не хотите зависеть от поставки конкретного изделия? Но почти везде упираетесь в лицензирование, отсутствие открытого доступа к IP-ядрам, документации и сталкиваетесь с ситуацией когда условия доступа к технологиям могут меняться быстрее, чем ваш цикл разработки. В стабильные времена это воспринимается как "стоимость входа", но в менее дружелюбные - воспринимается как риск, который внезапно становится техническим.

И пусть это звучит как рекламный слоган, но RISC-V предлагает другой базовый принцип: открытый стандарт команд, который можно реализовывать без разрешения на саму основу. Не "бесплатный процессор", а открытая спецификация, вокруг которой можно строить свои ядра и SoC, добавлять расширения и при этом оставаться в рамках общего стандарта. Это дает больше пространства для маневра именно там, где обычно больнее всего: в продуктах, которые выпускаются много лет, в требованиях к безопасности и в зависимости от чужих лицензий.

Но открытость не спасает от хаоса. Если каждый будет делать "почти совместимый" вариант, рынок быстро превратится в зоопарк, где интеграция того или иного решения снова становится подвигом. Российский Альянс RISC-V как раз про то, чтобы этого не случилось: он собирает участников и переводит идею открытой ISA в работающую экосистему, где софт, платы, безопасность, обучение и регуляторные ожидания не живут отдельно. Ставки тут очень практичные: кто умеет договориться о правилах и проверять их на практике, тот быстрее доводит решения до рынка и поддерживает их с наименьшими затратами. 

Именно о том какую роль играет Альянс в становлении целостной экосистемы RISC-V в России и будет наш очередной материал.

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

В тексте представлены основные идеи и решения для передачи и приёма битового потока c помощью BPSK модуляции.

Kubernetes давно стал повсеместной платформой, а написать к нему собственный оператор сегодня — задача нескольких часов. Стандартный путь — kubebuilder на основе controller-runtime: scaffold проекта, типы, реконсайлер. В типовых сценариях этого вполне достаточно. Но как только нагрузка растёт или поведение оператора начинает расходиться с ожиданиями, всплывает целый класс edge-кейсов, причина которых — непонимание того, как controller-runtime устроен внутри. Если вы пишете контроллеры для Kubernetes, этот материал поможет собрать целостную mental model и заранее избежать дорогих сюрпризов в проде.

В этой статье разберём внутреннее устройство controller-runtime и на его примере увидим, какие архитектурные решения лежат в основе самого Kubernetes. Начнём с того, как контроллеры читают объекты из Kubernetes API.

Есть распространённое заблуждение, что r.Get() в Reconcile ходит прямо в kube-apiserver, List() каждый раз смотрит «живую» картину мира, а после Update() можно сразу перечитать объект и увидеть свежее состояние. На практике всё наоборот: controller-runtime живёт на локальной копии данных через LIST+WATCH. Благодаря этому чтение в реконсайле обходится почти бесплатно и не нагружает control plane даже при сотнях вызовов в секунду — но ценой этой модели становится то, что оператор может внезапно съедать гигабайты памяти, делать скрытые O(n)-сканы и регулярно упираться в stale reads.

Статья рассчитана на тех, кто уже писал операторы на Go с использованием controller-runtime, но хочет собрать целостную mental model, а не жить с набором частных наблюдений. Фокус будет на практических последствиях для production-кластеров: память, трафик, консистентность чтения и поведение реконсайла.

Автор рассказывает, как самостоятельно создал аппарат для электроэпиляции, с какими сложностями столкнулся и как решал проблемы разработки.