Таблица вызова функций. Как?, Реализация "BIOS" Опции

[EXeGLuMATOR]

День добрый.
Имеется желание и необходимость сделать что-то типа BIOS для LPC23хх. Мысль в следующем - загружается что-то типа лоадера, который управляет камнем, также в нем есть базовый код для работы с периферией. Он един для всех проектов. Софт верхнего уровня делается отдельно и грузится выше адресами. Как сделать, чтобы из него можно было обращаться к базовым функциям?
Мысль одна - сделать табличку с адресами соотв. функций и буферов и верхним софтом ее юзать. Только как ее заполнять? Поскольку после каждой компиляции может меняться и размер и, как следствие, "раскладка" функций в памяти.

[e-serg]

Мысль одна - сделать табличку с адресами соотв. функций и буферов и верхним софтом ее юзать. Только как ее заполнять?

Допустим так сделать примерно так

Код

uint8_t data[4096];
int flash_write(uint32_t addr, uint8_t *data, int size); //некая функция
typedef struct{
    uint8_t VER_ID;
    int (*flash_write)(uint32_t, uint8_t*, int);
}FS; // в этой структуре перечислим
const FS __attribute__((section(".boot_func"))) fs = {0, &flash_write}; // разместим например по адресу 0x100UL с помощью линкера
const FS *fs2 = (FS *)0x100UL; // 0x100UL - адрес куда разместили структуру.

    fs.flash_write(250, data, 196); // варианты вызова одной функции.
    fs2->flash_write(250, data, 196);
    flash_write(250, data, 196);

Зачем в в таком примитивном микроконтроллере BIOS?

например одни и те же функции обработки данных в загрузчике и приложении.
тоже шифрование, зачем по два экземпляра кода.

[EXeGLuMATOR]

например одни и те же функции обработки данных в загрузчике и приложении.
тоже шифрование, зачем по два экземпляра кода.

Именно для мелких камней это и применимо. Тот-же ЮСБ и в загрузчике и в приложении - нет лишнего кода в приложении. Просто заполнил буфер, скомандовал на передачу. В этом и идея - все железо живет своей жизнью. Если оно нужно - его стартуем пользовательским софтом, если нет - то нет.

Спасибо. Вроде осознал по таблице. Т.е. как заполнить более или менее ясно, будем пробовать.
Теперь следующий вопрос, по этой же теме.
Лоадер работает, функции известны, периферия запущена (предполагается операционка, от Кейла). Т.е. лоадер - программа сама в себе. Верхнее приложение лежит во флэш с какого-то фиксированного адреса.
Стартовая функция (задача) приложения лежит по известному адресу и стартовать его не проблема. Каким образом компилировать пользовательскую программу, чтобы избежать появления лишнего кода? Т.е. чтобы был голый код приложения, после запуска которого он живет своей жизнью? Ну, насколько ему дает лоадер.
Тут скорее наоборот - лоадер выполняет функции ядра операционки, грубо говоря. А основной код может быть загружен в принципе любой, заточенный под такое применение, естественно. Т.е., например, идет обмен по ЮСБ - его сначала ловит лоадер и, если то что там ходит не относится к его работе (например обновление пользовательского софта и т.п.) - то пакет передается в пользовательское приложение. Как-то так.
Опять-же вопрос отладки. Ладно, лоадер и пользовательский софт во время отладки можно компилить как единое целое, а нужное потом как-то вырезать. Опять-же, как?

[scifi]

Похоже на изобретение велосипеда а-ля полновесная ось с запуском приложений.
Откладываем в сторону большой вопрос "нафиг?" и вообще вопрос о целесообразности такого подхода в микроконтроллерных приложениях.
Ось надо сначала спроектировать, в потом уже реализовывать. Надо описать ABI, под которым будет исполняться пользовательское приложение. Надо расписать функциональность и сферы ответственности ядра и приложения. И т.д. А вы занимаете свою голову второстепенными вопросами типа "Каким образом компилировать пользовательскую программу, чтобы избежать появления лишнего кода?"

[EXeGLuMATOR]

Похоже на изобретение велосипеда а-ля полновесная ось с запуском приложений.
Откладываем в сторону большой вопрос "нафиг?" и вообще вопрос о целесообразности такого подхода в микроконтроллерных приложениях.
Ось надо сначала спроектировать, в потом уже реализовывать. Надо описать ABI, под которым будет исполняться пользовательское приложение. Надо расписать функциональность и сферы ответственности ядра и приложения. И т.д. А вы занимаете свою голову второстепенными вопросами типа "Каким образом компилировать пользовательскую программу, чтобы избежать появления лишнего кода?"

В чем-то может и велосипед. А смысл прост. Есть устройство, нужно обеспечить запуск этих самых приложений. Ресурсы ограничены. Т.е. код лоадера + еще точно такой-же код в основном приложении - как-то расточительно, хоть и просто в реализации. И просто не лезет в камень. Еще очень большой блок данных во флэш лежит. Лоадер не меняется, только алгоритм обработки этих данных в зависимости от внешних воздействий. Вот и хочется максимальной скорости и простоты смены этого алгоритма пользователем на установленном изделии.

[scifi]

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

Возможно, подойдёт подход с интерпретатором скриптового языка. Он как раз обеспечивает простоту загрузки нового скрипта. Но если нужно быстродействие, то интерпретатор может не подойти.
Я использовал Pawn. Отличная вещь.