Универсальный загрузчик для MEGA-2560 .. хочу странного :)

[Arhat109]

В общем, поскольку изготовление плат подходит к концу, плюсом уже подьезжают платы расширения ОЗУ до 520кб суммарно (8кб своих + 512кб) и они будут со встроенным держателем SD-карт на SPI интерфейсе Меги, то .. возникла идея:

Разместить в зоне загрузчика (выделить из него) код, позволяющий доливать в процессе работы куски во флеш или оперативу с SD-карты. Получается "этакий Bios" .. как себе это вижу:

Из скетча, предварительно сложив "команду и адрес" в 3 резервных регистра GPIO (они есть!) вызываем "ОС" (загрузчик) с "дальнего адреса" (можно реализовать таблику переходов, типа номера функции), и загрузчик, т.к. он сидит во "втором блоке флеша", вполне может дозалить нечто указанное из SD сразу во флеш, точно также как он заливает скетч при загрузке.

Возможно это долго и гемморно, но у меги 256кб флеша и редко какой скетч "долетает даже до середины Днепра" .. аналогично, (там около 4 килобайт макс!) можно сделать заливку из SD в SRAM в т.ч. и вот эту "расширенную" блоками по 16кб.

Что ищу (хочу найти):
1. Исходники бутлоадеров. Желательно разных для сравнения решений;
2. Есть ли готовый бутлоадер скетчей с SD карт или с чтением исходника по SPI?
3. Какой механизм обращения в зону бутлоадера наиболее применим для вызова его подпрограмм (библиотеки, Биос, и т.д.)?

В результате хочу получить в верхней 4кб области флеша набор утилит, позволяющий читать SD по SPI, возможно (если влезет) по UART0..3 и напоследок если останется место по I2C .. который позволит читать блоки по этим интерфейсам и заливать их в нижнюю (программную) область, тем самым доливая/изменяя скетч или его часть.
В Максиуме - аналогичное действие для чтения/записи в SRAM по всей ширине адресной шины в 64кб (листать страницы интерфейса расширения SRAM, ПО у меня уже есть)..

Как-то так .. идеи, помощь, критика?

 

[Arhat109]

Применимость вопроса думаю всем ясна: можно изменять скетч "на лету", подгружая его оверлеи или подгружать разные блоки данных в ПЗУ микроконтроллера по мере необходимости .. например, какие-то длинные строки текстов, звуковые ряды, например музыки или текстов для "матюгальников" и т.п .. ну и вариант "чтение по I2C" - можно подцеплять по этой шине оч. большое ПЗУ последовательного типа ..

 

[Arhat109]

Так. Нашел кучку исходников, в т.ч. optiboot загрузчика как на гихабе, так и в поставке самого Ардуино ИДЕ .. они там оказывается есть и несколько.
Почитал вики про hex-файлы .. оказывается.

В общем ещё вопрос: есть где-нибудь готовые загрузчики с SD-карт во флеш? (полез гуглить, но может кто подскажет..)

Ответ нашелся сразу: https://github.com/zevero/avr_boot -- круто!

Почитал исходники optiboot ой, как все оказывается примитивно-то!

 

[Arhat109]

Итого, в общем-то покопавшись нашел большую часть и даже "с запасом" готовых решений:
1. Есть целая туча разных лоадеров стандартного вида от adaBoot до optiboot, в т.ч и полностью поддерживающих протокол stk500v2 и даже stk600
2. sd-bootloader - есть (ссылка выше)
3. Ethernet-bootloader - есть несколько версий
4. проект MegaCore содержит много чего, в т.ч. "Писалку во флеш" в процессе исполнения программ. там вообще очень много вкусного, в т.ч и новые платы на базе чипов 4809, 328PB и т.п. в т.ч. и "все ноги Мега 2560".
Похоже надо клонироваться от них и собирать этот "биос" с универсальным загрузчиком.
А заодно запилить в их стиле свои настройки плат с расширением ОЗУ, чтобы можно было также выбирать опцией: SRAM 8 / 32 / 64 /520 kb

