Добрый день! Всем.

Хочу попросить совета у профессионалов.

Задача такая:
построить программу для АРМ (среда разработки ИАР), чтобы она состояла из двух частей:
1 часть BIOS - постоянно находится во FLASH
2 часть APPLICATION - загружается BIOSом во FLASH и запускается им же и при этом для взаимодействия с железом использует ф-ции BIOS

У меня пока на уме такое решение: BIOS компилируется как обычная программа но расположенная в верхних адресах памяти и использующая верхние адреса RAM.

Приложение компилируется с обычным расположением сегментов ограниченных сверху размером под BIOS и загружается BIOSом в нижние адреса (как обычно) после загрузки (или во время загрузки) первая инструкция подменяется на команду перехода на BIOS.
Взаимодействие приложения с биосом через прерывание софтовое.



Или может есть другой способ (правильный ) ?

Заранее спасибо за советы.


Приложение включает в себя FreeRTOS. Или может лучше отнести её к BIOS ?

Поясните причину деления на BIOS и App? Для чего это нужно?

В основном для того чтобы обеспечить дистанционную загрузку приложения.
Во флэш должен всегда оставаться гарантированно рабочий загрузчик (т.е. он не должен перезаписываться).
Размер программы превышает размер половины флэша.

Подобное собирался сотворить на MB9X, но долго думая над реализацией так и не нашел в этом практической пользы, тем более что софтварны прерывания создают только лишнее неудобства. Поэтому пользую BootLoader + Application.




Так и не понятно зачем нужен BIOS.
И какие трудности для обеспечения "не перезаписывания" bootloader'а?

АВтор ещё не сказл што за кирпич и тяжкое наследие х86 чествуется , это я о биосе.

Первичный бутлоадер + образ системы ... собственно здесь даже и выбора нет по оптимальности...
линух, СЕ , VxWork далее со всеми остановками... А гарантированный загрузчик это как повезёт накрыться системе... всё равно пин для загрзчика выводить наружу с кнопкой ресета...

Пусть bootloader

тогда вопрос: он компилируется отдельной программой или является частью приложения?
может есть ссылочка на пример загрузчика из внешнего датафлэша



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

Мы делали так с LPC2134.

Распределили память LPC2134 на 3 части.
В начале памяти находится сектор размером 4К, в нем разместили специальный start-up
в адресах 0x00000-0x00FFF.
Далее 2 и 3 части - application. Для LPC2134 это 60К в адресах
0x01000-0x0FFFF - App1
0x11000-0x1FFFF - App2

Сначала всегда начинает работать start-up. Его задача - определить App, которое нужно в данный момент запускать.
Это делается проверкой на наличие App по CRC областях памяти App. Если App только одно - то оно и
стартуется. Если найдены App1 и App2, то реализуется механизм выбора App. Не суть важно, как он
сделан, например может во внешней eeprom быть флажок соотвествующий, или можно задействовать
для этого область в секторе start-up или втором секторе flash.
Соответственно есть соглашение на точку входа в App и адрес таблицы прерываний.
Когда App определено, его таблица прерываний копируется в облась 0x40000000 - это в RAM, и
устанавливается re-map таблицы прерываний на RAM в соотвествующем регистре LPC.
Далее делается переход на точку входа в App по фиксированному адресу.

Загрузка App реализуется в самом же App. App грузится всегда в неактивную область. То есть, если
работает в данный момент область App1, то грузится в область App2, и наоборот. Для этого при сборке
проекта создается 2 бинарника, отличающиеся адресами линковки. Для всего этого есть механизм
в протоколах загрузки, по которым определяется, какой именно файл нужно грузить. По окончании
загрузки устанавливается признак, что активно новое App и производится рестарт.
Если взять другой ARM (не LPC), то такое тоже вполне можно сделать, нужно чтобы только был
re-map таблицы прерываний на RAM ну и IAP.

Какие плюсы:
1. Апдейт софта проходит в фоне, не нарушая нормального функционирования устройства. Если
канал, по которому происходит обновление не быстрый, то это актуально.
2. Для апдейта можно выделить буфер 256 байт, это значение определено как минимально
возможное в командах IAP для LPC. То есть много дополнительной памяти это не ест.
3. Если в процессе загрузки даже что-то слетает, то никаких катастрофичкеских последствий
не будет.


Ваше желание разделить функции на bios и app не очень удачное. Смысла в этом особого нет, появится куча соглашений о точках входа в BIOS, приложение будет сложнее собирать и контролировать ошибки этих вызовов. Ну и т.д. и т.п.

Отдельной программой и линкуется в определенный сектор, запись в который сам и исключает.


Минусы:
- накладные расходы по сопровождению (драйвер поменял - меняй BIOS, а его менять надо ОЧЕНЬ аккуратно, чтоб аппарат потом завелся...)
- накладные расходы при выполнении операций через BIOS

Делали и так, правда в AVR - но это не принципиально.
Сидит загрузчик где-то в начальном секторе. По команде App передает ему управление,
потом под управдением загрузчика App перезаписывается и рестартуется.
Вот только что там было с таблицей прерываний - не помню, но в ARM ее можно перенести в RAM,
это проще.

Большое спасибо!


с примером всё понятно - очень удобно (у нас одна проблема - программа имеет больший размер чер половина флэша)



а насчёт загрузчика если он линкуется не с нуля то как на него осущ переход при вкл питания
или он изменяет на себя вектор сброса после загрузки приложения?


В АВР есть fuses для изменения адреса старта (перехода на загрузчик)
а в арме по-моему нет (или я не в курсе)

Загрузчик как раз линкуется так, чтобы на него попадали при включении питания.
То есть reset вектор всегда передает управление на загрузчик. Далее загрузчик уже делает
переход на вектор входа в App на фиксированный адрес. Это соглашение с сами собой,
не более того.

Далее возможно 2 варианта для перенаправления прерываний.
1. На векторах прерываний в загрузчике ставятся команды перехода на область App,
где эта таблица располагается. Это соглашение принимается и все. В этом случае
загрузчик не может пользоваться прерываниями и должен работать с периферией по поллингу.
2. Если uC позволяет, можно поместить таблицу векторов приложения в RAM - об этом я писал выше.

Для AT91SAM7 есть недешевый вариант https://www.prllc.com/productcart/pc/viewPr...mp;idproduct=84.

Посмотрите здесь (готовый проект)


http://www.tnkernel.com/usb_fw_upgrader.html

Спасибо.

А вы можете поподробнее расписать об этом? С примерами? Заранее - спасибо!

3. Cамый правильный - верктора считываются из контроллера прерываний, который какждый из участников программирует так, как ему нужно.



Да уж куда, простите, "подробнее"

А вы бы не могли ответить в соседней ветке, там указывается на что прошу ответить подробнее?