При работе с STM32 приходится решать несколько повторяющихся задач: настроить сборку, подключить библиотеки, записать прошивку и проверить её поведение на плате. После изменений эти действия нужно выполнить снова — желательно тем же способом и с понятным результатом.

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

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

Инструменты можно использовать по отдельности. Например, готовый HEX можно записать через stm32-flasher независимо от способа его сборки. А stm32-gdbtest можно подключить к проекту, который не использует YAML-конфигурацию.

stm32-cmake-yml помогает вынести повторяющиеся настройки сборки в явное описание проекта. В файле stm32_config.yml задаются микроконтроллер, исходники, библиотеки, драйверы и параметры получения выходных файлов. Скрипты читают это описание и настраивают сборку CMake.

Основной механизм опирается на stm32-cmake. Моя часть добавляет конфигурацию через YAML и типовые способы подключения компонентов. При этом CMake остаётся доступен: собственные библиотеки, дополнительные цели и нестандартную логику можно описывать обычным способом.

Практический смысл особенно заметен, когда у прошивки появляются несколько вариантов. Общую часть конфигурации можно сохранить, а отличия микроконтроллера, платы или набора функций вынести в профили. В YAML видно, какие исходники и компоненты входят в сборку. При просмотре изменений в Git можно сразу заметить, например, добавление библиотеки, смену MCU или изменение флагов компиляции.

Проект допускает работу с CMSIS, HAL/LL, FreeRTOS и другими компонентами, а также отдельные варианты с Arduino Core STM32 или собственным startup. Часть настроек можно получить из файла CubeMX .ioc. Генерацию кода инициализации по-прежнему выполняет CubeMX. Границы этих возможностей описаны в README фреймворка.

demo-stm32-cmake показывает, как это выглядит в прикладных примерах. Здесь собраны проекты для разных семейств STM32: от запуска, GPIO и последовательного порта до работы с датчиками, дисплеями и сетевыми интерфейсами. Вместе с исходниками находятся конфигурации сборки и настройки работы в VS Code.

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

stm32-flasher закрывает задачу работы с готовым образом прошивки в Windows. Утилита использует ST-Link или J-Link и доступный инструмент записи: OpenOCD, STM32CubeProgrammer либо SEGGER J-Link Commander. Она сохраняет настройки выбора, журнал и отчёт о результате.

Один из простых вариантов использования — положить flash.cmd рядом с HEX-файлом и выполнить команду flash или запустить скрипт в Проводнике.

Сейчас доступны следующие команды:

Полное описание поведения команд находится в репозитории stm32-flasher.

Отдельной проблемой является тестирование для встраиваемых применений, где обычные подходы с unit-тестированием встречаются с разнообразием периферии и вообще тестового окружения. Хочу предложить ещё один инструмент в набор разработчика.

stm32-gdbtest превращает действия в отладчике в сохраняемые сценарии. Разработчик обычно уже умеет остановиться в нужной функции, посмотреть переменную, проверить регистр и продолжить выполнение. Здесь эта последовательность вместе с ожиданиями записывается на Python и хранится рядом с проектом.

Сценарий выполняется на компьютере внутри GDB с поддержкой Python. На микроконтроллере работает прошивка приложения; тестовую логику в неё добавлять не требуется. Для проверки используются ELF с отладочной информацией, описание микроконтроллера и конфигурация стенда.

Общая цепочка выглядит так:

Python-сценарий в GDB
        ↕
    GDB-сервер
        ↕
  ST-Link / J-Link
        ↕ SWD
  STM32 с прошивкой

Модуль организует запуск, ограничивает время выполнения и сохраняет отчёты JSON/JUnit. Сценарий достигает выбранной точки программы, читает значения и сравнивает их с ожиданиями. Такой подход в документации мною назван DDTT — Debugger-Driven Testing on Target, тестирование через отладчик на целевом устройстве.

В практических сценариях проверяются запуск приложения, настройки периферии, работа обработчиков прерываний и реакция программы на ошибки. Например, можно принудительно вернуть из вызова HAL код ошибки и проверить, что вызывающий код обработает его ожидаемым образом. Это проверка соответствующей ветви приложения; физическую причину отказа периферии такой опыт не воспроизводит. Возможности и ограничения собраны в README stm32-gdbtest.

Последовательность, однажды выполненная вручную или с помощью ИИ-агента, становится частью репозитория. Её можно повторить и получить отчёт.

Стенд может находиться рядом с рабочим компьютером или работать отдельно. В README модуля описаны несколько вариантов подключения. Во всех них сохраняется цепочка «GDB-сервер → USB-отладчик → SWD → микроконтроллер», а размещение программной части отличается.

Для удалённого сервера схема получается такой:

Рабочий ПК                        Linux-стенд
сценарий + GDB <─ SSH-туннель ─>  GDB-сервер
                                      ↕ USB
                                   отладчик
                                      ↕ SWD
                                     STM32

В опубликованных опытах локальные запуски выполнялись на Windows и Orange Pi 5; удалённые — с Windows и WSL2 на Orange Pi. Проверены также перенос пакетов и аппаратный CI. Локальный Linux x86_64 и вариант WSL2 с USB-пробросом пока не проверялись.

Для Orange Pi используются OpenOCD и J-Link. Выбор серверов зависит от платформы компьютера стенда. Актуальные сочетания и схемы приведены в разделе «Схемы запуска».

Два проекта hwtest показывают применение этого подхода на типовых отладках. stm32-hwtest-bluepill — небольшой пример прошивки и её проверки на STM32F103, удобный для знакомства с инструментом. stm32-hwtest-blackpill — более широкий стендовый проект с примерами для нескольких плат и накопленными результатами аппаратных опытов. Именно из него общая инфраструктура тестирования была выделена в stm32-gdbtest.

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

В CI stm32-cmake-yml есть проверки конфигурации и матрица сборок небольших тестовых прошивок с разными версиями инструментов. Подготовленные образы запускаются в QEMU и Renode. Проверяются, например, начальное состояние памяти, запуск C++-конструкторов и отдельные сценарии с библиотеками и FreeRTOS. Предусмотрены намеренная ошибка, зависание и повреждение образа — чтобы проверить способность инфраструктуры обнаруживать отказ.

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

В stm32-gdbtest без оборудования проверяются инфраструктура, сборка тестовых прошивок и подготовка сценариев по ELF. Отдельный аппаратный workflow запускается вручную и использует собственный раннер с подключёнными платами.

У BluePill CI включает сборки, подготовку аппаратных сценариев без платы и ограниченный тест в Renode. У BlackPill опубликованный offline workflow собирает профили и проверяет подготовку тестов; аппаратные результаты фиксируются отдельно. Для stm32-flasher автоматизированы проверки синтаксиса и тесты служебных режимов, резервного копирования и справки в двух вариантах PowerShell.

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

demo-stm32-skills относится к организации работы с ИИ-ассистентом. Репозиторий содержит примеры навыков: инструкции по настройке YAML, подключению исходников, созданию библиотек, разбору ошибок сборки и оформлению BSP-драйверов.

Каждый навык задаёт порядок работы и содержит примеры и типовые ошибки. Это позволяет сохранять принятые в проекте приёмы и передавать их ассистенту вместе с задачей. Навыки периодически обновляются.

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

Буду рад обратной связи в комментариях и Issues соответствующего репозитория. Особенно полезны конкретные наблюдения: какая плата использовалась, какую задачу вы решали, что оказалось неудобным и какого поведения ожидали. А если вы уже автоматизируете проверки STM32 через отладчик, интересно сравнить подходы — прежде всего выбор точек наблюдения, работу с ошибками и организацию удалённых стендов.