Учимся программировать микроконтроллеры
Если вы экспериментировали со встроенными устройствами, такими как 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 и раскроем тайну его происхождения! Ну и в качестве побочного квеста победим защиту одного из самых современных микроконтроллеров на рынке.
Итак, в первой части я смело пообещал вторую статью «из одних картинок», но… мой маленький часовой кукушонок настолько похужал и возмудел за прошедшее время, что пришла пора знакомиться с ним, можно сказать, заново. Оптимизация не пощадила практически ничего, и, хотя я там же в камментах бо́льшую часть перемен отразил — всё равно надо начать с того, что же в сумме у нас получилось.
Представьте, что вы начали слушать новый альбом любимой группы, а за стеной активизировался сосед с перфоратором. Примерно так же «чувствуют себя» компоненты на плате смартфона, контроллера или роутера, которые соседствуют с высокочастотным тактовым генератором. Чем выше скорость передачи данных — тем сильнее шум соседского перфоратора: электромагнитные помехи. Обычно помогает экранирование или фильтрация определенных частот, но у этих способов есть свои недостатки и ограничения.
Есть более элегантное решение — тактовый генератор с распределенным спектром (ТГРС). Мощность генератора остается прежней, а вот шум удается заметно снизить. Меня зовут Павел Кириченко, я автор курса «Схемотехника для начинающих» и ведущий инженер по разработке SoC в YADRO. В статье разберемся, как спроектировать ТГРС для последовательного интерфейса и рассмотрим два подхода к его архитектуре: с переменным коэффициентом деления и c фазовым интерполятором.