Почему нам нужен UART-Shell?

Есть такая классическая технология отладки Firmware как интерфейс командной строки поверх UART. Почему UART? Ответ прост. UART самый дешевый и простой проводной интерфейс. Для него доступны как переходники UART-USB (CP2102) так и софт(TeraTerm/Putty).

Бытует мнение якобы: “Да нам UART-CLI не нужна так как у нас устройство удаленное и к нему нет доступа кроме беспроводных интерфейсов”. 

Это высказывание можно перефразировать так: “Да нам JTAG/SWD не нужен так как у нас устройство удаленное и к нему нет доступа кроме беспроводных интерфейсов”

Иллюзия таких рассуждений в следующем. 

1–Во первых. У вас после какого-то коммита сломался ваш беспроводной интерфейс. И что вы будете делать? Чтобы понять, что сломалось, вам поможет 2 минуты с и пара команд UART-CLI или 1 день прочесывания кода GDB отладчиком с JTAG/SWD.

2–Во вторых UART-CLI нужна для в основном для отладки в Debug(жной) сборке. В Relese(ных) артефактах Shell можно и выпилить. Причем если вы собираете из Make, то выпиливание CLI это заменить один символ в *.mk файле с (Y на N).

3–В третьих CLI можно пустить по любому интерфейсу и протоколу: CAN, LoRa, UDP. Просто в этом случае придется писать консольную утилиту-переходник для LapTop(а). Хипстерская Tool(а) типа с stdin/stdout текстовый CLI в конкретный бинарный протокол + драйвер интерфейса. А если жалко трафика, то придется еще и пропускать CLI трафик через программный компонент компрессии. Заметьте, никакой GUI(ни) пока не нужно.

4–В четвертых UART CLI нужна как раз для отладки и верификации механизмов удаленного доступа (например стека LTE/Ethernet/TCP/IP/LoRa). Сами по себе беспроводные стеки это тонна кода, который тоже надо как-то отлаживать. Я могу сказать, что даже для запуска того же LoRa надо подтянуть кучу зависимостей: GPIO, SPI, DMA, FlashFS, UART, TIMERS, SX1262. В BlueTooth зависимостей на два порядка больше. И для стабильного Link(а) эти зависимости все по отдельности должны работать безупречно.

Общая канва такова, что более сложный программный компонент можно отладить только менее сложным компонентом. Ethernet отлаживают, в частности, при помощи UART-Shell. UART отлаживают связкой GPIO+JTAG. GPIO отлаживают мультиметром или логическим анализатором.

20 причин почему вам пригодится UART-Shell  

1–Допустим у вас плата без HeartBeat LED(а). Ну пожалели разработчики денег, ну бывает. Вы накатили прошивку и ничего не происходит. Вообще ничего не поменялось. А вот UART CLI позволит произвести такой простой Smoke тест как “А не зависла ли прошивка?”. Для этого достаточно просто открыть UART консоль и нажать Enter. Если появился курсор, то тест пройден. Прошивка вертится. Успех.

2–С UART CLI можно автоматизировать работу с Target(ом). Автоматически прогнать тесты. Автоматически прописать серийные номера. Автоматически прописать ключи шифрования.

3—Если у вас перестал работать Ethernet, то UART-CLI поможет понять в чем загвоздка. Это обыкновенное резервирование.

4–Оборудование для отладки через UART CLI дешевле, чем оборудование для отладки по JTAG в сотни раз, так как не нужен дорогой программатор. Цена JTAG программаторов, кажется, вообще ничем не ограничена. Видел от 7kRUB до 5kEUR.

5–UART-CLI менее подвержен статическому электричеству в сравнении с SWD и JTAG. У SWD программаторов часто нет Link(а) c Target(ом). UART же работает всегда.

6–UART-CLI harness можно протянуть на большую длину чем SWD/JTAG.  SWD обычно не работает уже при длине шлейфа около 40 см. Для UART 1 м до HIL cтенда это вообще ни о чем.

7–Отладка через UART CLI удобнее, чем отладка по JTAG так как нужно всего 4 провода (Rx Tx GND VDD) вместо 20 проводов JTAG.

8–CLI можно использовать как имитатор устройства. Человек может отправлять данные в CLI в конкретную API(шку) , а микроконтроллер будет реально думать, что это какой-то протокол или вообще устройство. То есть варианты комбинаций способов отладки с CLI ограничены только вашей фантазией.

9–Через CLI можно загрузить в устройство энергонезависимые конфиги. Например параметры модуляции беспроводных трансиверов.

10–CLI проста в использовании. Исполнять команды в CLI сможет даже необученный персонал просто следуя скачанной инструкции из pdf(ки) и вам не надо будет посылать программиста в командировку за Урал, чтобы тот настроил радар или перепрошил RFID СКУД.

12— Из консоли TeraTerm можно скопипастить любой кусок текста. При работе с GUI-подобным конфигуратором часто скопипастить текст нельзя так как текст иногда отрисовывается прямо на канве.

13–Через CLI можно инициировать запуск модульных тестов и увидеть отчет исполнения тестов. Можно запустить только те тесты, которые имеют в своем имени конкретную подстроку (например «i2c»). Или запустить только один конкретный тест.

14–Через CLI можно верифицировать функционал. Заставить испустить синус определенной частоты на DAC или распечатать в UART содержимое файла в FatFS.

15–CLI стимулирует писать более модульный код так как для каждого компонента надо где-то хранить список его внутренних команд.

