Комментарии 23
Загрузчик вещь спорная. С одной стороны удобненько. С другой стороны уменьшает надежность, занимает flash, которого может не хватить основной программы. Оправдан, если программатор дорогой как для PIC, но если стоимость программатора как st-link, то может ну его нафиг?
Файловая система плоха тем что флэш очищается блоками. А если у вас нет столько изменяемых данных? Вот у PIC для этих целей есть небольшой EEPROM, может это более выигрышный вариант?
программатор дорогой как для PIC
15$ за программатор с минимальными функциями отладки это дорого?
Одаренный пользователь с программатором может запросто сделать из МК неживой трупик, который только выпаивать и менять на новый. Ну нафиг.
Ну и нормальный загрузчик позволяет передавать потребителю зашифрованную прошивку и проверять контрольную сумму флешки перед тем как запускать основной код. Бывает полезно.
Как раз если окирпичить загрузчик, то потом для восстановления понадобится программатор. Никак не наоборот.
Для флеша есть программная реализация EEPROM (я подсмотрел ее у Infineon, но вообще довольно известное решение):
берем один блок флеш (скажем, 16кб), стираем его и пишем туда блок наших параметров (скажем, 200 байт) с некоторым заголовком\чексуммой. Если надо поменять параметры - не стираем флеш а пишем в свободное место измененный блок параметров (еще 200 байт). И так пока место не закончится. Когда закончилось - стираем все 16кб и пишем наши 200 байт в начало.
При загрузке соответственно - читаем из флеша блоки параметров по 200 байт пока чексумма совпадает, последний из прочитанных считаем актуальным.
Из всего перечисленного согласился бы только с необходимостью тестов и диагностики, но не таких какие описаны в тексте.
Тесты не модульные, а интеграционные. Диагностика не через CLI, а через специализированные протоколы и клиенты с GUI и развитой мат. обработкой.
Сторожевой таймер вещь полезная, но бывает что зависнуть полезнее чем постоянно сбрасывать систему. Так что тут по обстоятельствам надо решать о применимости. А с другой стороны вотчдогов может быть несколько независимых в одном чипе и они не для сброса при зависаниях могут быть предназначены, а например для реакции на нарушение событийности в реальном времени.
Загрузчик в реальности может не помочь, а усложнить поддержку. Обслуживающий персонал может быть недоволен необходимостью носить с собой компьютер или какой-то гаджет для перепрошивки и изучать сам процесс перепрошивки. Часто требуют просто прислать новую плату, но только чтобы не перепрошивать на месте, и все выполнить с помощью одной отвертки.
Интерфейс CLI сложен и неэффективен. На замену ему все больше приходят инструменты вроде STM32CubeMonitor, FreeMaster, SystemView, uC/Probe...
Диагностика через CLI тоже будет очень примитивной. Например через него невозможно в реальном времени оценить характеристику шума АЦП микроконтроллера по всем каналам, построить гистограмму, оценить функцию распределения и увидеть вклад неучтенных помех. Для этого что-то вроде Matlab применяют и диагностические протоколы. Т.е. CLI можно смело пропускать в пользу более эффективных инструментов.
Я бы добавил в обязательный список - шифрование бинаря, передаваемого заказчику для обновления, с помощью стандартных алгоритмов. Ключ для расшифровки должен лежать либо во внешней TPM, либо в том месте памяти микроконтроллера, куда непросто забраться человеку со стороны. Особенно если устройство умеет ходить в интернет. Иначе можно такой шикарный ботнет получить...
И вдогонку к шифрованию: использование какой-нибудь стандартной процедуры замены ключа/сертификата. Никакой самописной отсебятины.
А CLI штука неоднозначная: нормальной защиты от несанкционированного доступа в МК обычно не делают, а наломать дров и очень дорогого металла при наличии такого интерфейса можно очень много. У заказчиков частое требование: отсутствие пользовательского интерфейса на устройстве.
Ну-ну. Современные микроконтроллеры не доросли пока ни до TPM ни до поддержки современных методов шифрования. Это удел микрокомпьютеров. Пример esp8266 не может отправлять сообщения в телеграмм, так как не поддерживает современные методы шифрования. Более новая esp32 может. Но TPM там точно нет. И это мы говорим можно сказать о топах среди современных микроконтроллеров по соотношению распространенности и производительности
Это сильное заблуждение.
Аналог TPM в микроконтроллерах есть давно.
Вот в этой статье я применял криптосопроцессор для WEB сервера на микроконтроллере с Cortex-M4.
Скорость шифрования по алгоритму AES-256 GCM была 57 мегабайт в сек! при частоте ядра 240 МГц. Т.е. аппаратное шифрование очень быстрое в микроконтроллерах.
Так же как и в TPM в микроконтроллере ключи не хранятся в открытом виде, а проходят процедуру заворачивания.
Там есть и эллиптическая криптография. Так что все в порядке.
В этой статья я бы хотел обобщить
А вот обобщать как раз не надо. ) Задачи бывают разные. Для некоторых ничего из перечисленного вообще неприменимо. Разве что, вотчдог с небольшими оговорками.
Кроме того, как было замечено выше, полезных инструментов больше чем перечислено.
Если позволяет специфика, то можно прямо на "боевой" плате развести отладчик и вывести USB на корпус устройства; да, далеко не в любом случае можно такой девайс поставлять заказчику, но если можно - то это очень сильно облегчает отладку устройства в собранном виде.
Future proof - продумать, что может потребоваться улучшать. Футпринт с расчетом, что может потребоваться проц пожирнее; разъемы с небольшим запасом пинов, интерфейсы с запасом по скорости - тут сложно какой-то общий совет дать, но в целом подумать "а что мы можем захотеть поменять" полезно.
Если устройство в достаточно крупной серии, то загрузчику хорошо бы поддерживать какой-то вариант "обновить все девайсы разом", просто перетыкивать кабель больше 10 раз само по себе напряжно; перепрошивание через интернет или беспроводным способом тоже может быть полезно.
Возможность делать "factory reset" - с откатом на гарантированно рабочую прошивку, если предполагаются регулярные обновления.
Если делается какой-то вариант настроек (не суть, с файловой системой или без), то должен быть способ до этих настроек дотянуться без залезания в отладчик. Может через отдельную утилиту, может через CLI, может имитацией USB Mass Storage - не очень важно, главное, чтобы это можно было сделать не через перепрошивание. Ну и возможность "скачать" настройки с девайса тоже полезна.
CLI необязательно делать "дуплексным", зачастую вполне хватает просто вывода отладочной печати или логов. При отладке устройств, которые управляют собственным питанием, бывает очень полезно. Или полный дамп выдать.
Контроль версий. git, само собой, но и в саму прошивку можно запихать информацию о сборке - хеш коммита, время компиляции, может быть что-то еще. Главное, чтобы не вручную! Это нужно редко, но когда нужно - реально спасает.
Отладочные светодиоды на плате - банально, но про них часто забывают или делают только один, по питанию. Хотя бы два управляемых и разноцветных тоже сильно помогают жить - особенно если никаких других средств диагностики нет. Отладочная пищалка или динамик тоже хорошо, дает более широкий диапазон различимых сигналов :)
Серийный номер и версия платы прямо на текстолите; в идеале наносится автоматизированно.
Тест-поинты на платах и в целом продумывать "как мы это будем тестить автоматизированно" - если, конечно, девайсов планируется на 2-3 штуки.
Про юнит-тесты я писал пост; имхо тестами "на железе" дело ограничиваться не должно.
Нормальные IDE, современные стандарты языков, С++11 вместо С89, статический анализ (ну или сразу Rust, для смелых :)
Заинтриговал заголовок статьи , поэтому и прочитал, но не нашел для себя ничего нового
1Сторожевой таймер - полезная опция , но нужно умело применять и правильно настраивать. В PIC32 да и не только, есть возможность при запуске проанализировать что вызвало сброс МК - питание, вход reset, или сторожевой таймер. Поэтому пишем в лог соответствующее событие
2 Загрузчик функция полезная для обновления ПО. В PIC32 можно защитить область загрузчика от стирания из программы(только программатором можно переписать) - так что окирпичивание происходит крайне редко. На практике был всего один раз у пользователя. он вернул устройство , заявляя что оно перестало работать после обновления. Перепрошили программатором - все заработало. А что было причиной - пользователь молчит.
3 Файловая система NorFlashFs Здесь смешали в кучу функции файловой системы и хранение настроек. К хранение настроек нужно подходить с умом: настройки можно разместить во внешней памяти - тогда будет тратиться время на чтение. Можно разместить во внутреннем FLASH контроллера - получим быстрый доступ к настройкам. Большие объемы логов и другой информации удобнее хранить во внешней памяти. А файловая система нужна для обеспечения работы совместно с ПО более высокого уровня.
4 Модульные тесты
5 Health Monitor (HM) Монитор вещь хорошая, особенно если устройство сложное . Для простого устройства достаточно двухцветного светодиода
6 Command Line Interface (CLIшка) Командный интерфейс нельзя расматривать в отрыве от монитора. командная строка нужна продвинутым пользователям во время отладки и настройки системы. Рядовому пользователю она не особо нужна.
А где про эту самую "Файловая система для хранения многочисленных параметров" можно почитать? У меня идеи дальше структуры в RAM, которую можно писать во FLASH и загружать оттуда ничего на ум не приходит пока...
А где про эту самую "Файловая система для хранения многочисленных параметров" можно почитать?
Как пример реализации (есп32 поддерживает пары ключ-значение из коробки): https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/storage/nvs_flash.html
Про 5 HM и 7 Диагностика - вполне можно отказаться если устройство постоянно общается с внешним компом. Достаточно на стороне ПК вести логгирование принятой/переданой информации, и в случае возникновения проблем диагностика и мониторинг сводится к анализу логов.
ps: а чем ubifs не нравиться?
ubifs не годится для микроконтроллеров с особой организацией Flash.
Например для Flash c мелко-граннулированным Error Code Correction (ECC) или для Flash где после стирания возникает неопределенное состояние.
Гораздо более приспособлена для таких чипов STfs
всё это хорошо для сферіческого проекта
а в реальності это дополнительные компоненты и человекочасы которые комуто надо оплачивать.
по своим проектам могу сказать что основной функционал занимает 40-60% программы, а все остальные навороты после отладки не очень то и нужны.
Энергонезависимая Key-Value Map(ка). Есть десятки способов ее реализовать. Файловая система для хранения многочисленных параметров: счетчик загрузок, наработки на отказ, настройки трансиверов, серийные номера и прочее. Это позволит не настраивать устройство заново каждый раз после пропадания питания.
Есть и другой подход: хранить «настройки трансиверов» на стороне контроллера. (Или делать вид, что это так, поскольку ресиверы всё-таки могут хранить состояние, но это рассматривается как нежелательный эффект, а все порты и прочее перезаписываются). Тогда два разных сюрвейера берут каждый свой контроллер (вариант: открывают на одном и том же контроллере каждый свой проект), цепляются поочерёдно к одному и тому же приёмнику, он автоматически приходит в консистентное состояние, в соответствии с настройками.
Я слышал, что некоторые дилеры преподносили такой подход конечным юзерам как конкурентное преимущество (и он таковым, на мой взгляд, и является).
Для меня "поднятие" новой платы начинается с трех вещей -
Поморгать светодиодом (убедиться что работает хоть что-то).
Убедиться что работает чтение и вывод с ком-порта
Портировать на нее MemsVisual
MemsVisual - мой велосипед который по сути реализует пункт 3 из поста (энергонезависимую мапу параметров), но со временем был расширен и включает в себя все остальные пункты - кроме параметров которые сохраняются во флеш есть еще параметры которые находятся в оперативке, имена параметров и их типы (а так же значения масок и enumов) включены в прошивку, так что мы нажимаем "импорт параметров" и получаем и диагностику\интерфейс управления, и возможность конфигурации всех параметров и даже загрузчик, всё это по USB\RS\Ethernet (смотря что есть на плате).
Hidden text
Я конечно не буду рекомендовать всем делать что-то похожее, но лично для меня это офигенно удобный инструмент и к CLI даже притрагиваться после него не хочется.
7 атрибутов хорошего firmware