Дозагрузка программы в АРМ Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Древовидный Переключить на: Стандартный Переключить на: Линейный

[Пришелец]

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

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

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

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

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



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

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


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

[Пришелец]

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

Сообщение отредактировал Пришелец - Aug 31 2006, 11:13

[Andy Mozzhevilov]

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

Мы делали так с 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, приложение будет сложнее собирать и контролировать ошибки этих вызовов. Ну и т.д. и т.п.