Написал порт scmRTOS под ARM, интересны отзывы Опции

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

Написал порт scmRTOS (http://scmrtos.narod.ru/) для ARM. Отлаживал на AT91SAM7S64. Поскольку опыта в ARMах пока маловато (второй проект на ARM и первый с асмом), то перед тем как связываться с автором хотелось бы чтобы кто-то более опытный глянул. Порт лежит тут: http://upload.caxapa.ru/scmRTOS_arm.zip
Спасибо всем.

[GetSmart]

Странно, но почему-то в моем макете с AT91SAM7S64 при отладке через MT-Link перегрузки CPSR не происходит. Могу попробовать на LPC2119, но не думаю что будет большая разница.

Совсем забыл. Перезагрузка CPSR происходит только когда процессор находится не в USER или SYSTEM режиме. Потому что в этих режимах регистра SPSR вообще нет. Команда как бы некорректная, хотя процессор не падает. И ещё. Прочитать (загрузить в CPSR) можно только SPSR текущего режима. Запись в SPSR - аналогично. Даже если в команде явно будет указан регистр SPSR из другого режима. Непонятно только, зачем ассемблер разрешает так писать.

У вас вообще по какому событию происходит переключение?

А для чего или кого вообще пишите?

Сообщение отредактировал GetSmart - May 17 2006, 16:42

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

Странно, но почему-то в моем макете с AT91SAM7S64 при отладке через MT-Link перегрузки CPSR не происходит. Могу попробовать на LPC2119, но не думаю что будет большая разница.

Совсем забыл. Перезагрузка CPSR происходит только когда процессор находится не в USER или SYSTEM режиме.

Все это понятно. На это я с самого начала нарвался :-) У меня эта команда выполнятеся в IRQ_mode.
Но все же я настаиваю, что восстановление CPSR происходит только в одном варианте команды: когда стоит крыжик (^) И в списке регистров есть R15(PC). При этом восстанавливаются регистры в банке соотв. режима исключений. Если же в команде стоит крыжик и R15 в списке нет, то восстанавливаются регистры user(system) банка и CSPR не восстанавливается.
Или другими словами: если в списке LDM есть R15, то крыжик означает восстановление CSPR, если R15 нет - то крыжик означает восстановление в _user регистры. Детализируя:
LDMxx {R13-R15}^ восстанавливает R13_mode, R14_mode, PC, SPSR_mode->CPSR
LDMxx {R13-R14}^ восстанавливает R13_user, R14_user
Именно так происходит в железе (LPC2119 тоже проверил). Можете проверить. Симулятор же отрабатывает эту команду иначе. Я не вижу ничего незаконного в этой команде поэтому продолжаю считать что в этом случае симулятор явно ошибается.

Даже если в команде явно будет указан регистр SPSR из другого режима. Непонятно только, зачем ассемблер разрешает так писать.

Ассемблер не позволяет их указывать. Это в описании ядра они имеют такие обозначения.

У вас вообще по какому событию происходит переключение?

Планировщик взводит бит программного прерывания в контроллере прерываний.

А для чего или кого вообще пишите?

Для себя :-) Готовлю почву для новых проектов. FreeRTOS не понравилась чрезмерными требованиями к ОЗУ и кривизной написания. scmRTOS использовал в одном проекте на MSP430, понравилась. Из кристаллов под рукой есть макетки с SAM7 и LPC, есть еще ADuС, но на нем пока только пример из иара запускал. Ближайшие 2 проекта будут на ADuC и LPC.

Сообщение отредактировал Сергей Борщ - May 17 2006, 17:01

[zltigo]

Не сочтите за 'наезд' - работа несомненно полезная! Однако не могу не отметить, что основная прадигма отлично реализованная в scmRTOS на типичном ARM смотрится уже не так привлекательно,
как на AVR с полукилобайтом-килобайтом памяти.

FreeRTOS не понравилась чрезмерными требованиями к ОЗУ и кривизной написания.

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

Код

Module               CODE      DATA      CONST
------               ----      ----      -----
                    (Rel)  (Rel)  (Abs)  (Rel)
?CMAIN                108
?CSTARTUP              56
?EnI_t                 20
?RESET
  + common             60
?_EXIT                 12
?__dbg_break            2
?__exit                18
?cppinit               70
?exit                  14
?segment_init          84
OS_Kernel             300     40
  + shared             32             8     12
OS_Services            16
OS_Target_cpp         272    108
  + shared                            8
main                  478    940    220
scmRTOS_Asm           132
  + common             28
N/A (command line)           768
N/A (alignment)        10
----------          -----  -----    ---     --
Total:              1 624  1 856    236     12
  + common             60

И под FreeRTOS такой-же:

Код

Module               CODE      DATA      CONST
------               ----      ----      -----
                    (Rel)  (Rel)  (Abs)  (Rel)
?CMAIN                 80
?CSTARTUP             476
?DiI_t                 32
?EnI_t                 16
?RESET
  + common             64
