Как работает stm32-ros-alt-channel

Данные прошивки попадают в ROS1 без её изменения. Маршрут A читает переменные из памяти по SWD и не занимает UART, маршрут B берёт штатные топики rosserial по UART. Оба сходятся в одном ROS-графе внутри WSL, откуда их смотрят вживую или записывают в файл.

Путь данных

адреса, плата не нужна маршрут A: SWD маршрут B: UART ROS-граф и запись
1. Адреса полей (только для маршрута A)
Те же модули, что у stm32-diag-record: здесь их оригиналы.

fields.toml

что публиковать: топик, тип, выражение

expr = "&some_counter"

прошивка.elf и SVD

DWARF для переменных, имена регистров для svd:

читает

resolve_addresses.py

GDB вычисляет выражения по ELF, svd_lookup.py — регистры

офлайн, без платы
пишет

addresses.json

адрес, тип, сдвиг и маска каждого поля

2A. Маршрут A: память по SWD
Ядро не останавливается, UART свободен, root и socat не нужны.

Микроконтроллер

переменные в RAM, регистры периферии

SWD

ST-Link

отладчик

USB

OpenOCD, Windows

команды mdw по telnet

127.0.0.1:4444
mirrored networking

telemetry_node, WSL

читает слова по адресам, публикует топики

std_msgs/UInt32, Float32…
2B. Маршрут B: штатные топики rosserial
UART занят, зато видны все топики прошивки и есть обратный канал.

Прошивка с rosserial

топики по отладочному UART

UART

COM-порт, Windows

tcp_serial_redirect отдаёт его по TCP

127.0.0.1:7777
TCP

socat, WSL

превращает TCP в виртуальный последовательный порт

/dev/ttyVirtual0
PTY

serial_node

согласует топики с прошивкой и публикует их

3. ROS-граф в WSL: смотреть и записывать
При --via both маршрут A публикуется в дерево /swd/..., чтобы имена не совпали.

roscore

ROS1 Noetic внутри WSL: под Windows ROS1 официально не поддерживается

топики

Вживую

rostopic echo, PlotJuggler с плагином ROS

или

recorder_node

пишет любые топики через AnyMsg; прерванный bag переиндексируется

.bag (bz2), .mcap

Один запуск

Доктор--doctor: WSL, ROS, socat, доступ к портам Windows, остатки прошлого запуска.
План--dryrun: проверки и план без запуска.
Маршрут--via openocd | rosserial | both, смотреть с --keep.
Запись--record bag | mcap --seconds N.
Уборка--cleanup: останавливает ROS, собственный OpenOCD и редиректор, проверяет остатки.

Какой маршрут выбрать

A: SWDB: rosserial
ИсточникRAM по SWDUART прошивки
Виднополя из спецификациивсе топики прошивки
Правка прошивкине нужнанужна rosserial
UARTсвободензанят
Обратный каналнетесть
root и socat в WSLне нужнынужны

Время в WSL

Исследование 19 установило конфликт коррекции часов: monotonic замедлялся, realtime прыгал. Ранний вывод об остановке ВМ был опровергнут.

  • при паузах сравните REALTIME, MONOTONIC и RAW с независимыми часами Windows; настройки NTP меняют после диагностики;
  • проверка: wsl_tick.py, сравнение с часами Windows — host_clock.py и host_ref_probe.py;
  • счётчик платы тоже калибруйте относительно Windows: номинальная миллисекунда не гарантирует точность.

Если ROS не нужен, а нужен только файл, — навык stm32-diag-record: та же запись без WSL.

Что важно понимать

Прошивка не меняетсяДля маршрута A. Переменная должна жить в RAM, а не в регистре процессора.
ELF той же сборкиАдреса берутся из ELF: другая сборка — другие адреса.
Прошивка должна работатьПосле reset halt значения замирают.
Свои типы тоже пишутсяAnyMsg хранит готовые байты и описание типа, поэтому пишется любой топик.
Остатки мешаютУстаревший PID roscore или занятый порт ломают следующий запуск: помогает --cleanup.
Сверяйте с эталономСмещение на 4 байта даёт правдоподобное, но чужое значение.

Общая база диагностики

Оба навыка используют одинаковые модули чтения OpenOCD, декодирования полей, поиска GDB и управления дочерними процессами. Исправления транспорта применяются к записи в файл и к публикации ROS. Поддерживаются маски, сдвиги и невыровненные поля.

Источник модулей — stm32-ros-alt-channel; каждый навык содержит полную копию нужных скриптов и устанавливается самостоятельно. CI проверяет совпадение копий и оба потребителя, в Emulation используются адреса из ELF stm32-skills-probe.

Назначение маршрутов сохраняется: ROS/WSL и rosserial — в ROS-навыке, запись без ROS, Renode и RTT — в diag-record. В CI тест ROS-публикации подменяет middleware. Локально проверена также публикация через настоящий ROS Noetic в WSL с TCP-имитатором OpenOCD; SWD на F411CE проверен владельцем после рефакторинга; UART требует отдельной проверки.

Насколько проверено

19.10.2026, F411CE, версия d003ca5: SWD → ROS Noetic, семь топиков, около 10 Гц, MCAP 700 сообщений (по 100 на поле), fault=0, LED продолжает мигать после завершения. Tick платы отстал от Windows на 2,72% при независимом чтении без ROS; текущая проба WSL за 120 с не выявила скачков. Контроль HSI → HSE 25 МГц → HSI воспроизвёл отклонение только на HSI: около −2,7%; на HSE — 1562,546 tick/с при ожидаемых 1562,5. Настройки восстановлены, tick растёт и LED мигает.

Проверка частоты выбирает реальный опубликованный топик, предпочтительно tick_ms; можно указать --hz-topic /bp/tick_ms. На F411CE проверены автовыбор (9,998 Гц) и явный выбор температуры (10,005 Гц), оба выхода с кодом 0. Методика: Windows, WSL и MCU.

Проверяется в CI репозитория

  • адреса по ELF зонда: символы совпадают с nm, поля структур — с DWARF, регистры — с SVD F411
  • чтение RAM работающего ядра в Renode для F411CE и F103C8
  • писатели bag и MCAP (общие с stm32-diag-record): файлы читаются библиотеками mcap и rosbags

Ещё не проверено

  • UART/rosserial после рефакторинга; калибровка аппаратного времени
  • частота опроса и влияние на прошивку (R8), потери маршрута B (R9), время в WSL (R10)

Описание навыка (SKILL.md) и скрипты · версия 1.4.1