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

Загадка базы данных

Вся наша база данных находилась в памяти, однако операции поиска по ней занимали 12 тысяч тактов. При миллионе показаний датчика IoT-устройства с 64 КБ кэша реализация красно-чёрного дерева оказалась слишком медленной для запросов в реальном времени.

«Давайте попробуем B-дерево», — предложил я.

«Разве они нужны не только для баз данных на дисках? — спросил лид, — У нас всё находится в памяти. Чем нам будет полезно B-дерево?»

Вопрос был вполне разумным. B-деревья были придуманы для доступа к диску; каждый узел в них — это блок диска. Однако паттерны промахов кэша выглядели подозрительно похожими на паттерны дискового ввода-вывода — всего в 100 раз, а не в 100000 раз быстрее.

В итоге мы реализовали B-дерево. Результаты удивили всех...

Программы часто отлаживают применяя printf-отладку.
Однако в этом есть недостаток. Со временем вывод printf сообщений становится настолько частыми и плотным, что становится просто невозможно что-либо прочитать.

Чтобы с этим бороться придумали уровни логирования Log Levels.

Суть в том, чтобы из shell консоли в run time можно было включать или отключить логи для конкретных программных компонентов. Отдельными командами вы можете увеличивать или уменьшать многословность логирования.

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

Практический кейс реверс-инжиниринга приборной панели на базе микроконтроллера 9S12HY64 (Freescale). Вместо дизассемблирования мы использовали сниффинг шины I²C, сбор референсных команд, поиск сигнатур в прошивке и точечный патчинг статических данных.

В этом тексте я написал как реализовать CLI на CAN шине.

В разработке электроники часто делают электронные плату без UART, но с CAN .

Как же отлаживать софт и железо в таких случаях?

Катастрофа с красно-чёрным деревом

Компилятор тратил 60% времени на поиск символов. Не на парсинг, не на генерацию кода, просто на поиск в таблице символов.

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

«У него O(log n); судя по учебникам, оно идеально подходит для этой цели», — сказал мой коллега.

Но профилировщик показывал иное...

Как из таблицы истинности и четырёх битов родился семисегментный дешифратор? Разбираем два способа синтеза логических выражений, минимизацию и сборку в Digital Deeds. Спойлер: ни одной готовой микросхемы, только логика и желание понять, как это работает внутри.

«Преждевременная оптимизация — корень всех зол, но преждевременная пессимизация является им не в меньшей степени». — Андрей Александреску

Проблема перераспределения

Динамические массивы (векторы C++, ArrayList в Java) — одна из самых полезных структур данных. Они сочетают в себе удобство для кэша, присущее массивам, с гибкостью динамического изменения размера.

Однако у них есть скрытые затраты, связанные с перераспределением.

Однажды я работал над агрегатором логов встраиваемой системы. Система накапливала сообщения логов в динамическом массиве и периодически скидывала их на флэш-накопитель. Кажется, всё просто, не так ли?

Но производительность была ужасной. Система тратила 60% времени на realloc().

Миф про O(1)

Говорят, что хэш-таблицы обеспечивают поиск за O(1) — константное время, вне зависимости от размера. В теории они идеальны.

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

Я оптимизировал таблицу символов для компилятора. Таблица символов использовала хэш-таблицу с 1024 бакетами, и у нас было примерно 500 символов. Расчёты выглядели отлично: средний размер бакета = 500/1024 ≈ 0,5, поэтому большинство операций поиска должно выполняться за один запрос.

Но профилировщик рассказал иную историю...

Хорошие инструменты для отладки встраиваемого ПО микроконтроллеров давно стали делом привычным. Возможности таких инструментов определяются как архитектурой ядра, так и выбором отладчика. Рассмотрим три понятия: DAP (Debug access port), ITM (Instrumentation Trace Macrocell) и RTT (Real-Time Transfer). Всё это «механизмы» позволяющие выводить отладочную информацию в том или ином виде. DAP – это аппаратный блок, который дает доступ к шинам и ядру микроконтроллера. ITM – это специальный блок внутри Cortex-M (начиная с M3 и выше), предназначенный для сообщений с минимальными потерями времени. RTT – технология компании SEGGER, построенная на использовании кольцевого буфера внутри RAM. Именно о ней и пойдет речь в публикации.