?_EXIT                 12
?__exit                 2
?exit                  14
?segment_init          84
?strncpy               44
croutine
  + shared                                  12
heap                  244     24
leds                   76             8
  + shared                            4
list                  174
ll_init                 4
main                  186             8     16
port                  376      4     40     16
portasm               340
tasks                 902    168             8
N/A (command line)           530
N/A (alignment)        10
----------          -----    ---     --     --
Total:              3 072    726     60     52
  + common             64

Собственно разница по декларированному критическому ресурсу (RAM занимаемому ядром) отнюдь не впечатляет:
scmRTOS = 0x148 байт
FreeRTOS = 0x1AC
Итого - 100(dec) байт. Не слишком большая плата за несколько отличающюся базовую функциональность и (личное мнение) за большую способность к доработкам.
Причем, при "необходимости" можно убрать еще по 8 байт на задачу во FreeRTOS :-)

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

FreeRTOS не понравилась чрезмерными требованиями к ОЗУ и кривизной написания.

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

Объясню очень просто: указатели на любой объект передаются как void* что легко позволяет мне передать вместо указателя на семафор указатель на процесс или очередь. Зачем же в "языке высогага уровня Ц" был придуман контроль типов на этапе компиляции? Далее это же void * передается в другие функции место указателя соответствующего типа, а чтобы компилятор не выдавал предупреждения вместо элементарного создания локальной переменной нужного типа и приведения типа

Код

signed portBASE_TYPE xQueueSend( xQueueHandle xQueue, const void *pvItemToQueue, portTickType xTicksToWait )
{
xQueuePtr pxQueue = xQueue;

в описании предлагается задавить предупреждения этого типа в опциях компилятора. Причем предупреждения возникают при компиляции кода самой ОС. Что же это как не кривизна?

а по RAM..

46 байт на битовый семафор мне показалось расточительно. Они его реализуют как очередь из одного элемента нулевого размера. Да и на очередь 46 байт ОЗУ накладных "жаба душит".

Cобрал Ваш демо проект с тремя светодиодиками:
Собственно разница по декларированному критическому ресурсу (RAM занимаемому ядром) отнюдь не впечатляет:
scmRTOS = 0x148 байт
FreeRTOS = 0x1AC
Итого - 100(dec) байт. Не слишком большая плата за несколько отличающюся базовую функциональность и (личное мнение) за большую способность к доработкам.
Причем, при "необходимости" можно убрать еще по 8 байт на задачу во FreeRTOS :-)

Я не отрицаю большого потенциала в FreeRTOS. Однако в моем примере из базовой функциональности был только один сервис Sleep(). Оно и понятно - надо было отладить переключатель контекста. Более серьезный пример идет в исходнике scmRTOS с сайта автора. Там есть и семафоры и очереди. Если есть желание - можем сравнить.
Еще раз - я не хоче наступить на горло FreeRTOS, просто мне она субъективно не понравилась.

[zltigo]

Еще раз - я не хоче наступить на горло FreeRTOS, просто мне она субъективно не понравилась.

Это пожалуй главное. Так бывает. Я тоже не в восторге от многого, но идеал при знании потрохов :-)
недостижим, посему начал просто править "под себя" и под свой "вкус". А как "база" максимально устроила.

Объясню очень просто: указатели на любой объект передаются как void*

Ну такуж и на любой. Семафоры ака очередь это отдельная песня и при необходимости иметь оные несомненно буду встраивать 'семафористые' семафоры :-).

Причем предупреждения возникают при компиляции кода самой ОС. Что же это как не кривизна?

