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

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



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

Да ладно, все просто. В моей сегодня-скачанной версии 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 (тем более там дополнительные обращения к памяти за значениями приоритета, так и за счетчиком вложенности), но, при некотором извращении позволяет оставлять разрешенными прерывания с приоритетом выше заданного. Обработчики таких прерываний будут ограниченными по функционалу, но чисто формально можно заявить что прерывания полностью не запрещаются.


Не, мне лениво, у меня сейчас полное ретро - 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 вполне реалистична. Теперь верю

Эх, в итоге я так и не осилил scmRTOS и ChibiOS, которые хотел попробовать. scmRTOS у меня так и не завёлся с моим ассемблерным стартапом и скриптом линкера, а ChibiOS не завёлся без его HAL, который мне вообще не сдался. А на эти две ОС как раз была надежда именно в малом времени реакции...
Придётся использовать FreeRTOS (который завёлся сразу и не навязывал свои стартапы, скрипты линкера или HAL), несмотря на его большое время реакции.

Сообщение отредактировал ArtDenis - Nov 17 2014, 12:35

ещё раз. смотрите в сторону кроссворка. стиль кода куда читаемее чем у фриртоса.

Чей стиль кода? Операционки? У рядового разработчика необходимости заглядывать в её исходники вообще не должно быть.

на этапе выбора этой самой операционки - ещё какая! а если разработчик нерядовой? то что делать? ))

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

У меня в REx получается около 6us при 72MHz. При этом простой вызов ядра - 1.9us. Я считаю время более чем приемлимым. Мало того, если включить профилирование (время работы процесса, размер использованной кучи и стека и т.д.), время увеличивается до целых 11us, но какой-либо потери производительности от этого я не заметил. Код теста есть в примерах.

Остановились на чём нибудь окончательно?
топчусь перед выбором ОС РВ не знаю куда податься...
(STM32F7)

... а что за реалтайм задачи перед вами перед ... податься? И чем RTOS не устроил?

подозреваю что совсем не эксклюзивные-обычное управление железкой (ну взрывоопасной малость)
сейчас всё крутится на AVR, вообще без ОС - ручками память, ручками семафоры, ручками прерывания...
но нельзя же вечно жить на 128кБ (тем более что их уже стало не хватать), да и хочется всяких готовых GUIёв, сетевых библиотек...
на красивости потянуло, сечас код практически нечитаем людьми со стороны, если есть возможность привести базу к общему с другими людьми виду и заниматься только функциональной частью, то почему этого не сделать... (для меня увеличивается шанс успешно спихнуть проект в другие руки)
+АТМЕЛ малость достала со своими маркетинговыми закидонами, но это к вопросу отношения не имеет.

Если пользуетесь Кейлом, посмотрите RTX.

Понимаю что тема старая и тут уже сам автор (MBR) написал , но случайно наткнулся в ЖЖ на "рекламу", исходники в открытом доступе (про лицензию еще не читал), документация присутствует на русском, OS в свободном доступе для STM32, присутствует ядро, свой std, куча драйверов, библиотек и стеков.
Автор пишет про


А кто нибудь уже пробовал эту ОСРВ (кроме автора MBR)? Как впечатление?