Comments 114
Загрузчик вещь спорная. С одной стороны удобненько. С другой стороны уменьшает надежность, занимает flash, которого может не хватить основной программы. Оправдан, если программатор дорогой как для PIC, но если стоимость программатора как st-link, то может ну его нафиг?
Файловая система плоха тем что флэш очищается блоками. А если у вас нет столько изменяемых данных? Вот у PIC для этих целей есть небольшой EEPROM, может это более выигрышный вариант?
программатор дорогой как для PIC
15$ за программатор с минимальными функциями отладки это дорого?
По сравнению с 2$ за st-link v2? Да. Или скажем к программатору rp2040 в качестве которого может выступать любой микрокомпьютер с gpio.
У нас на работе 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 загрузчик.
Программатор-отладчик MSP-FET на Али стоит 25 долл, работает отлично и сходу подхватывается студией — не умеет только жечь фуз защиты, если же вам хочется именно фирменный шлейф из США за 60 долл (плюс транспортные расходы, сейчас заказать из США совсем сложно) — это ваши проблемы, и к дороговизне средств разработки не имеет отношения.
Чтобы пользоваться их заводским BackDoor загрузчиком надо удерживать DIO13 в 0.0V при reset. Чтобы микроконтроллер прыгнул в BackDoor загрузчик. Т.е автоматизировать прошивку из скриптов уже не возможно. Надо чтобы кто-то нажимал и удерживал кнопку.
Как вы через UART подадите напряжение на физический Pin? Да еще так чтобы он при reset оставался в 0V на 3 сек.
Вот и приходится делать custom-made загрузчик и CLI для перехода в него чтобы делать все операции автоматически на нажимая кнопок, которых даже на custom-made PCB нет.
Посмотрите схему подключения ESP32. Там тоже самое.
Чтобы пользоваться их заводским BackDoor загрузчиком надо удерживать DIO13 в 0.0V при reset. Чтобы микроконтроллер прыгнул в BackDoor загрузчик. Т.е автоматизировать прошивку из скриптов уже не возможно. Надо чтобы кто-то нажимал и удерживал кнопку.
DTR/RTS чем не угодили?
Ситуация такова, что нет доступа к плате.
Нет доступа к пину, который переключает исполнение на BackDoor загрузчик. Одна плата на 3 разработчика подключена в офисе к NetTop компьютеру (зомбику) по UART. У разработчиков, сидящих на карантине, есть только Win Remote Desktop Connection и доступ к CLI через Putty.
И в этих условиях надо после каждого коммита в репу автоматически обновить приложение на target(e), прогнать тесты.
Если все же первое — то что вам мешает вывести этот пин в разъем программирования и повесить на него какую угодно сложную схему со стороны программатора? Ну или встроить программатор с этой сколь угодно сложной схемой в устройство и вывести USB наружу?
Про сложности жизни с одной платой и nettop и RDP и СИТУАЦИЮ пожалуйста, не рассказывайте — это ником образом не относится к проблеме «бутлоадер запускается только внешним пином» и говорит только о проблемах в компании, коль она не смогла обеспечить своих же разрабов тремя платками производимых ей же устройств, чтобы они могли спокойно унести их по домам.
Т.е. одна ситуация «нет возможности прошить автоматически, потому что бут включается по уровню на пине» решается правками в схемотехнике, от самых простых (пусть юзер кнопку нажимает) до средних (ставим в качестве USB-UART FT232, которую сначала переключаем в GPIO, перезагружаем МК и вводим его в бут, а потом переключаем в UART и прошиваем), до более сложных (собираем на транзисторах, резисторах и конденсаторах схему, которая например при быстром открытии порта два раза подряд, поднимает уровень на ноге на три секунды и перезагрузит устройство).
Вторая ситуация «чет надо как-то прошить устройство в офисе, но там некому нажать кнопку» решается накостыливанием для конкретного устройство — взять, например, в качестве моста FT2232D, второй уарт который конфигурируется как GPIO и вешается на питание/ресет/бут/что угодно, там штук 6 GPIO. Или просто FT232 подключается в другой порт компа и так же используются как GPIO. Все это соединяется проводками и три разработчика счастливы. Не нравятся костыли и проводки? Ну так см. п. выше.
Для студента ардуинщика не привыкшего покупать ничего дороже 2$, я еще могу понять такой аргумент. Как по мне, для конторы разработчика всё что меньше 100$ (плюс минус) это расходник вроде картриджа для принтера.
Вот что тебя ждёт.
Для конторы разработчика программатор нужен не один. Один разработчику, один монтажнику, чтобы заливал прошивку и не отвлекал разработчика. Это если у вас за пуско-наладку только один человек отвечает. 1-2 должны быть в запасе, на случай выхода из строя, чтобы все не остановилось. Если вы решили отдать на аутсорс часть разработки, то должны обеспечить оборудованием еще и аутсорсера.... А еще это можно умножить на количество производителей чипов с которыми работает контора. И бюджет становится приличным.
По сравнению с 2$ за st-link v2?
Да! я его просто внутри устройства решил оставлять:)
У нас очень дорогой программатор.
Одаренный пользователь с программатором может запросто сделать из МК неживой трупик, который только выпаивать и менять на новый. Ну нафиг.
Ну и нормальный загрузчик позволяет передавать потребителю зашифрованную прошивку и проверять контрольную сумму флешки перед тем как запускать основной код. Бывает полезно.
Как раз если окирпичить загрузчик, то потом для восстановления понадобится программатор. Никак не наоборот.
правильный загрузчик окирпичить как раз таки почти нереально.
И думаю речь шла о том, что программатором можно по незнанию/криворукости какой нибудь FUSE/Option byte выставить и контроллер на помойку.
а высоковольтным программатором разве нельзя восстановить FUSE ?
ну, во-первых, далеко не у всех мк есть такая возможноть. во-вторых, это требует демонтажа мк, что далеко не всегда возможно.
На плате закладывать возможность внутрисхемного программирования... Нет, не слышали?
чукча не читатель, чукча писатель(с)
Но все же поясню. После неудачного конфигурирования мк доступ к его памяти тем или иным способом может быть заблокирован. Более того, может быть отключен сам интерфейс для внутрисхемного программирования. В таких случаях некоторые мк позволяют прошить память на низком уровне, но далеко не все.
Дополню кейс - в памяти мк может храниться не только прошивка, но и, например, калибровочные параметры (да хоть та же NORFlashFS, приведенная в статье). Прошивка в данном случае может отличаться от от банального запустить - открыть файл - прошить ибо потребуется указать какие области стирать, куда писать и тп. При неправильных действиях девайс может не стать кирпичом, но будет требовать калибровки в лабораторных условиях.
А при прошивке через загрузчик пройдет помеха по питанию и будет кирпич. У дешёвых стмов - один сегмент флэша и высушить весла на нем вообще элементарно.
Передача по помехоустойчивому каналу, контроль целостности данных, выделенный в отдельный сектор загрузчик, который не может себя перезаписать.
Не помню как в STM8 но даже в stm32l010 можно выделить бутлоадер в защищенную часть.
Не иметь отдельно от бутлоадера два отдельных сегмента под версии прошивки - это какая-то дичь.
UART это не RS-232 или RS-485 и предназначен для внутренних коммуникаций, а не для торчания наружу устройства
ECU контроллер управления 4мя газовыми форсунками от KME управляется и конфигурируется как раз по UART, что выходит на harness.
https://kme.eu/kme/en/produkt/nevo-sky-sun-ecu-2/
UART это не RS-232 или RS-485 и предназначен для внутренних коммуникаций, а не для торчания наружу устройства
Напишите это компании Вега Абсолют.
http://vega-absolute.ru/production/monitoring-transporta/vega-mt-x-lte/
Для флеша есть программная реализация EEPROM (я подсмотрел ее у Infineon, но вообще довольно известное решение):
берем один блок флеш (скажем, 16кб), стираем его и пишем туда блок наших параметров (скажем, 200 байт) с некоторым заголовком\чексуммой. Если надо поменять параметры - не стираем флеш а пишем в свободное место измененный блок параметров (еще 200 байт). И так пока место не закончится. Когда закончилось - стираем все 16кб и пишем наши 200 байт в начало.
При загрузке соответственно - читаем из флеша блоки параметров по 200 байт пока чексумма совпадает, последний из прочитанных считаем актуальным.
У меня как раз так и реализовано.
https://github.com/aabzel/ti_mcu_code_base/tree/master/Drivers/flash_fs
Называется endurance optimization.
FRAM еще до кризиса была самой дорогой памятью. Написать endurance optimization для NorFrash дешевле тем более что сорцы есть.
https://github.com/aabzel/ti_mcu_code_base/tree/master/Drivers/flash_fs
Тем более что для FRAM чипов нужны 4 Pin(а) микроконтроллера так как они все требуют SPI. Лучше пользоваться OnСhip NorFrash(ом).
Есть FRAM и с I2C интерфейсом, с этим нет проблем. Написать щадящую систему хранения для Flash несложно, но я бы все равно не стал ее использовать в местах, где надо хранить данных много и часто. Например, вы меряете какой-то показатель (температуру, расход энергии и т.п.) и храните исторические данные за какой-то период.
Так если данных мало может лучше использовать микроконтроллер сразу с FRAM и не связываться с eeprom.
Дополнительное место на плате, дополнительный элемент в BOM, дополнительная логистика, дополнительная точка отказа и тестирования, дополнительная стоимость. Нет, спасибо, я лучше во флеш.
Я сам это велосипед изобрёл 15 лет назад, когда кольцевой архив для АСУТП на 8Мб флеше сочинял ;)))
NOR память очищается блоками? Думал, что NAND.
А вот писать логи во flash или SD, квк предлагает автор, идея сомнительная. Число циклов записи ограничено. (вот в Теслах уже дописались однажды)...
Файловая система плоха тем что флэш очищается блоками.
Для этого поверх NOR-Flash запускают NVRAM(ки)
быстрая
https://habr.com/ru/articles/732442/
компактная
https://habr.com/ru/articles/706972/
Из всего перечисленного согласился бы только с необходимостью тестов и диагностики, но не таких какие описаны в тексте.
Тесты не модульные, а интеграционные. Диагностика не через CLI, а через специализированные протоколы и клиенты с GUI и развитой мат. обработкой.
Сторожевой таймер вещь полезная, но бывает что зависнуть полезнее чем постоянно сбрасывать систему. Так что тут по обстоятельствам надо решать о применимости. А с другой стороны вотчдогов может быть несколько независимых в одном чипе и они не для сброса при зависаниях могут быть предназначены, а например для реакции на нарушение событийности в реальном времени.
Загрузчик в реальности может не помочь, а усложнить поддержку. Обслуживающий персонал может быть недоволен необходимостью носить с собой компьютер или какой-то гаджет для перепрошивки и изучать сам процесс перепрошивки. Часто требуют просто прислать новую плату, но только чтобы не перепрошивать на месте, и все выполнить с помощью одной отвертки.
Интерфейс CLI сложен и неэффективен. На замену ему все больше приходят инструменты вроде STM32CubeMonitor, FreeMaster, SystemView, uC/Probe...
Диагностика через CLI тоже будет очень примитивной. Например через него невозможно в реальном времени оценить характеристику шума АЦП микроконтроллера по всем каналам, построить гистограмму, оценить функцию распределения и увидеть вклад неучтенных помех. Для этого что-то вроде Matlab применяют и диагностические протоколы. Т.е. CLI можно смело пропускать в пользу более эффективных инструментов.
в Low-power продуктах UART специально отключают
Когда есть развитая 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 и прочее.
Когда ты управляешь компьютером через GUI(ню) твои действия ограничены фантазией разработчика GUI(ни)
Когда ты управляешь компьютером через CLI(шку), то твои действия ограничены твой фантазией.
Watch dog на мой взгляд нужен точно, чтобы гарантированно ребутнуться в стабильное состояние. Дальше могут быть варианты - крутиться дальше, что может быть приемлемо но не всегда. У stm есть варик посмотреть причину ресета, если ресет был по watch dog, то можно показать ошибку, установить необходимые выводы в безопасное состояние и перейти в контролируемое зависание.
Интерфейс CLI сложен и неэффективен.
Когда есть CLI то есть возможность убедиться, что устройство реально работает в run-time(е).
Когда нет CLI, то остается только нанять в штат православного дьякона, чтобы тот благословлял устройства на работу. Это частая практика в российских технологических компаниях.
Чтобы проверить работу устройства run-time достаточно SWD отладчика.
А дальше я использую FreeMaster протокол
Необходимости CLI нет.
Такие вещи как FreeMaster портируются гораздо легче чем CLI.
Если делаете CLI, то вынуждены в нем реализовывать фичи специфичные для дивайса.
А потом отлаживать фичи CLI на самом дивайсе. Итерации идут медленно и не эффективно.
С FreeMaster вам ничего не надо не добавлять ни убавлять от готового стека протокола. Всю инфу о переменных можно взять из .elf файла после компиляции. Ну или в дивайсе реализовать простенькую табличку мапинга переменных, не больше.
Дальше только в клиентском приложении выбирать и кидать на экран нужные переменные и осциллограммы.
Это же гораздо удобнее чем набивать отладочную функциональность (что и есть CLI) в самом фирмваре дивайса и каждый раз по новому для каждого уникального проекта.
Необходимости CLI нет.
Отладка по JTAG это тоже так себе подход. Ведь любая точка останова нарушает тайминги и с пошаговой отладкой вы отлаживаете уже не ту программу, что будет работать в реальности. Только с CLI можно делать Non Invasive Debug. Когда есть CLI(шка), команды установки уровней логирования и чтения памяти по адресу, то отпадает даже необходимость в пошаговой отладке по JTAG.
Речь не о JTAG, а о SWD и RTT.
Писал довольно давно об этом - https://habr.com/ru/post/259205/
Это гораздо менее "инвазивная" технология чем CLI.
На самом деле я имею свой движок CLI.
Его можно посмотреть в моих открытых проектах.
Тащу за собой как старый рудимент.
Интерфейс CLI сложен и неэффективен.
Когда есть UART CLI, то далее plug and play
Когда нет UART CLI, то далее plug and pray
Интерфейс CLI сложен и неэффективен.
UART-CLI это как рука, которая позволяет залезть в прошивку и взять оттуда всё что угодно.
CLI это как строительные леса в только для программирования МК.
Если видели фильм Матрица 1999, то могли заметить, что в Software(ной) компании за окнами строительные леса. В таких фильмах случайных мелочей не бывает.
Это намек на то, что код надо отлаживать отдельной инфраструктурой. В разработке System SW такой инфраструктурой является UART-Shell.
Обслуживающий персонал может быть недоволен необходимостью носить с собой компьютер или какой-то гаджет для перепрошивки и изучать сам процесс перепрошивки.
Если в устройстве есть фотодиод, то прошивку можно загрузить мобильным телефоном мигая кусочком экрана на смартфоне который отображает *.gif файл.
Я бы добавил в обязательный список - шифрование бинаря, передаваемого заказчику для обновления, с помощью стандартных алгоритмов. Ключ для расшифровки должен лежать либо во внешней TPM, либо в том месте памяти микроконтроллера, куда непросто забраться человеку со стороны. Особенно если устройство умеет ходить в интернет. Иначе можно такой шикарный ботнет получить...
И вдогонку к шифрованию: использование какой-нибудь стандартной процедуры замены ключа/сертификата. Никакой самописной отсебятины.
А CLI штука неоднозначная: нормальной защиты от несанкционированного доступа в МК обычно не делают, а наломать дров и очень дорогого металла при наличии такого интерфейса можно очень много. У заказчиков частое требование: отсутствие пользовательского интерфейса на устройстве.
Ну-ну. Современные микроконтроллеры не доросли пока ни до TPM ни до поддержки современных методов шифрования. Это удел микрокомпьютеров. Пример esp8266 не может отправлять сообщения в телеграмм, так как не поддерживает современные методы шифрования. Более новая esp32 может. Но TPM там точно нет. И это мы говорим можно сказать о топах среди современных микроконтроллеров по соотношению распространенности и производительности
Это сильное заблуждение.
Аналог TPM в микроконтроллерах есть давно.
Вот в этой статье я применял криптосопроцессор для WEB сервера на микроконтроллере с Cortex-M4.
Скорость шифрования по алгоритму AES-256 GCM была 57 мегабайт в сек! при частоте ядра 240 МГц. Т.е. аппаратное шифрование очень быстрое в микроконтроллерах.
Так же как и в TPM в микроконтроллере ключи не хранятся в открытом виде, а проходят процедуру заворачивания.
Там есть и эллиптическая криптография. Так что все в порядке.
У меня ESP8266 при использовании mbedtls библиотеки держит связь с сервером по tls 1.2 c относительно современным крипто набором на эллиптических кривых. Правда есть нюанс: tls handshake длится около 7 секунд
Пример esp8266 не может отправлять сообщения в телеграмм, так как не поддерживает современные методы шифрования.
Что значит не поддерживает? Поддерживает прекрасно.
Современные микроконтроллеры не доросли пока ни до TPM ни до поддержки современных методов шифрования.Это удел микрокомпьютеров.
Вы что под современными подразумеваете, атмегу и пики? Уже везде есть и железное ускорение шифрования и производительность реализовать их в софте и часто защищенные области для ключей.
Если разработчики опасаются несанкционированного доступа к CLIшке то есть 2 решения:
1 добавить логин/пароль для активации полной версии CLI.
И паузу после 3х попыток ввода неверного пароля.
2 выпилить CLI из релизной сборки. Но в Debug CLI должна быть.
В этой статья я бы хотел обобщить
А вот обобщать как раз не надо. ) Задачи бывают разные. Для некоторых ничего из перечисленного вообще неприменимо. Разве что, вотчдог с небольшими оговорками.
Кроме того, как было замечено выше, полезных инструментов больше чем перечислено.
Если позволяет специфика, то можно прямо на "боевой" плате развести отладчик и вывести USB на корпус устройства; да, далеко не в любом случае можно такой девайс поставлять заказчику, но если можно - то это очень сильно облегчает отладку устройства в собранном виде.
Future proof - продумать, что может потребоваться улучшать. Футпринт с расчетом, что может потребоваться проц пожирнее; разъемы с небольшим запасом пинов, интерфейсы с запасом по скорости - тут сложно какой-то общий совет дать, но в целом подумать "а что мы можем захотеть поменять" полезно.
Если устройство в достаточно крупной серии, то загрузчику хорошо бы поддерживать какой-то вариант "обновить все девайсы разом", просто перетыкивать кабель больше 10 раз само по себе напряжно; перепрошивание через интернет или беспроводным способом тоже может быть полезно.
Возможность делать "factory reset" - с откатом на гарантированно рабочую прошивку, если предполагаются регулярные обновления.
Если делается какой-то вариант настроек (не суть, с файловой системой или без), то должен быть способ до этих настроек дотянуться без залезания в отладчик. Может через отдельную утилиту, может через CLI, может имитацией USB Mass Storage - не очень важно, главное, чтобы это можно было сделать не через перепрошивание. Ну и возможность "скачать" настройки с девайса тоже полезна.
CLI необязательно делать "дуплексным", зачастую вполне хватает просто вывода отладочной печати или логов. При отладке устройств, которые управляют собственным питанием, бывает очень полезно. Или полный дамп выдать.
Контроль версий. git, само собой, но и в саму прошивку можно запихать информацию о сборке - хеш коммита, время компиляции, может быть что-то еще. Главное, чтобы не вручную! Это нужно редко, но когда нужно - реально спасает.
Отладочные светодиоды на плате - банально, но про них часто забывают или делают только один, по питанию. Хотя бы два управляемых и разноцветных тоже сильно помогают жить - особенно если никаких других средств диагностики нет. Отладочная пищалка или динамик тоже хорошо, дает более широкий диапазон различимых сигналов :)
Серийный номер и версия платы прямо на текстолите; в идеале наносится автоматизированно.
Тест-поинты на платах и в целом продумывать "как мы это будем тестить автоматизированно" - если, конечно, девайсов планируется на 2-3 штуки.
Про юнит-тесты я писал пост; имхо тестами "на железе" дело ограничиваться не должно.
Нормальные IDE, современные стандарты языков, С++11 вместо С89, статический анализ (ну или сразу Rust, для смелых :)
CLI необязательно делать "дуплексным", зачастую вполне хватает просто вывода отладочной печати или логов
Не согласен. Проходили уже это. В таком случае прошивка будет сыпать ниагарский водопад Log(ов). Это будет нагружать/тормозить ход основного приложения.
В случае CLI пользователь сам сможет запросить ту диагностическую страницу, которая ему реально нужна, а не копаться во флуде.
Отладочные светодиоды на плате
Это для статьи "N атрибутов хорошей PCBшки". )
Это если прошивка еще отвечает, плата еще не сгорела, батарейка еще не села и т.д. А логи - вот они!
Ну и логи можно слать по DMA, чтоб не тормозило.
Но в целом это просто еще один вариант, универсальных ответов нет :)
Заинтриговал заголовок статьи , поэтому и прочитал, но не нашел для себя ничего нового
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
Можно прямо сорцы реализации почитать. Там 15 функций всего
https://github.com/aabzel/ti_mcu_code_base/tree/master/Drivers/flash_fs
первая версия была взята из сорцов РКК "Энегрия"
А где про эту самую "Файловая система для хранения многочисленных параметров" можно почитать?
https://habr.com/ru/articles/706972/
https://habr.com/ru/articles/732442/
Про 5 HM и 7 Диагностика - вполне можно отказаться если устройство постоянно общается с внешним компом. Достаточно на стороне ПК вести логгирование принятой/переданой информации, и в случае возникновения проблем диагностика и мониторинг сводится к анализу логов.
ps: а чем ubifs не нравиться?
ubifs не годится для микроконтроллеров с особой организацией Flash.
Например для Flash c мелко-граннулированным Error Code Correction (ECC) или для Flash где после стирания возникает неопределенное состояние.
Гораздо более приспособлена для таких чипов STfs
всё это хорошо для сферіческого проекта
а в реальності это дополнительные компоненты и человекочасы которые комуто надо оплачивать.
по своим проектам могу сказать что основной функционал занимает 40-60% программы, а все остальные навороты после отладки не очень то и нужны.
В среднем embedded компании в СНГ существуют уже 25лет.
За это гигантское время внутри уже должна быть протестированная, переносимая, модульная кодовая база со всеми системные компонентами. Если этого нет, то явно что-то не так с менеджментом.
судя по отсуствію значимой продукции в масс маркете, у нас всё не так с менеджментом.
зато дети красивые (ц)
уже должна быть протестированная, переносимая, модульная кодовая база со всеми системные компонентами
а она и переносится. только ведь прогресс не стоит на месте: новые контроллеры, новые возможности языков, ну и конечно же новые хотелки заказчиков. в результате получается что новая разработка идет по мотивам существующего.
и да, дефицит компонентов накладывает свои нюансы. например у нас получилось так: не смогли купить DCDC нужный, переделали схему питания на другой => в прошивке меняется логика старта, требуется переложить пины => попали на периферию которая в errata, пошел исправлять => отлаженный блок переписан снова. Из постоянного только библиотека обработки сигналов, спасибо ARM за это.
Что-то много 40-60%, наверняка если покопаться куча копипасты и прочего мусора затерялось. Или почти ничего из описаного не использовали. Если делаете свистульку для себя - то да, не нужны эти навороты, у вас и так известный сценарий использования. А у пользователей может оказаться очень богатая фантазия.
Половина этих функций служит для профилактики окирпичивания. Устройство, которое при малейшем чихе превращается в кирпич будет иметь очень низкую репутацию, высокую цену гарантии, низкий спрос. Еще часть - расширение рынка за счет гибкости конфигурирования. Несколько пунктов снижает стоимость тестирования и сервиса. А если все это грамотно реализовано, то может мигрировать из проекта в проект без больших затрат.
У меня не много опыта. Знаю, что можно положить AVR из-за фьюзов. Сам это делал, пытаясь через Atmel ICE организовать возможность дебага в Microchip Studio для китайской Ардуино. Но всё возвращал к работе параллельным прогером, собранным на "бредбоард" из проводов и другой Ардуино. А вот вопрос, а как окирпичить старые 8битные PIC, допустим? Я имел дело с PIC16F18326 и PIC12F675. К последнему, кроме "ватчдога", правила из статьи вообще слабоприменимы. Если только на асме всё как-то написать и то хз...
пик12 и 16 софтварно не окирпичиваются.
для пик16/18 есть старый бутлоадер ан851, и мплаб8 его поддерживает как программатор. только защиты бутлодыря от затирания не стоит и при настройках по умолчанию мк окирпичиваеца
Я имею в виду, то что пички через обычный ICSP программатор шьются из любого состояния. АВРы, например, могут впасть в состояние из которого их достать можно только параллельным программатором, а это почти всегда выпаивание из схемы.
пиководы издавна непонимали мазохизма авр-щиков.)))
Соглашусь 20% времязатрат - реализация целевого функционала, 80% - реализация дуракоусточивости.
Если дураки к устройству не будут допущены, и работает оно между двумя машинами с очень простым интерфейсом и алгоритмом, то действительно - проще вычистить этот алгоритм на стадии разработки. Тем более в такое место воткнется что-то очень маленькое с приоритетом нетребовательности к внешнему электричеству в ущерб логической функциональности.
Но если протокол и алгоритм не позволяет добиться 100% покрытия тестами, то лучше добавить все эти штуки из статьи, а если не лезут - взять чип побольше, пусть и будет на 100р дороже (условно!! читать "немного относительно общей стоимости прибора или потерь в случае его отказа". Любят здесь дословно к цифрам придираться.)
На партии в несколько десятков тыщ изделий, которым 5+ лет кататься в агрессивной внешней среде вдали от разработчиков и питаться в основном от солнца, функционал системы диагностики сопоставим с основным функционалом, или чуть превышает его. Зачем так много? Самое главное - чтобы обоснованно отказывать в гарантии. Затем, чтобы определять потери и порчу устройств третьими лицами. Ну и для дальнейшей оптимизации прошивки и для ловли проблем при сочетании условий, которые на тестовых стендах непросто создать.
Энергонезависимая Key-Value Map(ка). Есть десятки способов ее реализовать. Файловая система для хранения многочисленных параметров: счетчик загрузок, наработки на отказ, настройки трансиверов, серийные номера и прочее. Это позволит не настраивать устройство заново каждый раз после пропадания питания.
Есть и другой подход: хранить «настройки трансиверов» на стороне контроллера. (Или делать вид, что это так, поскольку ресиверы всё-таки могут хранить состояние, но это рассматривается как нежелательный эффект, а все порты и прочее перезаписываются). Тогда два разных сюрвейера берут каждый свой контроллер (вариант: открывают на одном и том же контроллере каждый свой проект), цепляются поочерёдно к одному и тому же приёмнику, он автоматически приходит в консистентное состояние, в соответствии с настройками.
Я слышал, что некоторые дилеры преподносили такой подход конечным юзерам как конкурентное преимущество (и он таковым, на мой взгляд, и является).
Для меня "поднятие" новой платы начинается с трех вещей -
Поморгать светодиодом (убедиться что работает хоть что-то).
Убедиться что работает чтение и вывод с ком-порта
Портировать на нее MemsVisual
MemsVisual - мой велосипед который по сути реализует пункт 3 из поста (энергонезависимую мапу параметров), но со временем был расширен и включает в себя все остальные пункты - кроме параметров которые сохраняются во флеш есть еще параметры которые находятся в оперативке, имена параметров и их типы (а так же значения масок и enumов) включены в прошивку, так что мы нажимаем "импорт параметров" и получаем и диагностику\интерфейс управления, и возможность конфигурации всех параметров и даже загрузчик, всё это по USB\RS\Ethernet (смотря что есть на плате).
Hidden text
Я конечно не буду рекомендовать всем делать что-то похожее, но лично для меня это офигенно удобный инструмент и к CLI даже притрагиваться после него не хочется.
Давно хотел понять в чём там собственно жпа. Купили недавно сетевухи Solarflare в серваки, в стиле best practices пешили обновиться, думали ну уж за 10 лет они точно починили процесс обновления прошивки, тем более на RHEL. Попробовали - падает как и раньше, километровые письма в поддержку, куча советов от них на тему того в какой последовательности обновлять дрова и прошивку, и до сих пор не получилось. Черная магия просто.
Тоже решил вписаться со своим мнением, оно ведь всем необходимо
По поводу загрузчика согласен, он жизненно необходим. С оптимизацией по размеру отлично вмещается в 4кБайт с учетом шифрования и проверку серийника чипа. Жизненно необходим способ исправить ошибку без нарушения целостности корпуса или пломбы.
По поводу всего остального скажу лишь что, как и всегда стоит делать оговорки. В устройствах по с постоянным человеческим доступом все что вы написали актуально, в большинстве серийных устройств, задача которых быть вдали от человеческого контроля и выполнять свою работу, такие требования избыточны и даже мешают. Любой CLI или файловая система там где она не нужна - лишняя вероятность ошибки и потеря памяти. Сами они может уже отлажены годами, как вы написали в комментариях, но связка их с новыми функциями может что-то плохое да спровоцировать. По поводу памяти. Файловая система займет 4-10 кБайт, сам CLI еще несколько кБайт. В случае если цена чипа важна, а таких случаев не меньше чем тех, где важен юзеринтерфейс, нужно отказаться от почти всего что вы предлагаете. (я говорю о случаях когда у вас в доступе 16, 32 или 64 Кбайт памяти флеша суммарно. stm8, китайцы на 8051, миланды земля им пухом, микрон, ну и конечно китайские копии ф103)
Ну и наконец по делу
Статья то класс. Командный интерфейс на мк, в совокупности с файловой системой, ну прям красота. Я заинтересован. Хочу больше скринов! Давайте больше историй про то как cli выручал! Опишите саму файловую, тоже интересно, и со скринами!
Я написал очевидный аргумент, но так как между строк в статье написано "у кого нет cli тот лох", пришлось накидать на вентилятор.
Ждем еще статей
Канадский Bluetooth модуль BC127 компании Sierra Wireless тоже обладает интерфейсом командной строки поверх UART.
11 Aтрибутов Хорошего Firmware