Допустим, я написал программу на C++, скомпилил, прошил. Теперь мне понадобилось дописать в ROM ещё одну функцию, написанную также на C++. Цель - скажем, допрошил 30-40 файлов-функций в ROM и пользуешься ими из основной программы.
Вопрос:
1) Возможно ли настроить среду (EWARM или любую другую) так, чтобы она выдала мне файл с "чистым" кодом функции, т.е. без кода инициализации процессора и т.п.?
2) Существуют ли стандарты файлов, предназначенных не для включения в проект, а для непостедственной прошивки в устройство?

1) Можно функции разместить в каком нить отдельном пространстве и выдрать потом и прошивочного файла.

2) конечно существуют, обычно имеют разширения .hex и .bin, но бывают и другие форматы

P.S. обычно туда 1 раз записывают

И еще по ходу, а откуда основная программа узнает что вы что то куда то дописали ?

1) ROM = Read Only Memory
2) сразу на будущее ознакомьтесь с понятием трансляции адресов (как в DLL)

Если Вы будете дописывать в FLASH/EEPROM функции во время работы девайса, то таким же нехитрым способом можно переписать всю прошивку, что обычно и делают.

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

Да, эти функции должны хранится во внутренней флешке или во внешнем хранилище (CF card/FLASH....) ?

А это зачем ?

в результате работы компилятора получаются "относительные" адреса, абсолютные их значения становятся известны только на этапе линковки. соответственно, если Вы хотите использовать скомпилированный код, преобразовывать "относительные" адреса в абсолютные придется самостоятельно. эта процедура в DLL называется "трансляцией адреса"

Может в DLL и так, а вот для микроконтроллера вы не преобразуете никак и никогда !!! незная MAP(файл для линкера который описывает пямять). А когда этот файл есть то и ничего преобразовывать не надо так как всегда можно посмотреть где эта функция находится.

Попробуйте заранее расположить 30-40 по фиксированным адресам. Получится если функции не использут никаких системных библиотек и внешних функций (или внешним функциям как-же присваивать адреса). И с оптимизацией поиграть. Возможно придется выключить перемещение кода.

Совершенно бесполезное и ненужное занятие.
Зачем это, я что-то не понимаю.

Я так понимаю, чтобы пользователь мог сам определять функционал устройства. что-то вроде ПЛК. Ядро отдельно , юзеровская программа отдельно. Можно даже несколько юзеровских программ хранить и практически на лету переключать. Остается придумать как подключить стандартные функции, которые уже есть в ядре. Например как можно присвоить функции cos фиксированый адрес? или если эта функция не используется в ядре, расположить ее в юзеровской области.

вопрос тут не в том, КАК это сделать - достаточно разместить функцию-транслятор адресов в фиксированном месте памяти, и в ней хранить таблицу остальных адресов функций. вопрос в том, ЗАЧЕМ это может понадобиться

Понятно.
Что-то типа BIOS и OS на борту. Юзеровские программы подгружаемые. Аналог наладоннина.
Так же BIOS и OS на борту. А юзеровские программы прошиваются в отведенную область. Аналог PLC.

Можно ли настроить среду, чтобы она сгенерила .hex или .bin, содержащий только скомпилённую мою функцию?

Сообщение отредактировал der Spomer - Dec 18 2007, 09:16

1 вариант. Попробуйте отключить стартап, все глобальные переменные no_init
2 вариант. Вручную линковать obj. Может получится
Результат сообщите, интересно

Мои соображения.

Если я всё правильно понимаю(в чём я сильно сомневаюсь) то стандартный исполняемый файл с пустым main, сгенерённый ewarm, имеет след. структуру:
------------------------------------
таблица векторов прерываний
сstartup
cmain
cexit
------------------------------------
Если структура верна, то, видимо, при отключении первых двух пунктов получается работоспособный код, который можно вызвать из основной программы без потери работоспособности обоих. Поправьте если не прав

Сообщение отредактировал der Spomer - Dec 18 2007, 10:08

еще есть секция инициализации переменных, стека и т.д.
также надо разделить области ОЗУ ядра и приложения при использовании глобальных переменных
Более правильный путь - компиляция obj. Она позволит отключить все ненужные в данном случае секции и получить код с заданного адреса.

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