Учимся программировать микроконтроллеры
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-кластеров: память, трафик, консистентность чтения и поведение реконсайла.
Автор рассказывает, как самостоятельно создал аппарат для электроэпиляции, с какими сложностями столкнулся и как решал проблемы разработки.
Полгода прошло с первой статьи https://habr.com/ru/articles/969230/ , вариометр летает и сигнализирует о наборе высоты и о потере высоты, пилоты довольны. Код сыроват конечно. EMA фильтр стоит, линейная архитектура стоит, записи высот в полете нет и экспорта нет. Как-то работает. Но можно качественнее сделать. А вот когда лень переписывать с нуля, знакомая херня? Но решился.
Развернул Hermes Agent, закинул на аккаунт DeepSeek4 40 юаней, это 430 рублей, и начал диалог в терминал. Работал в диалоге с консолькой, ну просто магия. Без промптов. "Сделай FSM вместо ифов, добавь зуммер в стиле Браунигер, компенсацию акселерометра по трём осям с учётом гравитации, а не по модулю, трек полёта на флешпамять кольцевым буфером с CRC, WiFi экспорт через вебморду."
Рассмотрен подход к созданию управляемого "бэкдора", позволяющего подгружать функции без остановки и перезагрузки. С помощью манипуляций с линкер-скриптом и средств языка C создаются "точки расширения" в прошивке, позволяющие в будущем внедрять новые функциональные модули без пересборки и перезаписи всей программы. Такой подход может быть полезен при разработке отказоустойчивых систем для оптимизации жизненного цикла встроенного ПО, так как позволяет заложить гибкость при непредвиденных модификациях.
Я Михаил — создатель и главный разработчик системы вэб приложений. Второй участник проекта — Владимир — разработчик мобильных версий и ответственный за SEO оптимизацию.
Так бывает, что в твоей клавиатуре всё нравится, кроме провода, который не добавляет эстетики и удобства. Поэтому у меня возникло желание сделать адаптер для превращения своей проводной клавиатуры в беспроводную.
Я уже предпринимал такую попытку в одной из своих статей. Описанный там адаптер представлял больше учебный интерес, чем имел практическое применение, так как прошивка представляла собой полноценный Linux, кастомизированный скриптами, и использовала слишком мощное (Raspberry Pi Zero 2 W) для такой простой задачи железо.
К той статье были написаны справедливые замечания, а сейчас я хочу их исправить.
«В Computer Science есть только две сложные вещи: инвалидация кэша и придумывание названий», — Фил Карлтон
Разрыв в производительности
Наш парсер логов обрабатывал 800 тысяч строк в секунду. Нам требовалось 3 миллиона строк в секунду. От нужного нам показателя мы отставали в 3,75 раза.
Задача инструмента заключалась в парсинге строк логов в реальном времени, извлечении временных меток, уровней логов и сообщений из миллионов строк в секунду. Обработка миллиона строк логов в текущей реализации требовала 1,25 секунды — слишком долго для анализа в реальном времени.
Профилировщик показывал 85 миллионов промахов кэша. Для обработки строк это казалось слишком большим показателем.
В реализации использовались стандартные строковые функции C — простые, читаемые, но, очевидно, слишком медленные.
Я переписал этот код, добавив обработку строк с учётом кэша. Результаты были такими:
В 4,5 раза быстрее и в 7 раз меньше промахов кэша.
В этой главе мы поговорим о том, как эффективно использовать кэш при обработке строк.
Эта статья является продолжением серии для демо-проекта на базе OpenPLC. В предыдущей части были рассмотрены программирование Raspberry Pi Pico W в режиме Modbus RTU/TCP Slave, управление реле через Ladder-диаграмму. Теперь пришло время добавить в схему CAN-шину.
Что добавляется в этой части: узел Pico W получает модуль MCP2515 и подключается к CAN-шине. Для этого в OpenPLC Editor написан пользовательский функциональный блок, который работает поверх ардуино-библиотеки и предоставляет доступ к CAN-шине из обычной Ladder-программы через глобальные переменные-маркеры %MW.
«Блокировки — это goto конкурентного программирования», — Морис Херлихи
Проблема 60%
Наша система логгинга тратила 60% своего времени на ожидание снятия блокировок. Не на выполнение полезной работы, только на одно ожидание.
Восемь ядер, пытавшихся записывать сообщения логов, имели общий кольцевой буфер. Реализация была простой: буфер защищался мьютексом. При высокой нагрузке, когда все ядра записывали логи одновременно, профилировщик демонстрировал ужасный паттерн: 60% тактов CPU тратилось на операции с мьютексом.
Пропускная способность: 850 тысяч сообщений в секунду. В восьмиядерной системе она должна быть гораздо выше.
«Можно ли улучшить ситуацию, отказавшись от блокировок?», — спросил меня мой менеджер во время ревью производительности.
Этот вопрос привёл к полной смене архитектуры...