Чтобы пользоваться их заводскимBackDoor загрузчиком надо удерживать DIO13 в 0.0V при reset. Чтобы микроконтроллер прыгнул в BackDoor загрузчик. Т.е автоматизировать прошивку из скриптов уже не возможно. Надо чтобы кто-то нажимал и удерживал кнопку.
Как вы через UART подадите напряжение на физический Pin? Да еще так чтобы он при reset оставался в 0V на 3 сек.
Вот и приходится делать custom-made загрузчик и CLI для перехода в него чтобы делать всеоперацииавтоматически на нажимая кнопок, которых даже на custom-made PCB нет.
В среднем embedded компании в СНГ существуют уже 25лет.
За это гигантское время внутри уже должна быть протестированная, переносимая, модульная кодовая база со всеми системные компонентами. Если этого нет, то явно что-то не так с менеджментом.
3-можно шифровать поток CLIшки. Но для этого придется писать консольную утилиту PC- терминал для расшифровки потока. Так сделано, например, в прошивке MeshTastic (PythonCLI)
Когда есть развитая 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 и прочее.
ECU контроллер управления 4мя газовыми форсунками от KME управляется и конфигурируется как раз по UART, что выходит на harness.
https://kme.eu/kme/en/produkt/nevo-sky-sun-ecu-2/
Лучше CLI. Board(а) без CLI это как NetTop без клавиатуры и монитора.
Чтобы пользоваться их заводским BackDoor загрузчиком надо удерживать DIO13 в 0.0V при reset. Чтобы микроконтроллер прыгнул в BackDoor загрузчик. Т.е автоматизировать прошивку из скриптов уже не возможно. Надо чтобы кто-то нажимал и удерживал кнопку.
Как вы через UART подадите напряжение на физический Pin? Да еще так чтобы он при reset оставался в 0V на 3 сек.
Вот и приходится делать custom-made загрузчик и CLI для перехода в него чтобы делать все операции автоматически на нажимая кнопок, которых даже на custom-made PCB нет.
Вот что тебя ждёт.
Тогда можно реализовать UART на GPIO. Или перевести UART на самую низкую битовую скорость и тактирование.
В среднем embedded компании в СНГ существуют уже 25лет.
За это гигантское время внутри уже должна быть протестированная, переносимая, модульная кодовая база со всеми системные компонентами. Если этого нет, то явно что-то не так с менеджментом.
Можно прямо сорцы реализации почитать. Там 15 функций всего
https://github.com/aabzel/ti_mcu_code_base/tree/master/Drivers/flash_fs
первая версия была взята из сорцов РКК "Энегрия"
3-можно шифровать поток CLIшки. Но для этого придется писать консольную утилиту PC- терминал для расшифровки потока. Так сделано, например, в прошивке MeshTastic (Python CLI)
Это для статьи "N атрибутов хорошей PCBшки". )
Не согласен. Проходили уже это. В таком случае прошивка будет сыпать ниагарский водопад Log(ов). Это будет нагружать/тормозить ход основного приложения.
В случае CLI пользователь сам сможет запросить ту диагностическую страницу, которая ему реально нужна, а не копаться во флуде.
Когда ты управляешь компьютером через GUI(ню) твои действия ограничены фантазией разработчика GUI(ни)
Когда ты управляешь компьютером через CLI(шку), то твои действия ограничены твой фантазией.
FRAM еще до кризиса была самой дорогой памятью. Написать endurance optimization для NorFrash дешевле тем более что сорцы есть.
https://github.com/aabzel/ti_mcu_code_base/tree/master/Drivers/flash_fs
Тем более что для FRAM чипов нужны 4 Pin(а) микроконтроллера так как они все требуют SPI. Лучше пользоваться OnСhip NorFrash(ом).
Если разработчики опасаются несанкционированного доступа к CLIшке то есть 2 решения:
1 добавить логин/пароль для активации полной версии CLI.
И паузу после 3х попыток ввода неверного пароля.
2 выпилить CLI из релизной сборки. Но в Debug CLI должна быть.
Когда есть развитая 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 и прочее.
У меня как раз так и реализовано.
https://github.com/aabzel/ti_mcu_code_base/tree/master/Drivers/flash_fs
Называется endurance optimization.
У нас очень дорогой программатор.
У нас на работе 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 загрузчик.
Какой это конкретно ISM трансивер?
Пока из опытов ясно чем уже(меньше) BandWidth тем больше range. Физика явления до конца не ясна.
Параметры указаны в реестре link(ов)
https://docs.google.com/spreadsheets/d/1caYJx9t9fzNc-g-7rHRa80K604MFfrrm3M9BiRfSP3g/edit#gid=0