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

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

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

При определении топологии сети для обхода 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 тысяч сообщений в секунду. В восьмиядерной системе она должна быть гораздо выше.

«Можно ли улучшить ситуацию, отказавшись от блокировок?», — спросил меня мой менеджер во время ревью производительности.

Этот вопрос привёл к полной смене архитектуры...

В этом тексте я показал как настроить потоковую запись ADC семплов на микроконтроллере STM32.

ADC модуль это основа любого электронного измерения. Основа любого DMM. Всё что за корпусом микроконтроллера - это аналоговый мир. ADC это портал который позволяет аналоговым сигналам просачиваться в мир цифры.

Разработчики FPGA часто сталкиваются с необходимостью внедрения в свой проект софт процессора. Когда-то давно мы могли использовать проприетарные Altera NIOS или Xilinx MicroBlase. Но время идет. В последние годы наблюдается устойчивый тренд перехода производителей ПЛИС в сторону поддержки архитектуры RISC-V.

RISC-V это открытая, расширяемая и бесплатная архитектура набора команд (ISA), которая не требует лицензионных отчислений. Оба FPGA вендора Altera и Xilinx уже довольно давно предлагают и активно разрабатывают поддержку RISC-V в своих новых продуктах, теперь это уже софт процессоры NIOS V и MicroBlase V.

Однако, зачем использовать всё ещё проприетарные ядра, если можно использовать Open Source?

В этой статье я сравниваю два Open Source RISC-V микропроцессора:
1) picorv32 от компании YoSys (https://github.com/YosysHQ/picorv32) и
2) scr1 от Syntacore (https://github.com/syntacore/scr1)

Что буду сравнивать? Производительность софт ядер и занимаемые ресурсы в FPGA.
Как правильно сравнить? Использовать единую тестовую программу написанную на языке C, например Dhrystone, и скомпилированную в бинарный файл, или HEX файл и запускаемую в двух архитектурно одинаковых SOC, но с разными ядрами RISC-V.

> Названием «глухарь» птица обязана известной особенности токующего в брачный период самца утрачивать чуткость и бдительность, чем часто пользуются охотники

Защита программного кода — извечная битва меча и щита. Одни люди стараются создать устойчивые ко взлому программные и аппаратные продукты, другие пытаются эти решения сломать. Но что происходит, когда команда, специализирующаяся на взломе, выпускает на рынок свой продукт? Можно ли в этих обстоятельствах разработать устройство, защиту которого невозможно обойти?

Сегодня мы посмотрим внутрь флеш-картриджа для Nintendo Switch под названием MIG Switch и раскроем тайну его происхождения! Ну и в качестве побочного квеста победим защиту одного из самых современных микроконтроллеров на рынке.

Итак, в первой части я смело пообещал вторую статью «из одних картинок», но… мой маленький часовой кукушонок настолько похужал и возмудел за прошедшее время, что пришла пора знакомиться с ним, можно сказать, заново. Оптимизация не пощадила практически ничего, и, хотя я там же в камментах бо́льшую часть перемен отразил — всё равно надо начать с того, что же в сумме у нас получилось.