тогда эти платы тупо лягут на "готовое ПО" один в один..

 

[Wan-Derer]

@Arhat109, по-моему, было бы круто если бы бутлодырь поддерживал UART. Тогда можно было бы грузить блоки обычным терминалом через какой-нибудь X-modem и пр.

 

[Arhat109]

@Wan-Derer, так это самое простое. Они все поддерживают UART, т.к. в общем-то в Ардуино по факту, все принимается через него

 

[Arhat109]

В целом, организация кода optiboot получается "самая приличная", можно брать его за основу и допиливать плюшками - функциями:
"загрузка с SD", "загрузка по Ethernet", ... "Открыть/закрыть файл SD", "читать/писать блок файла с/на SD c/на Flash/SRAM" попутно вывести в доступ работу с UART (чтение/запись символа), I2C ..

Всё это есть (по кускам) готовое .. просто собрать в "верхний блок" Flash до кучи к загрузчику, поджав код (выбросив всё лишнее) .. в 4кб (Мега2560) влезет похоже легко, возможно и даже в 2кб получится упихать..

 

[Arhat109]

Полистал код загрузчиков с SD и библиотеку работы с ней. И .. возник вопрос:

Окей, пусть по кнопке ресет, обнаруживается что "вставлена SD" в разъем и надо "залить программу" (вариант SD бутЛодырь) .. а какой файл он будет заливать из ФС карты? В том лодыре что постил ссыль заливается файл со стандартной кличкой app.bin, причем он даже должен быть не hex а именно готовый бинарник! (там с трудом автор втиснулся в 4кб как оказалось).

Какие варианты можно иметь?
а) стандартное название файла. Требует всей лапши работы с FAT16/32 т.к. надо его найти и добраться по ФС .. примеры есть в нескольких реализациях;
б) имя файла указано в EEPROM .. или стандартное. Те же требования + чтение EEPROM (с какого места?);
в) первый файл в корневом каталоге. Несколько упрощает работу с ФС, нет привязки к имени файла. Проблема с заливкой на карты - не каждый файловый менеджер покажет Вам куда он пишет название сохраненного файла в "большой ОС" типа Windows, и даже Linux..

Подвариант "в2": "первый файл в первом каталоге карты. Кмк, несколько упрощает подготовку карты и в дальнейшем её пользовании как-бы сохраняет место в директории за этим файлом перманентно, если не удалять этот стандартный каталог с карты. А вот чистить сам каталог уже вполне можно. Исключает поиск в ФС "по имени" как самого каталога, так и файла, что несколько упрощает задачу.

Далее, похоже вся сложность будет упихать полноценную работу с ФС карт в эти самые 4 килобайта. Там много разного ..

Есть идеи лучше для бутЛодыря с SD карты? Предлагайте.

 

[Arhat109]

Пока сформировался такой "биос" в виде набора функций:

1. Работа с UART: чтение/запись символа, чтение/запись буфера заданной длины в/из SRAM, ожидание готовности. Собственно это есть в каждом лодыре, тупо выделить как функции, способные вызываться из рабочего ПО тоже;
2. Работа по SPI: аналогично. Тоже есть как примитивы чтения/записи данных с/на SD а также во всех Ethernet boot лодырях для w5100-w5500 шилдов, т.к. они сами подключены сюда же.
3. Работа с watchdog таймером и функция перезагрузки платы на рабочее ПО при отсутствии "загрузки" после reset или включения. Применить метод adaboot, примененный в optiboot тоже. Заодно, можно иметь основу будущей вытесняющей RTOS на базе этого таймера.
4. Примитивы работы с ФС fat16/32 (ещё надо?) типовым перечнем функций (открыть файл, закрыть файл, читать/писать сектор/кластер/простоБлок в/из SRAM и т.д.).
5. Блок поддержки протокола STK500v2 в необходимой для avrdude части как у optiboot.

