Технология динамической загрузки модулей для RTOS, Какие есть методы и инструменты. Опции

[AlexandrY]

Как-то тут проскочила мысль, что настоящая операционная система должна грузить сторонние приложения и выполнять их.

Очевидно, что это реализовать для небольших проектов и даже не с ОС совершенно элементарно.
Для этого при компиляции основного ядра делают symbol definition file и потом этот файл и файлы хидеров передают третьей стороне чтобы те могли правильно скомпилировать и слинковать свои приложения для ядра.

Но когда в ядре количество функций переваливает за тысячу, то сделать переносимые хидеры в ручную представляется проблемой.
Также желательно сделать отдельный модуль с так называемой jump table чтобы уменьшить зависимость от мелких изменений и перекомпиляций ядра. Как-то подумать о фильтрации, чтобы не все подряд сущности из ядра попадали в symbol definition file и т.д.

И тогда вопрос - заморачивается ли кто-нибудь с этим и известны ли инструменты автоматизации всего этого процесса.

[desh]

Контики от А. Дункельса и компании поддерживает загрузку модулей через elf для AVR, MSP430, x86 и др.
Ознакомиться с исходниками можно в contiki-2.6\core\loader\.
Сайт проекта http://www.contiki-os.org/

[SyncLair]

Контики от А. Дункельса и компании поддерживает загрузку модулей через elf для AVR, MSP430, x86 и др.
Ознакомиться с исходниками можно в contiki-2.6\core\loader\.
Сайт проекта http://www.contiki-os.org/

для AVR он немного "испортил" эльф и сделал его 16-и битным

Насчёт взаимодействия загружаемого модуля и ядра, моногие ARM-ы, например, имеют команду SVC - Supervisor Call, которая вызывает соответствующий .....

Вот этот пример показывает разницу между ABI и API ибо в первом случае чётко определены параметры вызовов и поэтому любая "прикладная задача" в ОС может воспользоваться функциями. Вопрос только в с ледующем а как же быть если есть задача и библиотека, и сначала грузиться библиотека а потом задача? и функции библиотеки не определены в SVC.


И на последок:

Координальное на мой взгляд решение в ембеддед мире -- специально готовить исполняемый прикладной файл с учётом того, что уже есть на плате. То есть линкер должен знать какое состояние флеши в контроллере и готовить очередной "прикладной процесс" (понятно что прикладной в смысле не ОС которая УЖЕ в МК) с учётом того что уже есть на плате. То есть ну вот есть функция TimeDelay() по адресу А так и не зачем пихать ещё одну а делаем вызов по адресу A.

Или если совсем просто, то пусть линкер линкует старые и новые объектные файлы только старые размещает по старому с нулевого адреса а новые далее. В этом случае загрузчику остаётся только сначала сделать memcmp, а уж потом оставшийся новый код догрузить во FLASH.

[haker_fox]

То есть ну вот есть функция TimeDelay() по адресу А так и не зачем пихать ещё одну а делаем вызов по адресу A.

Это правильно, но как этого добиться от линкера? Он-то о существовании оси не знает.
Допустим, у нас есть API для уже загруженной в МК операционки:

CODE

namespace OSAPI
{
void sleep( msec );
...
...
...
TPrio getSelfPrio();
...
...
...
void sendchar( char a );
}

Совершенно разные функции, которые уже есть в оси, на которые уже все заточено (прерывания, периферия, ядро). Допустим, мы решили воспользоваться одной из функций в нашем прикладном коде (драйвер, подгружаемая библиотека, просто программа):

CODE

....
int main( void )
{
....
while( 1 )
  {
    OSAPI::sleep( 100 );
    OSAPI::sendchar( '!' );
  }
....

Вот как объяснить линкеру, что нужно подставить только адреса функций, передать и принять аргументы.
Кроме, как в заголовочнике задать адреса этих функций (точно также, как мы делаем это в одном проекте "по месту") у меня идей нет... Вопрос, как сделать это красиво?

[kolobok0]

..есть API для уже загруженной в МК операционки...мы решили воспользоваться одной из функций в нашем прикладном коде...нужно подставить только адреса функций, передать и принять аргументы..

под AVR делал так:
имеем таблицу джампов переходов. Адресс таблицы "зашит жёстко". Сам по себе вектор может указыватьна любой адресс. А чтоб вызвать из прикладной прожки - то адресс известен. получается, что из любого места позвали известный адресс джамп перехода из ядра.

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

[AlexandrY]

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

А вот интересно , какой смысл у такой организации софта.

Вижу три варианта: для себя, для коллег в своей организации, для сторонних разработчиков.

Чтобы делать это для себя тут я вижу оправдание только в некоей эстетике, не относящейся к объективной необходимости.
Чтобы делать для коллег, то наверно это вызвано технологическими особенностями процесса разработки, а не потребностью приложения как такового.
Для сторонних разработчиков такой подход вызовет потребность создания огромного объема документации, проблемы с тех поддержкой. Для самих сторонних разработчиков вызовет проблемы с отладкой.

А где положительные стороны такого подхода? Я не могу увидеть.

[kolobok0]

..какой смысл у такой организации софта....

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

[AlexandrY]

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

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

В малых встраиваемых системах время загрузки вообще ничтожно. Килобайт или мегабайт вы грузите никто не заметит. Разница будет в долях секунды. Некоторая периферия гораздо дольше инициализируется.

Апдейт софта проще сделать когда апдейтится все. Иначе головная боль с совместимостью версий софта платформы и загружаемого приложения.
Проще после загрузки вытеснить весь старый софт новым, либо старый софт оставить в качестве начального загрузчика не используя его для приложения.

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

Т.е. я как бы совсем не понял ваших аргументов.

[kolobok0]

...мало относящемся к загрузке сторонних приложений.

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

...или мегабайт вы грузите никто не заметит. Разница будет в долях секунды...

как бы Вы поспешили я так понимаешь. мегабайты через какой-нить вяложующий протокол и вся ваша прыть с крутым камнем идёт лесом.

...Апдейт софта проще сделать...

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

..Иначе головная боль с совместимостью версий софта...

для меня - это пройденный этап. с точки зрения исполнения - пара-тройка экранов на сях...

...я как бы совсем не понял ваших аргументов.

и вас вылечим
я собственно не спорю. скорее всего я не прав. человек спрашивал я ответил... тащить кого то в колхоз - честно слово времени нет вообще...