В этой статья я бы хотел перечислить и обсудить некоторые общие системные поведенческие атрибуты хорошего firmware (прошивки) для микроконтроллерных проектов, которые не зависят от конкретного приложения или проекта. Некоторые атрибуты могут показаться очевидными однако в 9 из 10 российских embedded компаний нет ни одного из перечисленных атрибутов.
1. Сторожевой таймер
Прошивка может зависнуть при некорректных входных данных. Сторожевой таймер позволяет автоматически перезагрузиться и устройство не останется тыквой.
2. Загрузчик
Программатор есть не всегда. Программатор часто не видит микроконтроллер из-за статического электричества или из-за длинного шлейфа. Часто программатор в одном единственном экземпляре на всю компанию. Загрузка программатором это чисто developer(ская) прерогатива. У Customer нет и не будет отладчика и особого шлейфа для него. Загрузчик по UART позволит записать новый артефакт на дешевом переходнике USB-UART. Также загрузчик позволит наладить DevOps и авто-тесты внутри компании. В идеале загрузчик должен уметь загрузить бинарь по всем доступным интерфейсам которые только есть на плате (PCB).
3. Файловая система NorFlashFs
Энергонезависимая Key-Value Map(ка). Есть десятки способов ее реализовать. Файловая система для хранения многочисленных параметров: калибровочные коэффициенты, ключи шифрования, IP адреса, TCP порты, счетчик загрузок, наработки на отказ, настройки трансиверов, серийные номера и многое другое. Это позволит не настраивать устройство заново каждый раз после пропадания питания и не плодить зоопарк прошивок с разными параметрами. Устройство всегда можно будет до-программировать уже в run-time(е). Также FlashFS позволяет передать сообщение от приложения загрузчику и наоборот.
4. Модульные тесты (скрепы)
Тесты позволяют делать безопасный рефакторинг, локализовать причины сбоев. Код тестов должен быть встроен прямо внутрь кода прошивки. По крайней мере для Debug сборок. Тесты можно запускать как при старте питания так и по команде из CLI.
5. Health Monitor (HM)
Это отдельная задача, поток или периодическая функция, которая просто периодически проверяет все компоненты, счетчики ошибок и в случае, если возникли какие-то ошибки , HM как-то сообщает об этом пользователю. HM должен работать непрерывно. Например при ошибке посылает красный текст в UART-CLI а при предупреждении -желтый текст. Health монитор повысит надежность изделия в целом и позволит найти ошибки, которые пропустили модульные тесты.
6. Full-Duplex Command Line Interface (CLIшка)
Наверное самое полезное. Это интерфейс командной строки поверх UART. Как в Linux только в случае с микроконтроллером. Это чтобы общаться с устройством на человеческом языке. Запрос-ответ. С помощью CLI можно запускать модульные тесты софта и железа, просматривать куски памяти, отображать диагностические страницы, управлять GPIO, пулять пакеты в SPI, UART, I2C, 1Wire, I2S, SDIO, CAN, испускать PWM ки, включать/выключать таймеры. CLI для тотального управления гаджетом.
С помощью CLI вы сможете до-программировать поведение устройства уже после записи самой прошивки во Flash. Можно хранить CLI-скрипты на SD карте и запускать их как *.bat файлы. Подобно тому как в OS устанавливает и запускает утилиты. Просто подключившись к UART через TeraTerm/Putty и отправив несколько команд. CLI как интерпретатор команд. А без этого вам бы пришлось варить еще кучу сборок с какой-то специфической функцией на 1 раз. А потом поддерживать зоопарк проектов. Когда есть CLI(шка) и команды установки уровней логирования и чтения памяти по адресу, то отпадает даже необходимость в пошаговой отладке по JTAG.
7. Диагностика
У каждого компонента есть внутренние состояния: Black-Box Recorder, режимы микросхем, драйверов, какие-то конкретные переменные: up-time счетчики, дата, время сборки артефакта, версия, ветка, последний коммит. Всё это надо просматривать через CLIшку. Для этого и нужна подробная диагностика.
8 Аутентификация бинаря
Рано или поздно придется защищать гаджет от того чтобы на него не накатили чужеродный софт и не превратили его в BotNet. Можно поставить внешний сторожевой таймер и он будет сбрасывать прошивки, которые не догадываются о реальной схемотехнике. А можно добавить в загрузчик Decrypter, который будет записывать только тот артефакт, который после расшифровки содержит валидную контрольную сумму и подпись.
9 Black-Box Recorder
У него много имен: черный ящик. LogBook, BlackBox, Прошивка может записывать логи не только в UART(который может никто не смотреть) но и в NorFrash или SD карту. Если организовать циклический массив-строк на N-записей, то можно записывать, например, последние M минут работы. Лог сообщения с TimeStamp(ами). А затем можно делать post-processing логов для расследования инцидентов.
Вывод
Как по мне эти 9 атрибутов являются просто джентльменским набором любого разработчика. Своего рода коробочка в которую можно положить любой функционал. Если вам есть что добавить к изложенному списку, то предлагаю обсудить этот в комментариях.
Комментарии (77)
Indemsys
15.03.2022 01:25+6Из всего перечисленного согласился бы только с необходимостью тестов и диагностики, но не таких какие описаны в тексте.
Тесты не модульные, а интеграционные. Диагностика не через CLI, а через специализированные протоколы и клиенты с GUI и развитой мат. обработкой.Сторожевой таймер вещь полезная, но бывает что зависнуть полезнее чем постоянно сбрасывать систему. Так что тут по обстоятельствам надо решать о применимости. А с другой стороны вотчдогов может быть несколько независимых в одном чипе и они не для сброса при зависаниях могут быть предназначены, а например для реакции на нарушение событийности в реальном времени.
Загрузчик в реальности может не помочь, а усложнить поддержку. Обслуживающий персонал может быть недоволен необходимостью носить с собой компьютер или какой-то гаджет для перепрошивки и изучать сам процесс перепрошивки. Часто требуют просто прислать новую плату, но только чтобы не перепрошивать на месте, и все выполнить с помощью одной отвертки.
Интерфейс CLI сложен и неэффективен. На замену ему все больше приходят инструменты вроде STM32CubeMonitor, FreeMaster, SystemView, uC/Probe...
Диагностика через CLI тоже будет очень примитивной. Например через него невозможно в реальном времени оценить характеристику шума АЦП микроконтроллера по всем каналам, построить гистограмму, оценить функцию распределения и увидеть вклад неучтенных помех. Для этого что-то вроде Matlab применяют и диагностические протоколы. Т.е. CLI можно смело пропускать в пользу более эффективных инструментов.
amarkevich
15.03.2022 15:17+1в Low-power продуктах UART специально отключают
aabzel Автор
15.03.2022 18:46Тогда можно реализовать UART на GPIO. Или перевести UART на самую низкую битовую скорость и тактирование.
sav13
16.03.2022 06:07У большинства контроллеров есть пины управления загрузкой. Дернул пин - загрузил прошивку, дальше хоть на одном RT ядре работай )))
aabzel Автор
15.03.2022 15:53Когда есть развитая CLI но нет нужды тратить время-деньги на разработку специализированных бинарных протоколов и GUI(ни) клиента на PC.
Тем более раз встает вопрос о разработки GUI(ни) то ее надо сразу делать для Windows так и для Linux.C CLI(шкой) любую настройку может выполнить user при помощи Putty или TeraTerm. Вся прошивка для него становится не сложнее процесса в OS. Устройство становится полностью самодостаточным.
Есть множество успешных проектов с CLIшкой на уровне firmware.
Flipper Zero, NanoVNA V2, UBlox ODIN C099-F9P, AW100Rx Javad ArWest, U-boot и прочее.
aabzel Автор
15.03.2022 17:08-1Когда ты управляешь компьютером через GUI(ню) твои действия ограничены фантазией разработчика GUI(ни)
Когда ты управляешь компьютером через CLI(шку), то твои действия ограничены твой фантазией.
hedgeov
15.03.2022 02:15+5Я бы добавил в обязательный список - шифрование бинаря, передаваемого заказчику для обновления, с помощью стандартных алгоритмов. Ключ для расшифровки должен лежать либо во внешней TPM, либо в том месте памяти микроконтроллера, куда непросто забраться человеку со стороны. Особенно если устройство умеет ходить в интернет. Иначе можно такой шикарный ботнет получить...
И вдогонку к шифрованию: использование какой-нибудь стандартной процедуры замены ключа/сертификата. Никакой самописной отсебятины.
А CLI штука неоднозначная: нормальной защиты от несанкционированного доступа в МК обычно не делают, а наломать дров и очень дорогого металла при наличии такого интерфейса можно очень много. У заказчиков частое требование: отсутствие пользовательского интерфейса на устройстве.
maledog
15.03.2022 02:38+2Ну-ну. Современные микроконтроллеры не доросли пока ни до TPM ни до поддержки современных методов шифрования. Это удел микрокомпьютеров. Пример esp8266 не может отправлять сообщения в телеграмм, так как не поддерживает современные методы шифрования. Более новая esp32 может. Но TPM там точно нет. И это мы говорим можно сказать о топах среди современных микроконтроллеров по соотношению распространенности и производительности
Indemsys
15.03.2022 10:24+2Это сильное заблуждение.
Аналог TPM в микроконтроллерах есть давно.Вот в этой статье я применял криптосопроцессор для WEB сервера на микроконтроллере с Cortex-M4.
Скорость шифрования по алгоритму AES-256 GCM была 57 мегабайт в сек! при частоте ядра 240 МГц. Т.е. аппаратное шифрование очень быстрое в микроконтроллерах.
Так же как и в TPM в микроконтроллере ключи не хранятся в открытом виде, а проходят процедуру заворачивания.Там есть и эллиптическая криптография. Так что все в порядке.
Nadgob
15.03.2022 17:28У меня ESP8266 при использовании mbedtls библиотеки держит связь с сервером по tls 1.2 c относительно современным крипто набором на эллиптических кривых. Правда есть нюанс: tls handshake длится около 7 секунд
aabzel Автор
15.03.2022 16:20+1Если разработчики опасаются несанкционированного доступа к CLIшке то есть 2 решения:
1 добавить логин/пароль для активации полной версии CLI.
И паузу после 3х попыток ввода неверного пароля.
2 выпилить CLI из релизной сборки. Но в Debug CLI должна быть.
aabzel Автор
15.03.2022 18:073-можно шифровать поток CLIшки. Но для этого придется писать консольную утилиту PC- терминал для расшифровки потока. Так сделано, например, в прошивке MeshTastic (Python CLI)
RTFM13
15.03.2022 02:34+2В этой статья я бы хотел обобщить
А вот обобщать как раз не надо. ) Задачи бывают разные. Для некоторых ничего из перечисленного вообще неприменимо. Разве что, вотчдог с небольшими оговорками.
Кроме того, как было замечено выше, полезных инструментов больше чем перечислено.
Amomum
15.03.2022 03:15+6Если позволяет специфика, то можно прямо на "боевой" плате развести отладчик и вывести USB на корпус устройства; да, далеко не в любом случае можно такой девайс поставлять заказчику, но если можно - то это очень сильно облегчает отладку устройства в собранном виде.
Future proof - продумать, что может потребоваться улучшать. Футпринт с расчетом, что может потребоваться проц пожирнее; разъемы с небольшим запасом пинов, интерфейсы с запасом по скорости - тут сложно какой-то общий совет дать, но в целом подумать "а что мы можем захотеть поменять" полезно.
Если устройство в достаточно крупной серии, то загрузчику хорошо бы поддерживать какой-то вариант "обновить все девайсы разом", просто перетыкивать кабель больше 10 раз само по себе напряжно; перепрошивание через интернет или беспроводным способом тоже может быть полезно.
Возможность делать "factory reset" - с откатом на гарантированно рабочую прошивку, если предполагаются регулярные обновления.
Если делается какой-то вариант настроек (не суть, с файловой системой или без), то должен быть способ до этих настроек дотянуться без залезания в отладчик. Может через отдельную утилиту, может через CLI, может имитацией USB Mass Storage - не очень важно, главное, чтобы это можно было сделать не через перепрошивание. Ну и возможность "скачать" настройки с девайса тоже полезна.
CLI необязательно делать "дуплексным", зачастую вполне хватает просто вывода отладочной печати или логов. При отладке устройств, которые управляют собственным питанием, бывает очень полезно. Или полный дамп выдать.
Контроль версий. git, само собой, но и в саму прошивку можно запихать информацию о сборке - хеш коммита, время компиляции, может быть что-то еще. Главное, чтобы не вручную! Это нужно редко, но когда нужно - реально спасает.
Отладочные светодиоды на плате - банально, но про них часто забывают или делают только один, по питанию. Хотя бы два управляемых и разноцветных тоже сильно помогают жить - особенно если никаких других средств диагностики нет. Отладочная пищалка или динамик тоже хорошо, дает более широкий диапазон различимых сигналов :)
Серийный номер и версия платы прямо на текстолите; в идеале наносится автоматизированно.
Тест-поинты на платах и в целом продумывать "как мы это будем тестить автоматизированно" - если, конечно, девайсов планируется на 2-3 штуки.
Про юнит-тесты я писал пост; имхо тестами "на железе" дело ограничиваться не должно.
Нормальные IDE, современные стандарты языков, С++11 вместо С89, статический анализ (ну или сразу Rust, для смелых :)
aabzel Автор
15.03.2022 17:42CLI необязательно делать "дуплексным", зачастую вполне хватает просто вывода отладочной печати или логов
Не согласен. Проходили уже это. В таком случае прошивка будет сыпать ниагарский водопад Log(ов). Это будет нагружать/тормозить ход основного приложения.
В случае CLI пользователь сам сможет запросить ту диагностическую страницу, которая ему реально нужна, а не копаться во флуде.
aabzel Автор
15.03.2022 17:45Отладочные светодиоды на плате
Это для статьи "N атрибутов хорошей PCBшки". )
Amomum
15.03.2022 18:22+2Это если прошивка еще отвечает, плата еще не сгорела, батарейка еще не села и т.д. А логи - вот они!
Ну и логи можно слать по DMA, чтоб не тормозило.
Но в целом это просто еще один вариант, универсальных ответов нет :)
smart_pic
15.03.2022 06:52+1Заинтриговал заголовок статьи , поэтому и прочитал, но не нашел для себя ничего нового
1Сторожевой таймер - полезная опция , но нужно умело применять и правильно настраивать. В PIC32 да и не только, есть возможность при запуске проанализировать что вызвало сброс МК - питание, вход reset, или сторожевой таймер. Поэтому пишем в лог соответствующее событие
2 Загрузчик функция полезная для обновления ПО. В PIC32 можно защитить область загрузчика от стирания из программы(только программатором можно переписать) - так что окирпичивание происходит крайне редко. На практике был всего один раз у пользователя. он вернул устройство , заявляя что оно перестало работать после обновления. Перепрошили программатором - все заработало. А что было причиной - пользователь молчит.
3 Файловая система NorFlashFs Здесь смешали в кучу функции файловой системы и хранение настроек. К хранение настроек нужно подходить с умом: настройки можно разместить во внешней памяти - тогда будет тратиться время на чтение. Можно разместить во внутреннем FLASH контроллера - получим быстрый доступ к настройкам. Большие объемы логов и другой информации удобнее хранить во внешней памяти. А файловая система нужна для обеспечения работы совместно с ПО более высокого уровня.
4 Модульные тесты
5 Health Monitor (HM) Монитор вещь хорошая, особенно если устройство сложное . Для простого устройства достаточно двухцветного светодиода
6 Command Line Interface (CLIшка) Командный интерфейс нельзя расматривать в отрыве от монитора. командная строка нужна продвинутым пользователям во время отладки и настройки системы. Рядовому пользователю она не особо нужна.
Keroro
15.03.2022 07:55+1А где про эту самую "Файловая система для хранения многочисленных параметров" можно почитать? У меня идеи дальше структуры в RAM, которую можно писать во FLASH и загружать оттуда ничего на ум не приходит пока...
FGV
15.03.2022 08:17+3А где про эту самую "Файловая система для хранения многочисленных параметров" можно почитать?
Как пример реализации (есп32 поддерживает пары ключ-значение из коробки): https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/storage/nvs_flash.html
aabzel Автор
15.03.2022 18:14Можно прямо сорцы реализации почитать. Там 15 функций всего
https://github.com/aabzel/ti_mcu_code_base/tree/master/Drivers/flash_fsпервая версия была взята из сорцов РКК "Энегрия"
FGV
15.03.2022 08:24Про 5 HM и 7 Диагностика - вполне можно отказаться если устройство постоянно общается с внешним компом. Достаточно на стороне ПК вести логгирование принятой/переданой информации, и в случае возникновения проблем диагностика и мониторинг сводится к анализу логов.
kovserg
15.03.2022 10:16+18. Когда firmware открытая и в начале есть текстовая строка с названием, версией и url-ом где её можно скачать.
ps: а чем ubifs не нравиться?
srg27y
15.03.2022 10:35всё это хорошо для сферіческого проекта
а в реальності это дополнительные компоненты и человекочасы которые комуто надо оплачивать.
по своим проектам могу сказать что основной функционал занимает 40-60% программы, а все остальные навороты после отладки не очень то и нужны.
aabzel Автор
15.03.2022 18:29+1В среднем embedded компании в СНГ существуют уже 25лет.
За это гигантское время внутри уже должна быть протестированная, переносимая, модульная кодовая база со всеми системные компонентами. Если этого нет, то явно что-то не так с менеджментом.
srg27y
16.03.2022 11:10+1судя по отсуствію значимой продукции в масс маркете, у нас всё не так с менеджментом.
зато дети красивые (ц)
mctMaks
16.03.2022 12:25уже должна быть протестированная, переносимая, модульная кодовая база со всеми системные компонентами
а она и переносится. только ведь прогресс не стоит на месте: новые контроллеры, новые возможности языков, ну и конечно же новые хотелки заказчиков. в результате получается что новая разработка идет по мотивам существующего.
и да, дефицит компонентов накладывает свои нюансы. например у нас получилось так: не смогли купить DCDC нужный, переделали схему питания на другой => в прошивке меняется логика старта, требуется переложить пины => попали на периферию которая в errata, пошел исправлять => отлаженный блок переписан снова. Из постоянного только библиотека обработки сигналов, спасибо ARM за это.
anka007
15.03.2022 19:37-1Что-то много 40-60%, наверняка если покопаться куча копипасты и прочего мусора затерялось. Или почти ничего из описаного не использовали. Если делаете свистульку для себя - то да, не нужны эти навороты, у вас и так известный сценарий использования. А у пользователей может оказаться очень богатая фантазия.
Половина этих функций служит для профилактики окирпичивания. Устройство, которое при малейшем чихе превращается в кирпич будет иметь очень низкую репутацию, высокую цену гарантии, низкий спрос. Еще часть - расширение рынка за счет гибкости конфигурирования. Несколько пунктов снижает стоимость тестирования и сервиса. А если все это грамотно реализовано, то может мигрировать из проекта в проект без больших затрат.
Albert2009ru
16.03.2022 01:38+1У меня не много опыта. Знаю, что можно положить AVR из-за фьюзов. Сам это делал, пытаясь через Atmel ICE организовать возможность дебага в Microchip Studio для китайской Ардуино. Но всё возвращал к работе параллельным прогером, собранным на "бредбоард" из проводов и другой Ардуино. А вот вопрос, а как окирпичить старые 8битные PIC, допустим? Я имел дело с PIC16F18326 и PIC12F675. К последнему, кроме "ватчдога", правила из статьи вообще слабоприменимы. Если только на асме всё как-то написать и то хз...
hedgeov
16.03.2022 02:11+1На партии в несколько десятков тыщ изделий, которым 5+ лет кататься в агрессивной внешней среде вдали от разработчиков и питаться в основном от солнца, функционал системы диагностики сопоставим с основным функционалом, или чуть превышает его. Зачем так много? Самое главное - чтобы обоснованно отказывать в гарантии. Затем, чтобы определять потери и порчу устройств третьими лицами. Ну и для дальнейшей оптимизации прошивки и для ловли проблем при сочетании условий, которые на тестовых стендах непросто создать.
SShtole
15.03.2022 11:07+1Энергонезависимая Key-Value Map(ка). Есть десятки способов ее реализовать. Файловая система для хранения многочисленных параметров: счетчик загрузок, наработки на отказ, настройки трансиверов, серийные номера и прочее. Это позволит не настраивать устройство заново каждый раз после пропадания питания.
Есть и другой подход: хранить «настройки трансиверов» на стороне контроллера. (Или делать вид, что это так, поскольку ресиверы всё-таки могут хранить состояние, но это рассматривается как нежелательный эффект, а все порты и прочее перезаписываются). Тогда два разных сюрвейера берут каждый свой контроллер (вариант: открывают на одном и том же контроллере каждый свой проект), цепляются поочерёдно к одному и тому же приёмнику, он автоматически приходит в консистентное состояние, в соответствии с настройками.
Я слышал, что некоторые дилеры преподносили такой подход конечным юзерам как конкурентное преимущество (и он таковым, на мой взгляд, и является).
kipar
15.03.2022 11:27+1Для меня "поднятие" новой платы начинается с трех вещей -
Поморгать светодиодом (убедиться что работает хоть что-то).
Убедиться что работает чтение и вывод с ком-порта
Портировать на нее MemsVisual
MemsVisual - мой велосипед который по сути реализует пункт 3 из поста (энергонезависимую мапу параметров), но со временем был расширен и включает в себя все остальные пункты - кроме параметров которые сохраняются во флеш есть еще параметры которые находятся в оперативке, имена параметров и их типы (а так же значения масок и enumов) включены в прошивку, так что мы нажимаем "импорт параметров" и получаем и диагностику\интерфейс управления, и возможность конфигурации всех параметров и даже загрузчик, всё это по USB\RS\Ethernet (смотря что есть на плате).
Hidden text
Я конечно не буду рекомендовать всем делать что-то похожее, но лично для меня это офигенно удобный инструмент и к CLI даже притрагиваться после него не хочется.
mrbald
15.03.2022 16:22-1Давно хотел понять в чём там собственно жпа. Купили недавно сетевухи Solarflare в серваки, в стиле best practices пешили обновиться, думали ну уж за 10 лет они точно починили процесс обновления прошивки, тем более на RHEL. Попробовали - падает как и раньше, километровые письма в поддержку, куча советов от них на тему того в какой последовательности обновлять дрова и прошивку, и до сих пор не получилось. Черная магия просто.
ECRV
16.03.2022 22:52+3Тоже решил вписаться со своим мнением, оно ведь всем необходимо
По поводу загрузчика согласен, он жизненно необходим. С оптимизацией по размеру отлично вмещается в 4кБайт с учетом шифрования и проверку серийника чипа. Жизненно необходим способ исправить ошибку без нарушения целостности корпуса или пломбы.
По поводу всего остального скажу лишь что, как и всегда стоит делать оговорки. В устройствах по с постоянным человеческим доступом все что вы написали актуально, в большинстве серийных устройств, задача которых быть вдали от человеческого контроля и выполнять свою работу, такие требования избыточны и даже мешают. Любой CLI или файловая система там где она не нужна - лишняя вероятность ошибки и потеря памяти. Сами они может уже отлажены годами, как вы написали в комментариях, но связка их с новыми функциями может что-то плохое да спровоцировать. По поводу памяти. Файловая система займет 4-10 кБайт, сам CLI еще несколько кБайт. В случае если цена чипа важна, а таких случаев не меньше чем тех, где важен юзеринтерфейс, нужно отказаться от почти всего что вы предлагаете. (я говорю о случаях когда у вас в доступе 16, 32 или 64 Кбайт памяти флеша суммарно. stm8, китайцы на 8051, миланды земля им пухом, микрон, ну и конечно китайские копии ф103)
Ну и наконец по делу
Статья то класс. Командный интерфейс на мк, в совокупности с файловой системой, ну прям красота. Я заинтересован. Хочу больше скринов! Давайте больше историй про то как cli выручал! Опишите саму файловую, тоже интересно, и со скринами!
Я написал очевидный аргумент, но так как между строк в статье написано "у кого нет cli тот лох", пришлось накидать на вентилятор.
Ждем еще статей
maledog
Загрузчик вещь спорная. С одной стороны удобненько. С другой стороны уменьшает надежность, занимает flash, которого может не хватить основной программы. Оправдан, если программатор дорогой как для PIC, но если стоимость программатора как st-link, то может ну его нафиг?
Файловая система плоха тем что флэш очищается блоками. А если у вас нет столько изменяемых данных? Вот у PIC для этих целей есть небольшой EEPROM, может это более выигрышный вариант?
RTFM13
15$ за программатор с минимальными функциями отладки это дорого?
maledog
По сравнению с 2$ за st-link v2? Да. Или скажем к программатору rp2040 в качестве которого может выступать любой микрокомпьютер с gpio.
aabzel Автор
У нас на работе TI чипы для которых программатор стоит 40 USD=4600 RUR.
Далее кабель переходник USB<->USB micro 6 USB=770 RUR
Затем шлейф https://www.tag-connect.com/product/tc2030-alt-legged-cable-for-use-with-altera-byteblaster
$59.95=6894 RUR
В итоге стоимость первой прошивки отладчиком 106.3 USD или 12265 RUR
Это полтора для работы инженера.
Как раз можно разработать простенький UART загрузчик.
nixtonixto
Если у ваших МСП430 на борту есть УАРТ, то он прекрасно прошивается через него заводским загрузчиком.
Программатор-отладчик MSP-FET на Али стоит 25 долл, работает отлично и сходу подхватывается студией — не умеет только жечь фуз защиты, если же вам хочется именно фирменный шлейф из США за 60 долл (плюс транспортные расходы, сейчас заказать из США совсем сложно) — это ваши проблемы, и к дороговизне средств разработки не имеет отношения.
aabzel Автор
Чтобы пользоваться их заводским BackDoor загрузчиком надо удерживать DIO13 в 0.0V при reset. Чтобы микроконтроллер прыгнул в BackDoor загрузчик. Т.е автоматизировать прошивку из скриптов уже не возможно. Надо чтобы кто-то нажимал и удерживал кнопку.
Как вы через UART подадите напряжение на физический Pin? Да еще так чтобы он при reset оставался в 0V на 3 сек.
Вот и приходится делать custom-made загрузчик и CLI для перехода в него чтобы делать все операции автоматически на нажимая кнопок, которых даже на custom-made PCB нет.
RTFM13
Посмотрите схему подключения ESP32. Там тоже самое.
nixtonixto
Если вам нужен именно бутлодер а не этот самый всегда открытый бэкдур — то кнопку на пине нажмёт тот же, кто нажмёт и Ресет или простенький одновибратор на логике. Схемотехнически ничего принципиально невозможного я здесь не вижу. Не нравится — не ешь, но возможность такую (обновить прошивку пользователем, не покупая программатор за сотню долларов) нам предоставили. А дальше программисты решают — писать свой или пользоваться встроенным. Минусовать в карму-то зачем? Я не хотел вас настолько сильно оскорбить.
RTFM13
Для студента ардуинщика не привыкшего покупать ничего дороже 2$, я еще могу понять такой аргумент. Как по мне, для конторы разработчика всё что меньше 100$ (плюс минус) это расходник вроде картриджа для принтера.
aabzel Автор
Вот что тебя ждёт.
RTFM13
З/п от 5 килоевро и релокация в США/ЕС со средним набором плюшек - и я согласен.
Хотя самое смешное, что такие порядки в жлобских конторах с з/п 50-100 кило деревянных.
maledog
Для конторы разработчика программатор нужен не один. Один разработчику, один монтажнику, чтобы заливал прошивку и не отвлекал разработчика. Это если у вас за пуско-наладку только один человек отвечает. 1-2 должны быть в запасе, на случай выхода из строя, чтобы все не остановилось. Если вы решили отдать на аутсорс часть разработки, то должны обеспечить оборудованием еще и аутсорсера.... А еще это можно умножить на количество производителей чипов с которыми работает контора. И бюджет становится приличным.
RTFM13
Ну хорошо, 10 программаторов 150$. Я за 20 лет работы с пичками еще столько не израсходовал. Это всё еще значительно меньше 1% стоимости рабочего места и, вероятно, меньше расходов на канцтовары. Мы пока говорим про "дорогой программатор для пичков".
sim2q
Да! я его просто внутри устройства решил оставлять:)
aabzel Автор
У нас очень дорогой программатор.
mctMaks
подержите мое пиво)
hedgeov
Одаренный пользователь с программатором может запросто сделать из МК неживой трупик, который только выпаивать и менять на новый. Ну нафиг.
Ну и нормальный загрузчик позволяет передавать потребителю зашифрованную прошивку и проверять контрольную сумму флешки перед тем как запускать основной код. Бывает полезно.
maledog
Как раз если окирпичить загрузчик, то потом для восстановления понадобится программатор. Никак не наоборот.
nafikovr
правильный загрузчик окирпичить как раз таки почти нереально.
И думаю речь шла о том, что программатором можно по незнанию/криворукости какой нибудь FUSE/Option byte выставить и контроллер на помойку.
RustamDzh
а высоковольтным программатором разве нельзя восстановить FUSE ?
nafikovr
ну, во-первых, далеко не у всех мк есть такая возможноть. во-вторых, это требует демонтажа мк, что далеко не всегда возможно.
Vel69
На плате закладывать возможность внутрисхемного программирования... Нет, не слышали?
nafikovr
чукча не читатель, чукча писатель(с)
Но все же поясню. После неудачного конфигурирования мк доступ к его памяти тем или иным способом может быть заблокирован. Более того, может быть отключен сам интерфейс для внутрисхемного программирования. В таких случаях некоторые мк позволяют прошить память на низком уровне, но далеко не все.
Дополню кейс - в памяти мк может храниться не только прошивка, но и, например, калибровочные параметры (да хоть та же NORFlashFS, приведенная в статье). Прошивка в данном случае может отличаться от от банального запустить - открыть файл - прошить ибо потребуется указать какие области стирать, куда писать и тп. При неправильных действиях девайс может не стать кирпичом, но будет требовать калибровки в лабораторных условиях.
nixtonixto
У STM32 (если не ошибаюсь — кроме F1) есть Level 2 защиты, который снять вообще никак нельзя.
IgorPie
А при прошивке через загрузчик пройдет помеха по питанию и будет кирпич. У дешёвых стмов - один сегмент флэша и высушить весла на нем вообще элементарно.
nafikovr
Передача по помехоустойчивому каналу, контроль целостности данных, выделенный в отдельный сектор загрузчик, который не может себя перезаписать.
Не помню как в STM8 но даже в stm32l010 можно выделить бутлоадер в защищенную часть.
Serge78rus
«Одаренный пользователь» и с помощью преобразователя USB/UART, как предлагается в статье, окирпичит устройство с не меньшим успехом, чем с программатором. UART это не RS-232 или RS-485 и предназначен для внутренних коммуникаций, а не для торчания наружу устройства. Поэтому, если требуется обновление прошивки пользователем, то из современных интерфейсов только через USB.
aabzel Автор
ECU контроллер управления 4мя газовыми форсунками от KME управляется и конфигурируется как раз по UART, что выходит на harness.
https://kme.eu/kme/en/produkt/nevo-sky-sun-ecu-2/
aabzel Автор
Напишите это компании Вега Абсолют.
http://vega-absolute.ru/production/monitoring-transporta/vega-mt-x-lte/
kipar
Для флеша есть программная реализация EEPROM (я подсмотрел ее у Infineon, но вообще довольно известное решение):
берем один блок флеш (скажем, 16кб), стираем его и пишем туда блок наших параметров (скажем, 200 байт) с некоторым заголовком\чексуммой. Если надо поменять параметры - не стираем флеш а пишем в свободное место измененный блок параметров (еще 200 байт). И так пока место не закончится. Когда закончилось - стираем все 16кб и пишем наши 200 байт в начало.
При загрузке соответственно - читаем из флеша блоки параметров по 200 байт пока чексумма совпадает, последний из прочитанных считаем актуальным.
aabzel Автор
У меня как раз так и реализовано.
https://github.com/aabzel/ti_mcu_code_base/tree/master/Drivers/flash_fs
Называется endurance optimization.
kovserg
Так если данных мало может лучше использовать микроконтроллер сразу с FRAM и не связываться с eeprom. А вот когда флеша надо много и дешево, тогда имеет смысл всякими изощрениями способами увеличивать срок службы не надёжной памяти.
aabzel Автор
FRAM еще до кризиса была самой дорогой памятью. Написать endurance optimization для NorFrash дешевле тем более что сорцы есть.
https://github.com/aabzel/ti_mcu_code_base/tree/master/Drivers/flash_fs
Тем более что для FRAM чипов нужны 4 Pin(а) микроконтроллера так как они все требуют SPI. Лучше пользоваться OnСhip NorFrash(ом).
kovserg
Есть микроконтроллеры сразу с FRAM
MaximKulkin
Есть FRAM и с I2C интерфейсом, с этим нет проблем. Написать щадящую систему хранения для Flash несложно, но я бы все равно не стал ее использовать в местах, где надо хранить данных много и часто. Например, вы меряете какой-то показатель (температуру, расход энергии и т.п.) и храните исторические данные за какой-то период.
DrGluck07
Во всяких xmega для этого отдельная область флеша, которую так просто не перезапишешь
longtolik
NOR память очищается блоками? Думал, что NAND.
А вот писать логи во flash или SD, квк предлагает автор, идея сомнительная. Число циклов записи ограничено. (вот в Теслах уже дописались однажды)...
aabzel Автор
В cc26x2 NorFlash отчищается блоками по 8kByte.