11 Aтрибутов Хорошего Firmware

В этой статья я бы хотел перечислить и обсудить некоторые общие системные поведенческие атрибуты хорошего firmware (прошивки) для микроконтроллерных проектов, которые не зависят от конкретного приложения или проекта. Некоторые атрибуты могут показаться очевидными однако в 9 из 10 российских embedded компаний нет ни одного из перечисленных атрибутов.

0.Микросекундный UpTime счетчик (камертон)

В хорошей прошивке должен быть точный аппаратный микросекундный up-time счётчик. Это для программных компонентов которые используют время. Например TimeStamp(ы) для логирования, limiter, планировщик, функции выдержки пауз, LoadDetect. Реализовать этот счетчик можно на SysTick таймере или на периферийном Timer.

1. Сторожевой таймер (сторожевой пёс)

Прошивка может зависнуть при некорректных входных данных или в результате стресс тестирования. Сторожевой таймер позволяет автоматически перезагрузиться и устройство не останется тыквой.

2. Загрузчик (BootLoader)

Программатор есть далеко не всегда. Программатор часто не видит микроконтроллер из-за статического электричества или из-за длинного шлейфа. Часто программатор в одном единственном экземпляре на всю компанию в целом здании. Загрузка программатором это чисто developer(ская) прерогатива. У Customer нет и никогда не будет отладчика и особого шлейфа для PCB. Загрузчик по UART позволит записать новый артефакт на дешевом переходнике USB-UART. Также загрузчик позволит наладить DevOps и авто-тесты внутри компании. В идеале загрузчик должен уметь загрузить бинарь по всем доступным интерфейсам которые только есть на плате (PCB) USB, UART, RS485, RS485,CAN, LIN, BLE, 100BaseTX, WiFi, LoRa и пр.  Подробнее про хороший загрузчик можно почитать тут https://habr.com/ru/articles/754216/

3. NVRAM (числохранилище)

Энергонезависимая Key-Value Map(ка) или NVRAM, FlashFs. Есть десятки способов ее реализовать. Это простая файловая система для хранения многочисленных параметров: калибровочные коэффициенты, ключи шифрования, IP адреса, TCP порты, счетчик загрузок, наработки на отказ, настройки трансиверов, серийные номера и многое другое. В моей нынешней прошивке уже 60 параметров. Это позволит не настраивать устройство заново каждый раз после пропадания питания и не плодить зоопарк прошивок с разными параметрами. Устройство всегда можно будет до-программировать уже в run-time(е) просто исполнив несколько команд в CLI. Также FlashFS позволяет передать сообщение от приложения загрузчику и наоборот. Про это есть пара отдельных текстов https://habr.com/ru/post/706972/ и этот https://habr.com/ru/articles/732442/

4. Модульные тесты (скрепы)

Тесты позволяют делать безопасное перестроение упрощение кода, локализовать причины сбоев. Тесты выступают как документация к коду. Код тестов должен быть встроен прямо внутрь кода прошивки. По крайней мере для Debug сборок. Тесты можно запускать как при старте питания так и по команде из CLI. https://habr.com/ru/post/698092/

5. Health Monitor (медбрат)

Это отдельная задача, поток или периодическая функция, которая периодически проверяет все компоненты, счетчики ошибок и в случае, если возникли какие-то сбои, HM как-то сообщает об этом пользователю. HM должен работать непрерывно. Например при ошибке посылает красный текст в UART-CLI а при предупреждении -желтый текст. Health монитор повысит надежность изделия в целом и позволит найти ошибки, которые пропустили модульные тесты.

6. Full-Duplex Command Line Interface (CLIшка)

CLI наверное самое полезное. Как её только не называют: "CUI", "TUI", "командный интерфейс", "Shell", "Bash подобная консоль", Real Time Terminal (RTT), "Терминал", "Printf отладка", "CLI", "Консоль", UART Debug Termianl. Это уже намекает на её cупер полезность. Однако суть одна. Это текстовый интерфейс командной строки поверх UART(или UDP, TCP, RS232). Подойдет любой Full/Half Duplex интерфейс. Чтобы общаться с устройством на человеческом языке. Запрос-ответ. Как в Linux только в случае с микроконтроллером.

С помощью CLI можно запускать модульные тесты софта и железа, просматривать куски памяти, отображать диагностические страницы, управлять GPIO, пулять пакеты в SPI, UART, I2C, 1Wire, I2S, SDIO, CAN, испускать PWM(ки), включать/выключать таймеры. В общем CLI для тотального управления гаджетом. Стоит заметить, что CLI это, к слову, единственный способ отлаживать прошивку в микроконтроллерах без JTAG (AVR, ESP32).

