Сравнение RTOS для STM32 по времени реакции Опции

[ArtDenis]

Приветствую всех. Для проекта выбираю RTOS с вытесняющей многозадачностью. Основной критерий выбора - скорость реакции. Не хочется пробовать друг за другом все популярные RTOS для замера времени реакции, т.к. это займёт какое-то время. Может существует уже готовое сравнение времени реакции различных RTOS на STM32 (не важно для какого семейства)? Заранее спасибо.

Сообщение отредактировал ArtDenis - Nov 7 2014, 15:24

[ArtDenis]

С горем пополам запустил scmRTOS и померил время реакции на том же камне - 5.52 мкс
Спасибо AHTOX-е за его консультации при запуске )

[AlexandrY]

С горем пополам запустил scmRTOS и померил время реакции на том же камне - 5.52 мкс
Спасибо AHTOX-е за его консультации при запуске )

На Kinetis MK60 120 МГц RTOS MQX при переключении контекста через сервис флагов получается время 3 мкс (369 тактов)

При этом:
-флаги могут быть с автоматическим сбросом или без,
-время не зависит от маски флагов,
-не запрещаются прерывания ядра,
-у задач разрешен планировщик time slice,
-на ожидании флага может стоять очередь задач.

Т.е. сервис остается еще довольно навороченным.

[VslavX]

На Kinetis MK60 120 МГц RTOS MQX при переключении контекста через сервис флагов получается время 3 мкс (369 тактов)

Интересно, я смотрел MQX несколько лет назад, операционка хороша развитым middleware, но само ядро там слишком громоздкое и не может быть быстрым, имхо. Как бы цифра вызывает сомнения, но я смотрел давно, еще версию 3.7, надо будет собрать и погонять на STM32. Ну или К60 сам по себе фантастически быстрый, что тоже маловероятно. Или цифра 3 мкс никак не коррелирует с теми тестами по переключению контекста что мы с AHTOXA когда-то проводили. В-общем, у меня не сходится

-не запрещаются прерывания ядра,

А что такое прерывания ядра?
Сейчас специально скачал свежую версию 4.1.0 для K60. Посмотрел функцию sem_post(), там все те же макросы _INT_ENABLE, _INT_DISABLE которые выливаются для CortexM3 в инструкции cpsie и cpsid. Да еще оно считает уровень вложенности запрета прерываний, что тоже скорости не добавляет. Так что все там банально в MQX, запрещает она прерывания как миленькая. Или я куда-то не туда посмотрел?

-у задач разрешен планировщик time slice,
-на ожидании флага может стоять очередь задач.

Т.е. сервис остается еще довольно навороченным.

Ну этим уже тыщу лет никого не удивишь, это многие старенькие RTOS типа TNKernel/FreeRTOS давно умеют.

[AlexandrY]

А что такое прерывания ядра?
Сейчас специально скачал свежую версию 4.1.0 для K60. Посмотрел функцию sem_post(), там все те же макросы _INT_ENABLE, _INT_DISABLE которые выливаются для CortexM3 в инструкции cpsie и cpsid. Да еще оно считает уровень вложенности запрета прерываний, что тоже скорости не добавляет. Так что все там банально в MQX, запрещает она прерывания как миленькая. Или я куда-то не туда посмотрел?

Сильны же вы макросы смотреть.
Там без поллитра ничего не высмотришь.
Только пошаговая отладка позволяет понять какой там из кучи вариантов макросов реально выполняется.
В моей тестовой конфигурации просто повышался приоритет разрешенных прерываний.
На прерывания ядра (т.е. не проходящие через планировщик RTOS) у MQX выделено 4-е верхних уровня.
Полное запрещение прерываний не производится.

На STM32 порта MQX вообще-то нет. Забавно будет если кто-то его сделает.

Ну этим уже тыщу лет никого не удивишь, это многие старенькие RTOS типа TNKernel/FreeRTOS давно умеют.

Умеют они там или не умеют не так важно. Важно в честном сравнении это упоминать.

[VslavX]

Сильны же вы макросы смотреть.
Там без поллитра ничего не высмотришь.

Да ладно, все просто. В моей сегодня-скачанной версии 4.1.0:
_INT_DISABLE/_INT_ENABLE определяются в одном файле mqx_prv.h, в итоге они или вызывают функции _int_disable/_int_enable определенные в int.c. Вариант когда MQX работает без прерываний (MQX_USE_INTERRUPTS == 0) не рассматриваем как вырожденный, поэтому интересующие нас макросы всегда приводят к макросам _INT_DISABLE_CODE/_INT_DISABLE_CODE в инлайновом или вынесенном в функции варианте. Эти макросы юзают _PSP_SET_DISABLE_SR и _PSP_SET_ENABLE_SR.

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

Да, там действительно просмотрел ветвление между Cortex-M0 и Cortex-M4. Для Cortex-M4 производится модификация регистра BASEPRI. Это еще медленнее чем cpsie/cpsid (тем более там дополнительные обращения к памяти за значениями приоритета, так и за счетчиком вложенности), но, при некотором извращении позволяет оставлять разрешенными прерывания с приоритетом выше заданного. Обработчики таких прерываний будут ограниченными по функционалу, но чисто формально можно заявить что прерывания полностью не запрещаются.

На STM32 порта MQX вообще-то нет. Забавно будет если кто-то его сделает.

Не, мне лениво, у меня сейчас полное ретро - PDP-11 всякий разный в качестве хобби.

Умеют они там или не умеют не так важно. Важно в честном сравнении это упоминать.

Ну так тут пробегала ссылка в начале на тему с тестами, там и исходник приложения тестового был, кажется, прогнали бы, да назвали реальные цифры - вот и честное сравнение. Я сейчас просмотрел подробно sem_post, ну ничего нового, все та же банальщина - убрать задачу из двойного списка ожидающих таймер, убрать из ожидающих, добавить в активные, и все это сопровождается всякими относительно избыточными (относительно предельно вылизанных TNKernel или scmRTOS) телодвижениями - модификацией размера очереди и прочим. Хм, переключатель контекста сделан вообще громоздко - или сразу PendSV ставит, или выполняет svc где в обработчике опять таки PendSV ставится. Ну и cpsid/cpsie в перекллючателе контекста все-таки есть.

Update: перечитал тему по "мерянью" временем переключения контекста, там цифра 1.30 мкс на STM32F205 120МНz, 3WS, IAR6.30. ScmRTOS еще чуток быстрее. То есть ~3мкс для MQX на 120МГц К60 вполне реалистична. Теперь верю