Все эти пункты, в том или ином виде так или иначе, есть в бутлодырях того или иного вида. По идее, втиснуть все это в 4кб вполне можно, возможно работу с ФС придется перерисовать на Ассемблер (не проблема).

6. Добавить (если влезет, в чем пока сомневаюсь) драйвер аппаратного I2C (полноценный около 450байт) + примитивы чтения/записи EEPROM.

В итого, блок п.5 собственно и будет "bootloader" с настройкой: какие части из арсенала этого БИОС он будет использовать и в каком виде?
Как пример "конструктора":
а) "читаем протокол по UART + пишем в нижнюю FLASH + перезагрузка" - работа типового лодыря по шнурку USB.
б) "читаем файл по SPI + работа с ФС + пишем нижнюю FLASH + перезагрузка" - работа типового лодыря с карты.
в) "читаем файл по SPI + работа с ФС + пишем нижнюю FLASH с заданного адреса + возврат в ПО" - подгрузка оверлея (ПО или данные) с карты в заданное место.
.. и т.д.

Организацию взаимодествия с ПО вижу как выделенную область в SRAM (глобалы).. но это не точно.

Кстати .. подгрузка оверлеев .. можно же выйти за ограничение 4кб, и тупо дозаливать самим собой кусок RTOS в верхний конец нижней части flash, под загрузчик, если надо!

 

[Arhat109]

Нашел ещё одну реализацию FAT16,32 для AVR: https://github.com/alemorf/VinxFS очень интересно..

 

[Arhat109]

Посмотрел VinxFS, имхо много лишнего, код не оптимален.. как пишет автор, полная версия около 6.5кб, похоже что все нужное можно ужать в 1.5-2кб "легко". Кстати сделано по мотивам Petit FS, которая вложена в SD-bootloader по ссылке выше и которая влезает в 2кб.

В итого, сваять загрузчик в т.ч. + SD в 2кб задача кажется вполне реальной. В таком урезанном виде, можно думаю даже для серии 328 (Нано, Уно) приспособить..

Никому не надо?

 

[PiratFox]

@Arhat109, мне интересен вот какой момент. Если действительно получится ужать загрузчик до 2-х кб, тогда можно безо всяких извращений
заливать прошивки по воздуху через любой радиомодуль в 328-е меги. Или я что-то не так понял?

 

[Arhat109]

@PiratFox, не понимаю, как размер загрузчика влияет на размер загружаемой прошивки, даже "по воздуху"? Кмк, радиоканалу несколько пофиг какого размера Ваш загрузчик (optiboot так вообще 512 байт), ну и самому загрузчику, кмк, тоже до фени сей момент. В целом есть готовые загрузчики по Ethernet, которые через модуль bluetuth или wi-fi как раз и будет "во воздуху", не?

В целом, эта работа больше не к вопросу самого "загрузчика" (как выяснил их полно разных, готовых на все случаи жизни - "всё украдено до вас"), сколько как подготовка в верхнем блоке flash микроконтроллеров AVR подобия BIOS, с целью организации RTOS и дозагрузки скетчей и/или их кусков с заданного источника, в первую очередь - SD (и даже такой готовый кусок кода - есть в проекте Mega-Core!)

Пока, всё что интересно, лезет в 4к .. для Мега2560 и моих плат (тут было предложено в целом, для всего проекта название "AR-Go!") с оперативной памятью в 520кб - вполне терпимое решение. Посмотрим что из этого выйдет.

Пока, как ни старался, выжать из Мега2560 "всё" - мне ещё не удалось...

 

[PiratFox]

@Arhat109, я не столько о размере... Я к тому, чтобы сделать его, ну, универсальным, что ли. Чтоб и по юсбе мог скетч грузить, и по воздуху. Одним загрузчиком. Заранее извиняюсь, может, глупость спорол. Ну, не силён я в биосах и загрузчиках, так что сорри.

 