Да и отладка по JTAG это тоже так себе подход. Ведь любая точка останова нарушает тайминги и с пошаговой отладкой вы отлаживаете уже не ту программу, что будет работать в реальности. Только с CLI можно делать Non Invasive Debug. Когда есть CLI(шка), команды установки уровней логирования и чтения памяти по адресу, то отпадает даже необходимость в пошаговой отладке по JTAG.  Вернее JTAG/SWD понадобится только для отладки UART и запуска CLI. Далее отладка только через CLI.

С помощью CLI вы сможете до-программировать поведение устройства уже после записи самой прошивки во Flash. Можно хранить CLI-скрипты на SD карте и запускать их подобно *.bat файлам. Как OS устанавливает и запускает утилиты. Просто подключившись к UART через TeraTerm/Putty/HTerm и отправив несколько команд. Также CLI выступает как интерпретатор команд. А без CLI вам бы пришлось варить еще кучу сборок с какой-то специфической функцией на 1 раз. А потом поддерживать на плаву этот зоопарк проектов.

Посмотрите какая классная CLIшка у российского Flipper Zero
https://www.youtube.com/watch?v=ImQ_TO92kGM&t=937s (начало 15:00) нет только раскраски логов в красный, желтый, синий, зелёный, розовый.

Посмотрите какая классная CLIшка у швейцарского U-Blox ODIN C099-F9P https://www.youtube.com/watch?v=5MXh63XDfdY&t=15s (начало 7:15)

Посмотрите какая классная CLIшка у китайского STM32 устройства NanoVNA V2

Zephyr RTOS из коробки со своей собственной CLI.

Очевидно, что оглушительный успех этих продуктов в значительной мере определен наличием удобной и развитой CLI.

Даже авторитетные авторы FreeRTOS, рекомендуют использовать CLI.

https://freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_CLI/FreeRTOS_Plus_Command_Line_Interface.html

Про это есть отдельный пост https://habr.com/ru/post/694408/

7. Диагностика 

У каждого компонента есть внутренние состояния: Black-Box Recorder, режимы микросхем, драйверов, какие-то конкретные переменные: up-time счетчики, дата, время сборки артефакта, версия, ветка, последний коммит. Всё это надо просматривать через CLIшку. Для этого и нужна подробная диагностика. Без CLI диагностики прошивок получилось бы то же самое, если у медицины отнять МРТ, УЗИ, рентгеновские аппараты и даже термометры.

https://habr.com/ru/post/681280/

Прошивка без диагностики это как автомобиль без приборной панели, зеркал, с грязным лобовым стеклом без дворников. Пробовали на таком ездить?

8 Аутентификация бинаря (optional)

Рано или поздно придется защищать гаджет от того чтобы на него не накатили чужеродный софт и не превратили его в BotNet. Можно поставить внешний сторожевой таймер и он будет сбрасывать прошивки, которые не догадываются о реальной схемотехнике. А можно добавить в загрузчик Decrypter, который будет записывать только тот артефакт, который после расшифровки содержит валидную контрольную сумму и подпись.

9 Black-Box Recorder (Чёрный ящик)

У него много имен: черный ящик. LogBook, BlackBox, Прошивка может записывать логи не только в UART(который может никто не смотреть) но и в NorFrash или лучше SD карту. Если организовать циклический массив-строк на N-записей, то можно записывать, например, последние M минут работы. Лог сообщения с TimeStamp(ами). А затем можно делать post-processing логов для расследования инцидентов.

10 Переход в энергосбережение

Можно по команде из UART-CLI понизить частоту системной шины до минимума. Отключить тактирование от ненужной периферии и таким образом микроконтроллер перейдет в режим низкого энергопотребления. Это особенно важно если устройство работает от батареи.

Вывод

Как по мне эти 11 атрибутов являются просто джентльменским набором любой нормальной современной взрослой промышленной прошивки. Своего рода коробочка в которую можно положить любой функционал. Если у Вас в репозитории и прошивке всего этого нет, то ,наверное, говорить о разработке какого либо устройства не следует. Как ни крути, но сначала надо поднять систему. Писать прошивку без этих 7-10 свойств - это как ходить по улице без одежды.

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

Links
-->Command line interpreter на микроконтроллере своими руками: https://habr.com/ru/post/247507/
-->DevOps для производства Firmware: https://habr.com/ru/post/656449/

-->17 атрибутов хорошей PCB: https://habr.com/ru/post/655879/