16–CLI побудит вас сделать общий на все компоненты API для доступа к периферии, компонентам и драйверам. Это позволит вам в будущем быстро мигрировать с одного микроконтроллера на другой просто определив API(шные) функции для очередного чипа. А это первый шаг к методологии AUTOSAR.

17–Через CLI можно обновить прошивку. Можно передавать куски прошивки Hex в формате base64 или просто hex в виде ASCII (получается base16).

20—CLI это вообще универсальный протокол. Можно и прошивку кидать, и конфиги прописывать, и различную диагностику вычитывать. CLI понимает и человек и компьютер. Для CLI не нужен вспомогательный софт. Всё работает из коробки.

18–CLI не нарушает timing(и) время исполнения программ протекает в естественном режиме. Это вам не точки останова JTAG, которые останавливают программу на несколько секунд и полностью нарушают логику приложения. Для современных процессоров 1 секунда это как для человека вечность. С Shell получается none disturb отладка.

19–Cli позволяет до программировать Target уже в RunTime(е). Вы всё равно не предусмотрите все возможные обстоятельства в статической прошивке. CLI позволит менять поведение устройства на лету. Shell позволит упростить поведение самой прошивки и просто составить скрипты CLI для каждого отдельного случая. На PC много места там все скрипты поместятся.

20—UART CLI можно через переходник USB_TypeС — UART подключить к Android смартфону и управлять платой с телефона.

CLI в прошивке это как строительные леса в civil engineering(е). Вы где-нибудь видели, чтобы строители летали на JetPack(ах) c кисточкой и ведром при покраске фасада многоэтажек?
Почему же тогда большинство российских программистов МК на 15м году опыта говорят: «Что еще за UART-CLI … A что так можно было что ли?»

Да, в программировании МК тоже есть такое понятие как инфраструктурный код. В программировании MCU инфраструктурный код это UART Shell и модульные тесты. Без этого ваш проект банально рухнет под собственной тяжестью спустя год и произойдет это в самый неподходящий момент. Или код просто не будет работать, а вы об этом даже не будете догадываться.

Причем есть же примеры очень успешных продуктов, которые с самого начала заложили shell в свой toolchain. Это загрузчик U-Boot, анализатор NanoVNA V2, трансивер FlipperZero, приемник GNSS U-Blox ODIN C099-F9P. Трансивер BC127, в кодовой базе Zephyr project есть Shell. Очевидно, что оглушительный успех этих продуктов в значительной мере определен наличием удобной и развитой CLI.

Вот список наиболее часто употребительных команд CLI безотносительно к конкретному проекту:

Показать список доступных команд Help/TAB, перезагрузиться, запустить модульные тесты, установить/считать напряжение на GPIO, установить подтяжку напряжения на GPIO, показать напряжение на входах ADC, запуск аппаратных таймеров, включить/отключить конкретное прерывание, перенастроить частоту процессорного ядра, прыгнуть в загрузчик, показать версию софта и железа, показать историю команд, установить уровень логирования для конкретного компонента, показать таблицу состояния потоков и их свойства (стек, приоритет), показать счетчик принятых/отправленных пакетов по всем протоколам, показать список файлов в файловой системе FatFs, отобразить в UART содержимое конкретного файла, Просканировать шину I2C, пульнуть произвольные данные в SPI/I2C/I2S/MDIO, Вычитать кусок памяти из REG RAM FLASH, Найти адрес по значению, повторить конкретную команду N раз с периодом P,

У меня в среднем на каждую сборку приходится максимум 120 Shell команд.

Недостатки CLI

1—Нет контрольной суммы в PDU. Пользователя же не заставишь в уме высчитывать CRC32 того, что он там написал и приписывать в конце 32 битный hex. Иначе прошивка не ответит. Это было бы просто смешно. Однако не все так плохо. Если вы используете в консоли Putty коды цветов и цвета отображаются плюс/минус норм, то это уже хороший знак того, что данные в трафике валидные.

2—В самом простом виде UART-CLI это открытый текст. Можно перехватить трафик. Можно похитить ценнейшие метрики (логин-пароль, ключи шифрования). Но я подчеркиваю, что UART-CLI это только для отладки софта и железа внутри офиса.

3—Надо защищать устройство от несанкционированного доступа к CLI так как в этом случае можно получить тотальный доступ к устройству, превратить его в BotNet(а). Можно добавить логин и пароль как в Linux. Либо выпускать отдельную desktop tool(у)-терминал для шифровки и расшифровки shell трафика между человеком и платой. Так сделали авторы прошивки радиостанции MeshTastic. Там python скрипты-посредники для конфигурации и диагностики LoRa трансивера TBream.

4— Можно нечаянно набрать опасную Shell команду. Например стереть прошивку или замкнуть H-мост на GPIO. Поэтому надо добавить запрос «вы уверены что хотите выполнять эту опасную команду?» или просто выпилить все опасные команды для каждой конкретной сборки.

5— нет контроля непрерывности трафика так как нет как такового заголовка пакета. CLI трафик это просто текстовые строки, оканчивающиеся переноси строки. Поэтому каждая Shell команда должна быть самодостаточной и не зависать от предыдущих команд.

Вывод

В общем плюсов больше чем минусов. Добавляйте в свои прошивки UART-Shell. Никто не заставляет вас оставлять shell в релизной сборке, однако в отладочной сборке shell должен быть обязательно. Shell того стоит. CLI позволяет обеими руками по локоть забраться в исполняемый процесс и найти там любой бит при этом не помешав самому потоку исполнения кода. Эта технология позволит вам говорить с устройством на понятном обоим сторонам языке.

Links

https://habr.com/ru/post/247507/
https://habr.com/ru/post/127890/