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

Я работаю в компании, которая разрабатывает и продаёт систему электронной очереди. Пришёл недавно, успел написать веб-клиент для их очереди — общение по SOAP, веб сайт, талоны с QR кодом, ничего особенного. Потом руководство поставило задачу: интегрировать физическое табло с вызовом клиентов через веб. Старое десктопное приложение как-то умеет зажигать на нём цифры — надо сделать то же самое, но из веба.

Окей, задача понятная. Первым делом пошёл к тем, кто делал это приложение.

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

Для лучшего восприятия ограничимся определением умного дома как комплексным управлением светом (основной свет, подсветка, шторы), управления климатом (обогреватели, кондиционеры, осушители, увлажнители) и безопасностью (замки, датчики присутствия). Поведение устройств может определяться как изолировано (включение/выключение света в гостиной), так и объединено в единые сценарии (ночной режим, основной режим, режим охраны).

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

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

Получив макетные платы, стало необходимостью запустить демо проект. Для него потребуется также JTAG, компилятор и OpenOCD. Сам JTAG использовался DirtyJTAG. Ну а дальше разбираемся.

В этом тексте я написал про то как наладить интерфейс командной строки (CLI) по двухпроводному синхронному отладочному интерфейсу SWD.

Посылать в прошивку команды и получать ответ.

Чтобы можно было работать примерно как с UART, только по SWD.

Это когда прошивка в коде асинхронно получает текстовую строку от PC и отправляет текст обратно в сторону PC.

Если что-либо можно измерить числами, то это уже вселяет оптимизм. Значит мы имеем дело с более-менее понятным объектом или явлением, которое можно описать устоявшимися правилами. И, казалось бы, что тут такого, измерить влажность почвы? Вроде простоя и понятная задача, но в ней всё оказывается не так уж просто. Давайте разбираться!

PwrBlock (Power Block) — открытый программируемый источник питания для тестовых стендов и автоматизации проверки электроники.

Его уже можно потрогать руками, а скоро — заказать себе такой или собрать самостоятельно: проект полностью open source. Рассказываю, из чего он сделан, что уже работает, что показал тест на максимальной мощности и какие выводы появились после первых измерений.

Кошмар с автозавершением

Наше префиксное дерево было в 8 раз медленнее хэш-таблицы. И оно потребляло 128 МБ памяти, в отличие от хэш-таблицы с 24 МБ.

Такого не должно было произойти. Префиксные деревья — стандартное решение для автозавершения: поиск за O(k), где k — длина строки вне зависимости от размера датасета. Идеально подходит для сопоставления префиксов. Обычно всегда используется для автозавершения, проверки правописания и таблиц IP-маршрутизации.

Мой коллега предложил использовать префиксное дерево для функции автозавершения в нашем инструменте командной строки. Поиск в нём должен был выполняться по 50 тысячам команд и опций. Учебники говорили, что это правильный выбор.

Поэтому мы реализовали префиксное дерево. Результаты бенчмарка оказались ужасными:

Префиксное дерево было в 8 раз медленнее простой хэш-таблицы. И оно использовало 128 МБ памяти, в то время как хэш-таблица — всего 24 МБ.

Где мы ошиблись?

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

Вся наша база данных находилась в памяти, однако операции поиска по ней занимали 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 поставляется с набором консольных утилит, которые делают этот процесс вполне прямолинейным.

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

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

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