Risk-V и запуск К1921ВГ015

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

Учимся программировать микроконтроллеры

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

В этом тексте я написал про то как наладить интерфейс командной строки (CLI) по двухпроводному синхронному отладочному интерфейсу SWD.
Посылать в прошивку команды и получать ответ.
Чтобы можно было работать примерно как с UART, только по SWD.
Это когда прошивка в коде асинхронно получает текстовую строку от PC и отправляет текст обратно в сторону PC.

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

Кошмар с автозавершением
Наше префиксное дерево было в 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 на Си.

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

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