Почему нам нужен 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/
