Ну да, вполне стандартные задачи. Обычно у первичного загрузчика свой протокол, у вторичного - поверх первичного - свой. Есть таблица вызова функций для работы с железом. Первичный загрузчик гарантирует доставку пакетов, вторичный - занимается логикой.

Кстати, вторичный загрузчик, вообще можно не держать во флеше. Грузить непосредственно первичным в ram и стартовать оттуда. Решает кучу проблем.

А зачем второму свой протокол?


В смысле - вторичный загрузчик дергает по этой таблице функции из первичного?


Ну так получается, что первичный загрузчик должен уже уметь практически все, чтобы запрошить вторичный. Во вторичный особо нечего выносить... Если бы к примеру надо было еще какую-нить дополнительную память писать - датафлеш скажем - ну тогда да, можно было бы вынести в отдельный загрузчик. А так...


А каких? Вроде с флешем только одна проблема - во время записи флеша проц "виснет". При стирании страницы получается ощутимо.

Как зачем? Первичный - пакет принял, пакет отправил. Проконтролировал отправку контрольными суммами, если нужно, переслал. Что находится в пакете - ему знать не нужно, он лишь гарантированно доставляет данные, устраняя вероятные ошибки в физическом канале связи. Вторичный - парсит пакеты без траспортных заголовков, определяет, какая там логическая команда, какие данные и занимается непосредственно логикой. OSI же.


Да. Набор этих функций минимален, и, скорее всего, не будет нуждаться в доработке.


Надо исходить из того, что основные задачи первичного загрузчика:
- транспортный канал с хостом
- загрузка вторичного загрузчика через канал связи
- обеспечить проверку подлинности и запуск вторичного загрузчика.
- запустить основную прошивку, если условия запуска загрузчика не выполнены
Все это занимает меньше килобайта.


Главное: не нужно поддерживать на уровне хоста зоопарк версий. Прогрузили вторичный загрузчик, запустили - вот и новый протокол. Можно их делать несколько - для каждой задачи - прошивка основного флеша, прошивка датафлеш. Да хоть сброс настроек.

Если первому загрузчику надо заливать второй, то так не получится - ему придется парсить пакеты и отвечать на них... А заливка второго загрузчика ничем не отличается от заливки самой программы (по крайней мере в моем случае, когда прога живет во встроенном флеше). Так что опять получается, что в первом загрузчике сидит все, а во втором - почти ничего


Ну хз насчет килобайта. У меня практически эта функциональность + шифрование + еще кое-что по мелочи едва влезла в 8 к. Компилятор gnu gcc от бывшего кодесоурсери. Писал на С с классами, без всяких наворотов, CMSIS юзал по минимуму.



А зачем нам новый протокол? Опять таки, функциональность устройства по железу фиксирована на момент заливки туда основного загрузчика. Т.е. если в основном загрузчике иметь разные варианты компиляции в зависимости от устройства - это с головой хватит.

Что-то многовато. Ищи там ФУНКЦИОНАЛ навороченный?
На АВР приём-передача по UART-запись-чтение прошивки в dataflash-простейшее шифрование в 4КБ влезало. В 8 наверное AES влезет и приём-передача через GSM например (GSM не проверял).

Там пакета-то - код команды, блок данных, crc. Ответ ack/nack. Это 5 строчек на сях. Получить блок, проверить crc, скопировать в область памяти, увеличить счетчик. По команде запуска джампнуть на адрес. И 3 команды в минимуме - handshake + load secondary, read/write.


Имхо, си c классами в загрузчике, это слишком жирно.


Баги, новые команды. Да что угодно. Если устройств выпустится достаточное количество, поддерживать их будет уже геморно.

IAR AVR как-то получше оптимизировал. На нем в 8К помимо того, что влезло в АРМ, втиснулась еще и индикация на дисплее. Шифрование у нас ГОСТ, прием-передача конкретно в этом случае по самодельному интерфейсу, чем-то похожему на SPI.

Функционал:
1. Запись прошивки (+ проверка на совместимость + дешифровка + проверка цифровой подписи)
2. Чтение прошивки (+ шифровка, цифровая подпись)
3. Чтение информации об устройстве и статуса
4. Широковещательная запись (похожа на 1, но немного другой алгоритм)
5. Всякие мелочи - запуск программы, принудительный переход в программирование

Оптимизацией сильно не занимался, просто поигрался с разными комбинациями флагов. Еще можно немного выжать, ужав таблицу прерываний - у меня даже в неиспользуемых прерываниях в конце таблицы все равно лежат нули.

Писал на С с классами (просто данные и методы собирал в класс). АСМ не юзал.



Ну 5 строчек - это большое преуменьшение. Надо настроить переферию, прерывания, собственно прием пакетов, дешифровку, проверку цифровой подписи, возврат текущего статуса. На линии могут сидеть несколько устройств, нужно фильтровать свой адрес, уметь его сообщать, поддерживать одновременную запись неск устройств...


Ну может быть. С другой стороны, чем это сильно отличается от функций + глобальных переменных? Единственное отличие - каждая функция получает доп указатель. Но у СТМ по идее тут должно быть все хорошо. Хотя надо ради интереса один класс сделать на статических переменных\функциях, возможно действительно что-то ужмется.



Баги и новые команды сидят в самой прошивке. Если они вдруг поселятся в первичном загручике - все равно его перепрошить не получится...

А оптимизация какая использовалась?
Заметил, что в отличии от ИАРа GCC реально оптимизирует по размеру - чуть ли не в полтора раза ужимает.