Некоторое время назад я поделился первыми впечатлениями от знакомства с Ардуино-совместимой платой ELBEAR ACE-UNO на базе отечественного микроконтроллера MIK32 «Амур». Материал нашёл хороший отклик среди читателей, и это подогрело моё желание развить тему. Правда, подогрев слегка перешёл в фазу медленного бурления, и достиг точки закипания только сейчас. Но лучше поздно, чем никогда.

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

В этом тексте я покажу как собрать прошивку при помощи компилятора IAR и GNU Make файлов.

Собрать прошивку компилятором IAR с помощью GNU Make — это не просто возможно, это стандартный подход для автоматизации сборки, например, на CI/CD серверах, где использование IDE неудобно. IAR поставляется с набором консольных утилит, которые делают этот процесс вполне прямолинейным.

Статья посвящена микроконтроллерным системам управления преобразователями частоты для электродвигателей переменного тока. Рассматриваются различные варианты структуры и конструкции систем управления преобразователями частоты. Приводится техническое описание российского микроконтроллерного блока управления БУПЧ, который входит в состав преобразователей частоты для судовых систем электродвижения концерна «Русэлпром»: его состав, устройство, технические характеристики, преимущества и недостатки по сравнению с западными аналогами. Рассматривается сервисное программное обеспечение, которое существенно сокращает время тестирования и отладки программного обеспечения для БУПЧ, уменьшает вероятность ошибок в нем, способных привести к аварийным ситуациям, позволяет проверить правильность работы БУПЧ и преобразователя частоты, а при возникновении ошибок – быстро определить их причину. 

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

В статье рассматривается процесс создания программы для инициализации и управления микросхемой ad9363. Описанный подход применим для всего семейства ad936x. Всё реализовано под клон ADALM-Pluto с помощью Vivado 2021 и Vitis 2021 на Си.

AI - не микроархитектор, не проектировщик и не верификатор. Это все-лишь гламурный поисковик уже решенных и опубликованных задач. Именно такой вывод следовал из предоставленных мною на конференции SNUG Silicon Valley 2026 фактов как десятки студентов мучали ИИ чтобы решить мои задачки. Одну задачку ИИ решил лишь через полгода после выкладывания решений в интернет, другую за два месяца, потом пошла третья. При этом задачки были довольно банальные - мы в Самсунге даем делать такие статические конвейеры с контролем потока данных практикантам.

Вот постер, сопровождающий мою статью:

Это мой развернутый ответ на тему организации программных таймеров который я обещал в комментариях (ссылка на комментарии будет ниже).

На самом деле это не совсем то что я изначально имел ввиду - хотел рассказать, то есть это на самом деле только часть ответа. Картинки я здесь не стал рисовать, так как они уже у меня нарисованы в одной из предыдущих статей, ссылка тоже будет, но в самом конце.

Как создавать пользовательские типы данных в открытой АСУТП? Зачем объединять скорость, температуру и статус двигателя в одну переменную?

В ИТ-команде «Северстали» мы занимаемся разработкой компонентов для открытой АСУТП. В этой статье разберём, как создавать и применять пользовательские типы данных в нашей среде разработки Flogic. 

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

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

Сейчас беспроводными технологиями передачи данных никого не удивишь. На том же Али море различных модулей для беспроводной связи на любой вкус и цвет начиная от WiFi заканчивая NFC и RFID. Однако, в некоторых изделиях, по разным причинам, применение спец микросхем/модулей беспроводной передачи данных может быть нежелательно. Эта статья о том, как можно c помощью дросселя и нескольких транзисторов реализовать беспроводный интерфейс малого радиуса действия для микроконтроллера.

Modbus — это открытый и очень распространённый протокол обмена данными в промышленной автоматизации. Он работает по модели master–slave: мастер (например, PC-приложение) запрашивает данные у ведомого устройства (ПЛК), получая или записывая значения регистров.

На практике Modbus кажется простым — всего лишь массив 16-битных регистров. Но как только возникает задача читать типизированные переменные, поддерживать несколько проектов в одном ПЛК, минимизировать количество запросов и безопасно работать с соединением, всё быстро усложняется.

В этой статье я описываю реальный подход, который использовал для чтения и записи переменных из ПЛК и отображения их в приложении на C#.

Задачи в нашей небольшой команде разделены строго: Лев отвечает за аппаратную часть, схемотехнику и проект в целом, а Марк — за инженерию данных, разметку виброакустических датасетов и алгоритмы каскадной фильтрации.

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