Насколько трудно портировать scmRTOS под Keil? Опции

[DimaM]

Нравится мне C++ и поэтому smcRTOS интересна, хотел попробовать портировать под Keil, но из за того что с IAR не работал проблемы возникли.

И возник вопрос - а стоит ли связыватся? Как авторы и народ оценивают количество специфических для IAR вещей?

[Сергей Борщ]

Как авторы и народ оценивают количество специфических для IAR вещей?

Несколько макросов в сишных исходниках (INLINE, OS_INTERRUPT, OS_PROCESS) и один асмовый файл. Причем код в асмовом файле переписывать скорее всего не нужно, только директивы ассемблера. Ну и линкерные скрипты, если дефолтные не подойдут. Могу консультировать "что эта фИгня делает в ИАРе" (лучше через ICQ), но поскольку с кейлом не работаю, подсказать "а как это будет в Кейле" скорее всего не смогу.
Портирование на GCC сложнее, ибо он не позволяет указывать thumb или arm для конкретной функции, только для файла целиком.

[DimaM]

Несколько макросов в сишных исходниках (INLINE, OS_INTERRUPT, OS_PROCESS) и один асмовый файл. Причем код в асмовом файле переписывать скорее всего не нужно, только директивы ассемблера. Ну и линкерные скрипты, если дефолтные не подойдут. Могу консультировать "что эта фИгня делает в ИАРе" (лучше через ICQ), но поскольку с кейлом не работаю, подсказать "а как это будет в Кейле" скорее всего не смогу.
Портирование на GCC сложнее, ибо он не позволяет указывать thumb или arm для конкретной функции, только для файла целиком.

я думаю часть вопросов может быть интересна не только мне
например что делают OS_INTERRUPT, OS_PROCESS
может что то выскажут и знатоки keil, например как со стеком обходится.

[Сергей Борщ]

я думаю часть вопросов может быть интересна не только мне

Возможно, им более интересно, чтобы вы выложили уже готовый порт?

например что делают OS_INTERRUPT, OS_PROCESS

Код

#if scmRTOS_CONTEXT_SWITCH_SCHEME == 0
    #define OS_INTERRUPT __arm
#else
    #define OS_INTERRUPT __arm __irq
#endif

Тут, кажется, все понятно и без комментариев. Абисьнять?

Код

#define OS_PROCESS

Т.е. не делает ничего. Заглянув в порт для AVR можно увидеть такое объявление:

Код

#define OS_PROCESS    __task

Т.е. если у кейла есть возможность определить функцию, для которой не надо сохранять контекст на стеке (аналог __attribute__((__naked__)) в GCC) - используйте ее здесь.

может что то выскажут и знатоки keil, например как со стеком обходится.

Со стеком там работа идет на асме, зависимости от компилятора в ней нет.

[DimaM]

Возможно, им более интересно, чтобы вы выложили уже готовый порт?

Код

#define OS_PROCESS

Т.е. не делает ничего. Заглянув в порт для AVR можно увидеть такое объявление:

Код

#define OS_PROCESS    __task

Т.е. если у кейла есть возможность определить функцию, для которой не надо сохранять контекст на стеке (аналог __attribute__((__naked__)) в GCC) - используйте ее здесь.Со стеком там работа идет на асме, зависимости от компилятора в ней нет.

если осилю то выложу для всех, только сомнения есть - например __task у keil есть, но описан как ключевое слово их собственной RTOS.

[ReAl]

если осилю то выложу для всех, только сомнения есть - например __task у keil есть, но описан как ключевое слово их собственной RTOS.

А это надо глянуть, что при этом генерируется на уровне команд. Варианта два

- Это ключевое слово используется в их ОС, но в итоге достаточно "самостоятельное", просто меняет (убирает) прологи/эпилоги, не вставляя никакого специфического кода для их ОС.
В этом случае его удастся использовать и в scmRTOS

- Слово сильно завязано на их ОС, напихивает в код чего-то непонятного.
Тогда OS_PROCESS надо оставить пустым, единственная беда - будет некоторый перерасход стека процесса на сохранение тех регистров, которые реально никогда не будут восстанавливаться плюс немного больше займёт код процесса. Но всё работать будет.