Это бардак :-(, такие места правлю, правда "легкой" c "наплевать на warnings" переносимости под разные компиляторы уже гарантировать нельзя.

Более серьезный пример идет в исходнике scmRTOS с сайта автора. Там есть и семафоры и очереди. Если есть желание - можем сравнить.

Нет, особого желания нет. Порядок "платы" ясен и меня совсем не смущают пару сот байт, особенно по отношению к размеру стеков (особенно при отсутствии даже простейших механизмов контроля обьема использования стека присутствующих в FreeRTOS) задач :-(. Кстати о стеках, на штатное (руками и так реализуется без напряга) нововведение FreeRTOS 4.x обратили внимание?

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

Объясню очень просто: указатели на любой объект передаются как void*

Ну такуж и на любой. Семафоры ака очередь это отдельная песня и при необходимости иметь оные несомненно буду встраивать 'семафористые' семафоры :-).

typedef void * xQueueHandle;
typedef xQueueHandle xSemaphoreHandle;
typedef void * xTaskHandle;
Собственно других открытых пользователю сервисов там вроде и нет.

Более серьезный пример идет в исходнике scmRTOS с сайта автора. Там есть и семафоры и очереди. Если есть желание - можем сравнить.

Нет, особого желания нет. Порядок "платы" ясен и меня совсем не смущают пару сот байт, особенно по отношению к размеру стеков (особенно при отсутствии даже простейших механизмов контроля обьема использования стека присутствующих в FreeRTOS) задач :-(.

Надо будет этот вопрос изучить, спасибо за наводку.

Кстати о стеках, на штатное (руками и так реализуется без напряга) нововведение FreeRTOS 4.x обратили внимание?

Нет, я работал с 3.2.2, как проект сдал больше на FreeRTOS.org не заглядывал. Посмотрю обязательно, спасибо.

[zltigo]

typedef void * xQueueHandle;
typedef xQueueHandle xSemaphoreHandle;
typedef void * xTaskHandle;

А здесь-то криминал-то в чем? Совершенно разные типы. Я 'дико извиняюсь', но это
typedef а не define - любой компилятор находясь в твердом уме и здравой памяти обломает
подмену безвариантно.

Нет, я работал с 3.2.2, как проект сдал больше на FreeRTOS.org не заглядывал. Посмотрю обязательно, спасибо.

Кстати :-) обратите внимание, там в переключении контекстов 'nop'-чик недавно добавился...

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

typedef void * xQueueHandle;
typedef xQueueHandle xSemaphoreHandle;
typedef void * xTaskHandle;

А здесь-то криминал-то в чем? Совершенно разные типы. Я 'дико извиняюсь', но это
typedef а не define - любой компилятор находясь в твердом уме и здравой памяти обломает
подмену безвариантно.

Совсем не уверен. Во всяком случае

Код

    int x,y;
    xQueueReceive(&x, &y, 0);

IAR съел молча, хотя int* это совсем не xQueueHandle. И что-то мне казалось что в С это не разные типы а синонимы, это в С++ будут разные типы.

По сравнению объемов мне непонятно откуда такие цифры? Чего-то вы напутали. Заглянул в .map, получил там такое:

Код

OS::Kernel      0x28
IdleProcess     0x6c
Proc1           0x134 ( 8 + 0x12C stack)
Proc2           0x134 ( 8 + 0x12C stack)
Proc3           0x134 ( 8 + 0x12C stack)

Т.е. ядро+Idle занимает 148 байт плюс по 8 байт на каждый процесс. Остальное - стеки прцессов. Счас буду делать аналогичный тест с FreeRTOS, сравню сам. Еще особенность - я не правил .xcl из ИАРовского примера, поэтому возможно погрешность ползет оттуда: в качестве IRQ_STACK в scmRTOS используется CSTACK, да и его размер в .xcl определен как 0x400 что явно замного. Продолжаю эксперименты. Счас попробую замерить время переключения контекстов.

Кстати :-) обратите внимание, там в переключении контекстов 'nop'-чик недавно добавился...

Еще один? :-))

[zltigo]

Совсем не уверен. Во всяком случае

Код

    int x,y;
    xQueueReceive(&x, &y, 0);

IAR съел молча, хотя int* это совсем не xQueueHandle. И что-то мне казалось что в С это не разные типы а синонимы, это в С++ будут разные типы.

Ну начинаем выкручиваться:
1. Амперсандик добавили, спасибо, что не (xQueueHandle) :-)
2. С настройками компилятора разберитесь, ибо я, естественно, как и положено, получил

Код

D:\ARM_WORK\COMMON\LPC2000\rtc.c(107) : Warning[Pe167]: argument of type "int *" is incompatible with parameter of type "xQueueHandle"

По сравнению объемов мне непонятно откуда такие цифры? Чего-то вы напутали. Заглянул в .map, получил там такое:

Тоже из MAP. MAP в тестовом виде прилагается, кстати, был в свое время обрадован IARовским
HTML мапом. Смотрите в приложении:
* MODULE SUMMARY *
Делал только сборку, ничего не менял, на железо не переносил.

Счас буду делать аналогичный тест с FreeRTOS, сравню сам. Еще особенность - я не правил .xcl из ИАРовского примера, поэтому возможно погрешность ползет оттуда: в качестве IRQ_STACK в scmRTOS используется CSTACK, да и его размер в .xcl определен как 0x400 что явно замного.

Это Правильно! Едиственное изменение мною для уравнивания шансов конфигурирось количество приоритетов равное числу задач, ибо так и в scmRTOS. И отключальтись дополнитительные
наворотики. Собственно конфигурация в приложении. На железо заливалось.
Результат возможно будет даже немного лучше при компиляции базовой FreeRTOS, ибо я своего надобавлял.

Счас попробую замерить время переключения контекстов.

Если мне не изменяет память, то я получил на уровне 7us. Но это при ЧЕСТНОМ измерении,
от момента ВНЕШНЕГО а не таймерного прерывания и до проднятия задачи дергающей PIN.
Время это время для FreeRTOS, естественно, не фиксированное. Задач было около 6. Можно
повторить под протокол, но через недельку - болею сейчас.

Еще один? :-))

Если последняя рассматриваеваемая Вами версия была 3.X.X, то помнится да.