Прошивка STM32F7 через другой STM32F7 (UART), Прошивка ведомых ведущим. Опции

[AVStech]

Добрый день! Повторюсь в этой ветке, так как в основном работа с ARM

Возникла необходимость прошивки микроконтроллера STM32F7 другим микроконтроллером STM32F7 подключенный к нему через UART, а также прошивки Atmega328P подключенного по SPI. Необходимость возникла по причине того, что SoM на Allwinere страдает кучей недостатков в том числе отсутствием необходимого количества UART.
Постараюсь описать кратко идею:
Есть несколько микроконтроллеров STM32F7 общающихся между собой по UART и один Atmega328P подключенный к STMке по SPI, из них:

а) 1-й Микроконтроллер STM32F7: Концентратор на базе STM32F7 он собирает данные с разных микроконтроллеров по UART пакует их в пакет и отправляет по Wi-Fi пользователю через модуль ESP-01 или ESP-06 (UART+2xGPIO). Также данный контроллер имеет слот под microSD подключенный по SDIO и FRAM по SPI.

б) 2-е...5-е Микроконтроллеры STM32F7 (4 штуки): собирают различную цифровую и аналоговую информацию, обрабатывают ее и отправляют на концентратор (см. пункт а)), который в свою очередь ее упаковывает и отправляет в сеть.

в) Микроконтроллер Atmega328P: Следит за уровнем заряда батареи, управляет вкл и выкл систем питания, и в теории программирует по i2c две микросхемы BQ25892 (устанавливает настройки).

Как все это должно работать в теории:

1. Вставляем в microSD слот карту памяти с папкой, например, Firmware, и контроллер (концентратор stm32 из пункта а)) просматривает файлы и в случае, если находит в ней прошивку старше загруженной шьется сам и шьет все остальные контроллеры включая Atmega328P. Затем удаляет все исходники из папки Firmware. Все папка пуста.

2. Подключается по wifi к сети интернет, заходит по ссылке в сети интернет смотрит версии прошивки и если есть прошивки старше загруженной качает ее на microSD карту в папку Firmware, перезагружается, и затем как в варианте с microSD шьется сам и шьет все остальные контроллеры включая Atmega328P. Затем удаляет все исходники из папки Firmware. Все папка пуста.

Теперь вопросы - это возможно реализовать на практике?

И "ДА" - Естественно все микроконтроллеры имеют необходимый bootloader и все прошивки скомпилированы в бин или хекс.

У меня одна проблема - я не могу учится по учебникам, то ли мозг так заточен, то ли уситчивости не хватает. Я не нашел ни одного примера. Я могу взять чужой пример и переделать его. С нуля не получается, тем более что нужно быстро.
Поэтому спрашиваю это физически возможно?
Если да то прошу помощи - пример как это сделать, включая схему подключения между контроллерами. Ведь голый uart не пойдет нужно с концентратора еще и gpio подводить к ногам boot0 и boot1 и RST ведомых микроконтроллеров (для avr также)

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

Спасибо.

Сообщение отредактировал AVStech - May 23 2018, 17:06

[khach]

Система с кучей STM32 в том числе F7 имеет право на жизнь, и отдельный F7 отвечающий за библиотеки прошивки это тоже нормально. Но в определенных случаях. Например это удаленная система без непосредственного доступа оператора с плохим каналом связи. Т.е прошивка для апгреда заливается медленно и печально, часами или неделями, с обрывами связи. Процессор-менеджер фирмвари этим и занимается. Когда прошивка залита во внешний флешь, проверены ее чексуммы и соответствие акуальной версии харда остальных процессоров, то планируется действия по накатыванию фирмвари в безопасный для техпроцесса период. При этом во флеши менеджера прошивок лежит как минимум две копии фирмвари, в том числе и для даунгрейда в случае проблем. Т.е если вылезит баг при накате прошивки то всегда можно быстро откатиться без передачи новой-старой фирмвари по ненадежному каналу связи. Ну а мультипроцессороность позволяет функционировать управляющему блоку даже при неудачной прошивке. Т.е новая фирмварь вводится в опытную эксплуатацию в режиме надзора без включения в управляющий контур и только после некоторого пробного периода управление переключается на нее. Менеджер фирмвари также может принимать, хранить и высылать журнал эксплуатации системы, журналы срабатывания ватчдогов, трапов и ловушек подчиненных систем итд. Возможен спец-вариант принудительного наката дефолтных прошивок по срабатыванию ватчдога всей системы низкого уровня на "мелком 8-битном процессоре" но с этим надо очень осторожно чтобы не крашнуть систему при проблемах питания. Самоапдейт менеджера фирмвари тоже возможен, но это очень особый случай типа частичной порчи флеша от длительной эксплуатации. Или если эта вся система расположена совсем не на родной планете....
Это все из области ультранадежных дублированных управляющих систем.