Так и сделал.
Плюс к глобальным переменным дописал __no_init.
Работает.
Спасибо.

Как указать линкеру, что используемая функция уже лежит по конкретному адресу и на этот адрес писать ничего не надо?

Голую main можно получить если исключить startup и low_lewel_init.
Наблюдается некоторый оверхед. Если main использует хоть какие-нибудь библиотечные функции, то они тоже будут присутствовать в коде. В той части программы, которую здесь назвали BIOS, они также могут присутствовать, что слегка излишне. Если предполагается использовать таким образом несколько "подгружаемых" функций, то и они все будут содержать в себе полный набор используемых ими функций несмотря на наличие того же самого у других.
Если подобный расход памяти не критичен, то на это можно закрыть глаза. Иначе придётся таки воспользоваться механизмом DLL.


Она не только лежит по адресу, но и некоторый обьём памяти (в общем случае неизвестный) занимает.
А что касается линкера, то что ни линкер, то свои заморочки. У IAR, например, выделяется отдельный сегмент со своим диапазоном адресов.

Не понимаю как им можно воспользоваться? Может как-то можно через линкер? Адреса же заранее известны.



Вот именно. Как заставить IAR-ий линкер НЕ ПИСАТЬ по данному адресу функцию, а только произвести вызов? Из расчета что библиотечная функция по данному адресу уже есть. Может это Keil делать умеет?
Т.е хочется прошить "BIOS" c библиотечными фукнциями, а потом маленькие пользовательские програмки, которые обращаются к этим функциям. Програмки делать отдельным проектом с голым main.

В общих чертах -

Выполняемый (загружаемый) код должен иметь таблицу импорта для библиотечных функций (id=address) и таблицу экспорта (id/name=address)

Загрузчик кода поправляет таблицу импорта и добавляет список экспорта в глобальный список функций. Это несложно в реализации и дает возможность динамической загрузки и выполнения кода.

Вместо таблицы импорта можно сделать callback и возвращать загружаемому объекту ссылку на нее (чтобы можно было выполнять код из flash, не переписывая в нем таблицу)

Вообще, вариантов реализации - море, но механизм везде общий

ps Единая для всех модулей точка входа (инициализации), и больше ничего не надо - остальное сделает загрузчик
Такой код пишется в ИАРе в рабочем проекте (с рабочим загрузчиком объектов), потом либо перетаскивается в пустой проект, либо собирается в отдельном сегменте, чтобы его можно было легко выкусить. Просто вместо стандартных malloc/free/strcpy будут вызовы _malloc/_free/_strcpy - записи из локальной таблицы импорта

Сообщение отредактировал _dem - Dec 18 2007, 12:15

Как-то сложно и слишком по ПКшному получается. А если стандартных функций сотни? всего-то надо заставить линкер сделать вызов по конкретному адресу.

PS IAR похоже не умеет.

Да, IAR не предусматривает динамической загрузки кода
1. Если стандартных функций - сотни (сотнИ!), то, имхо, в проект просится серьезная ОС, в противном случае у вас где-то не там проведена граница между user code и BIOS.
2. Заставляя линкер делать прямые вызовы, вы потеряте возможность обновить bios без обновления user code
3. На самом деле код загрузчика довольно прост и не съест много памяти - адресное пространство-то единое

Таблица импорта для объекта, даже если там 100 ф-ций - это 400 байт, оверхеда на их вызов никакого (это ARM)

Неудобство в том, что нужно иметь единый .h файл с define-ми для всех функций BIOS

А как быть с системными функциями С? (те которые явно не определены?)
например __longToFloat::??rT , __fMul::??rT .

В линкере создаем секцию типа MY_SPACE_PROGRAMM размером равным максимальному размеру подгружаемой программы.
С помощью команад section_begin и section_end можно получить начало и размер этой области.

далее создаем прототип нашей функции



определяем указатель



инициализируем указатель


делаем операции которые проверяет правельность кода, его наличие и т.д.

вызываем



P.S. а создавая код своей ункции указываеш где и как еще размещать, причем я думаю дак если включить реижм компиляции в библиотеку, приэтом присвоив функции #pragma section="NAME" [align]
то может с этого что то и получится...

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

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

Вам, видимо, нужно что-то попроще. В любом случае, написано в этой ветке достаточно

Определяете линкеру символ с именем функции и адресом ( -Dfunc_name=address, без пробелов) в .xcl, командной строке или на вкладке в оболочке. И все, собственно. Но более гибко - создать таблицу указателей на все такие "bios"-функции и программе давать указатель на эту таблицу.

Купи наладонник, и программируй его под WinCE и будет тибе щастье, а на ARM7 делать такие вещи извращение

Текущий проект - SAM7X, IAR 4.41a, uCOS/II, активных полтора десятка задач, использована почти вся периферия процессора.
библиотечных функций я насчитал примерно на 632 байта, из которых 260 - ?div_module, такой объем вполне можно прилинковать и статически.

Хотя тут все равно надо думать в сторону линкера и адресов.




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

Я когда то делал один проэкт в котором было много разных девайсов по функционалу, но состояли они
на 60% из одинаковых функций. Я сделал так отладил все функции, потом создал к ним один хидер, собрал все функции в один файл и закомпилил в библиотеку. Потом просто ее подключал и пользовал нужные функции.

думаю не все так просто.

Полноценная загрузка должна быть защищенна от неправельного кода и недолжна вызывать сбой устройства. А это дело такое... да же у винды синий экран бывает так что полноценная загрузка это куча кода.

мне кажется, о защите речь не заходила
тем более понятно, так как у ARM7 отродясь не было MCU, от сбойного кода никакая защита не поможет. Watchdog - наш ответ кривому коду.

Давайте на некоторое время спустимся с небес с Windows CE/Linux embedded на грешную землю к ARM7. Имеем девайс, который должен иметь десяток простых алгоритмов обработки поступающих данных + возможность добавления новых. Причем SAM7 нас вполне устраивает по скорости/периферии. А теперь предложим заказчику проект на ARM7 и рядом на ARM9/Cortex/etc (подчеркнуть) с суммами и сроками.

На сим предлагаю дискуссию о целесообразности закончить и перейти к рассмотрению вопроса по существу.

[off] А то станем как на ixbt.com - сначала 3 страницы "а нафига", потом 2 страницы "купи готовое", потом один нормальный совет.[/off]