[Arhat109]

@PiratFox, ну .. к этому и иду. Но, решение этого вопроса больше "побочная задача". По идее, должно вырисоваться "само собой".

 

[PiratFox]

@Arhat109, В общем, основную идею я понял так, по аналогии с IBM PC, объединить BIOS и некоторые функции MS-DOS для того, чтоб в процессе исполнения кода из флеши(внутренней или внешней) грузились нужные куски, т.н. оверлеи. Я правильно понимаю? Идея мне очень нравится, но...
Стоит ли превращать старую добрую ардуину в некое подобие Raspberry без периферии. Я не претендую на правоту, однако подумайте и об этом. Тут ведь и до своей ОС недалеко, а? В таких вещах, ИМХО, главное - вовремя остановиться. Что получается далекоооооо не всегда. А впрочем, дело Ваше. Здоровая критика ещё никогда и никому не мешала, вот так вот.

 

[Arhat109]

@PiratFox, правильно понимаете, если в "общих чертах". Да, идея сделать работу с периферией "типовой" (Base Iinput Output System) и запихать все это в старшую область адресов, туда где "загрузчик". Сам загрузчик (как следствие!) становится тупо универсальным и пользует этот же самый bios в процессе загрузки. Соответственно, сам становясь "частью" bios.
Это должно позволить прикладному ПО (скетчам) пользоваться им как частью, что разрешает "дозагрузку" частей ПО (иных скетчей, оверлеев, кусков данных во флеш и т.д.) "на лету".
В этот блок также планируется "система управления заданиями" .. то есть некое подобие RTOS, ну и, как следствие, да .. Мега2560 превращается в подобие "Расбери" или чего-то похожего.

Что в этом "плохого"?

Это - хобби, "чем бы дитя не тещилось, лишь бы не вешалось" .. Соответственно, его применимость в количестве 1 штук (мне лично) и есть "цель поставленной задачи" .. т.с. "программа миниум". Если кому-то ещё это интересно - милости просим. Нет? Не переживаю, т.к. ещё раз - это хобби, а не "курсовой проект" или "проект для хайпа, лайков и т.п.".

Мне просто интересно и любопытно: какой сложности систему можно создать на Мега2560, если весь код писать грамотно .. то, что компьютеры, летающие в Космос несколько (примерно на порядок) проще - я в курсе.

Переживаете, что "Малинки станут никому не нужны"? Не стоит .. сейчас рулит не то что "полезно или эффективно", а больше то, что МОДНО. Никуда они не пропадут как и STM32 .. допилю, посмотрю .. может и за STM32F429 в 176 ногом корпусе возьмусь, чё валяется без делу-то? Только пока .. не могу придумать для него "дел", кроме как "обработка изображений на лету"... а это мне ни антиресно ни разу.

P.S. Тут, в целом-то и работы особой нет .. всё есть по кускам в разных местах. Надо только собрать всё в кучку не потеряв компактность, скорость и какие-то возможности периферии. То, что "периферии нет" .. так её для Мега2560 и не было никогда .. не?

 

[PiratFox]

@Arhat109, за "Малинки" и прочие ягоды я как - то и не волнуюсь. Пусть об этом у их разработчиков и владельцев тренда голова болит. Я занимаюсь промышленным оборудованием, электро и гидроприводом, так мне был бы интересен Ваш проект, ежели портировать его на ARM, точнее на STM32.
В адаптивном управлении иногда требуется смена управляющих алгоритмов, так что подгрузка программы "на лету" было бы самое оно.

 

[Arhat109]

@PiratFox, а там разве нет ничего похожего? Не в курсе просто..

 

[PiratFox]

Да Вы знаете, ничего похожего как-то и нет. Возможно, никто такую задачу не ставил.А тут вот откуда-то взялись мы с Вами, и давай эти задачи ставить. Может, кроме меня и Вас, это и нахрен никому не нужно.