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

[ArtDenis]

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

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

[AHTOXA]

Вот тут мы сравнивали scmRTOS и TNKernel.

[ArtDenis]

Спасибо за ссылку, но сравнения всего двух RTOS мало.

[ViKo]

Здесь можно посмотреть временные характеристики для Keil RTX. Не знаю, насколько они актуальны.
http://www.keil.com/support/man/docs/rlarm...timing_spec.htm
Нужно искать нечто аналогичное для других ОС.

[Lagman]

Скорость реакции, надо чтобы ОСРВ отработала или достаточно скорости обработки прерывания?
Ведь МК это не ЦП на ПК с ОС, он может приняв внешнее прерывание, не передавая событие в ОСРВ, переварить его в обработчике прерывания (если не сложное вычисление) и отработать событие, при этом ОСРВ будет осуществлять свою работу "параллельно", приостановится на время обработки прерывания. (на процессорах с многоуровневой системой прерываний и FreeRTOS такое можно сделать на раз).

[ArtDenis]

Lagman, под скоростью реакции я имею ввиду промежуток времени от момента уведомления ОС о событии до начала выполнения первых инструкций обработчика события.
Вчера померил это время на серии STM32L152 на максимальной рабочей частоте (32 МГц) с FreeRTOS. Минимум, что удалось выжать с 2-мя задачами - это 11.7 мкс, что довольно печально на мой взгляд. + AHTOXA померил время реакции scmRTOS на VLDiscovery (24 МГц). У него получилось 6.5 мкс, что уже гораздо лучше.

Сообщение отредактировал ArtDenis - Nov 8 2014, 08:16

[AlexandrY]

+ AHTOXA померил время реакции scmRTOS на VLDiscovery (24 МГц). У него получилось 6.5 мкс, что уже гораздо лучше.

Не знаю на что в scmRTOS тратят время, но нормальные RTOS тратят на это в два раза меньше.
Смотрите бенчмарки ChibiOS.

[AHTOXA]

Не знаю на что в scmRTOS тратят время, но нормальные RTOS тратят на это в два раза меньше.
Смотрите бенчмарки ChibiOS.

Ваш наезд насчёт "нормальных" осей выглядит как минимум некрасиво. Нормальные участники форума так не делают.
По вашей ссылке есть ссылка на независимое тестирование, где цифры гораздо более правдоподобны (2.92µs на 72 МГц). У scmRTOS на 72МГц получалось 2.7µs. Причём мы не учитывали время включения и выключения светодиода, как в этой ссылке.

[Mahagam]

эм. только не забывайте, что freertos сравнивать ни с чем нельзя. лицензия не позволяет =8)

[Lagman]

под скоростью реакции я имею ввиду промежуток времени от момента уведомления ОС о событии до начала выполнения первых инструкций обработчика события.
Вчера померил это время на серии STM32L152 на максимальной рабочей частоте (32 МГц) с FreeRTOS. Минимум, что удалось выжать с 2-мя задачами - это 11.7 мкс, что довольно печально на мой взгляд. + AHTOXA померил время реакции scmRTOS на VLDiscovery (24 МГц). У него получилось 6.5 мкс, что уже гораздо лучше.

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

[ArtDenis]

Lagman, у меня методика тестирования простейшая. Есть две задачи. Одна низкоприоритетная и одна - высокоприоритетная. Высокоприоритетная задача ожидает бинарный семафор, и как только получает его, сразу сбрасывает ногу МК. Низкоприоритетная с некоторой периодичностью взводит ту же самую ногу МК и сразу же отдаёт семафор. На осциллографе контролируется длительность импульса на ноге МК.

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

[ZASADA]

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

[AlexandrY]

Ваш наезд насчёт "нормальных" осей выглядит как минимум некрасиво. Нормальные участники форума так не делают.
По вашей ссылке есть ссылка на независимое тестирование, где цифры гораздо более правдоподобны (2.92µs на 72 МГц). У scmRTOS на 72МГц получалось 2.7µs. Причём мы не учитывали время включения и выключения светодиода, как в этой ссылке.

Смотрите лучше по ссылке http://chibios.sourceforge.net/reports/STM32F100-24-GCC.txt

Код

--- Test Case 11.4 (Benchmark, context switch)
--- Score : 364984 ctxswc/S
--- Result: SUCCESS

Т.е. 2,7 мкс на 24 МГц

[ArtDenis]

ZASADA. Я примеры не использовал, а ноги "дрыгаются" самым быстрым способом Настройки ОС выкрутил на максимум, чтобы отключить все навороты. Кстати, со всеми наворотами время реакции получается около 30 мкс

[AHTOXA]

Т.е. 2,7 мкс на 24 МГц

Да, я видел. Это какой-то сильно "синтетический тест". Возможно, просто вызывали в цикле функцию, переключающую контекст. Без собственно оси и всего остального.
2.7мкс на 24 МГц - это всего 64 такта процессора.
12+12 тактов на вход/выход в прерывание планировщика + сохранение контекста (8 регистров + SR = 10 тактов) + восстановление контекста (13 тактов),
Это уже 47 тактов. Осталось 17 тактов. В эти такты надо уместить:

• собственно вызов перепланировки;
• запрет/разрешение прерываний;
• переключение стеков;
• поиск самого приоритетного готового к выполнению процесса;
• ну и, наконец, надо включить и выключить светодиод.

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

[Lagman]

Есть две задачи. Одна низкоприоритетная и одна - высокоприоритетная. Высокоприоритетная задача ожидает бинарный семафор, и как только получает его, сразу сбрасывает ногу МК. Низкоприоритетная с некоторой периодичностью взводит ту же самую ногу МК и сразу же отдаёт семафор. На осциллографе контролируется длительность импульса на ноге МК.

http://we.easyelectronics.ru/NiC/freertos-...heniya-v-2.html

[ArtDenis]

Lagman, время переключения контекста и время реакции - это разные вещи. Точнее сказать, во время реакции на событие входит время переключения контекста. Время же переключения контекста декларируется на сайте freertos в 84 цикла ЦПУ для кортексов: http://www.freertos.org/FAQMem.html#ContextSwitchTime

[Lagman]

время переключения контекста и время реакции - это разные вещи. Точнее сказать, во время реакции на событие входит время переключения контекста. Время же переключения контекста декларируется на сайте freertos в 84 цикла ЦПУ для кортексов: http://www.freertos.org/FAQMem.html#ContextSwitchTime

Я это знаю, что это разные вещи, я давал ссылку там где приводились моменты от которых зависит время переключения контекста, и если вы хотите настроить систему на быстродействие то придется настраивать не только МК и ОСРВ, но еще указать правильные опции компилятору, как и написано в FAQ FreeRTOS, так что дерзайте. А вот тут http://electronix.ru/forum/index.php?showt...t&p=1290397 вам дали ссылку на независимую методику где приводят различные варианты и с мутексами и сообщениями и т.д. и т.д. для ChibiOS. Так что можете хоть что то с чем то сравнить.

[ArtDenis]

придется настраивать не только МК и ОСРВ, но еще указать правильные опции компилятору, как и написано в FAQ FreeRTOS, так что дерзайте.

К тому моменту, когда я написал свои результаты, я уже успел попробовать разные опции оптимизации (-O2, -O3, -Os), а также включал/отключал оптимизацию LTO. Самый быстрый результат был -O3 + LTO. Так что я сомневаюсь, что можно выжать больше. К тому-же мои результаты очень похожи на результаты для FreeRTOS, найденные в интернете.

[AlexandrY]

К тому моменту, когда я написал свои результаты, я уже успел попробовать разные опции оптимизации (-O2, -O3, -Os), а также включал/отключал оптимизацию LTO. Самый быстрый результат был -O3 + LTO. Так что я сомневаюсь, что можно выжать больше. К тому-же мои результаты очень похожи на результаты для FreeRTOS, найденные в интернете.

И что интересует только бинарный семафор? Другие сервисы оси не интересуют?
Например как быстро происходит вход в критическую секцию и какие способы предоставляются.
Я бы на вашем месте заинтересовался именно этим, поскольку это чаще всего используемый сервис в том числе и самой осью.

[ArtDenis]

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

[Lagman]

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

Не хочу расстраивать, но все semaphore во freertos основаны на queues, для этого достаточно посмотреть исходники.

[ArtDenis]

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

[Mahagam]

попробуйте ещё CTL запустить.

[AlexandrY]

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

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

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

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

[LightElf]

К тому моменту, когда я написал свои результаты, я уже успел попробовать разные опции оптимизации (-O2, -O3, -Os), а также включал/отключал оптимизацию LTO. Самый быстрый результат был -O3 + LTO. Так что я сомневаюсь, что можно выжать больше. К тому-же мои результаты очень похожи на результаты для FreeRTOS, найденные в интернете.

Еще хорошо бы померить время реакции для худшего случая, а не для сферического коня. Не удивлюсь, если FreeRTOS всех порвет на тряпки. Ну и там всякие мелочи, типа длительность входа в прерывание в худшем случае.

[AlexandrY]

Еще хорошо бы померить время реакции для худшего случая, а не для сферического коня. Не удивлюсь, если FreeRTOS всех порвет на тряпки. Ну и там всякие мелочи, типа длительность входа в прерывание в худшем случае.

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

Да и то мало смысла сравнивать оси с разной функциональностью.
Скажем смешно сравнивать scmRTOS с MQX.

[LightElf]

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

Ну взять такой пример:
1) высокоприоритетная задача помещена в состояние спячки
2) две задачи с одинаковым приоритетом непрерывно шлют друг другу сообщения размером 8 байт через очередь длиной 16 сообщений (одна задача шлет, другая принимает)
3) на вход внешнего высокоприоритетного прерывания подается импульс
3) обработчик прерывания пробуждает задачу из пункта 1)
4) проснувшаяся задача изменяет состояние ножки
Измеряем время от импульса прерывания до изменения состояния на ноге

Да и то мало смысла сравнивать оси с разной функциональностью.
Скажем смешно сравнивать scmRTOS с MQX.

Ходить - так по большому!

[AlexandrY]

Ну взять такой пример:
1) высокоприоритетная задача помещена в состояние спячки
2) две задачи с одинаковым приоритетом непрерывно шлют друг другу сообщения размером 8 байт через очередь длиной 16 сообщений (одна задача шлет, другая принимает)
3) на вход внешнего высокоприоритетного прерывания подается импульс
3) обработчик прерывания пробуждает задачу из пункта 1)
4) проснувшаяся задача изменяет состояние ножки
Измеряем время от импульса прерывания до изменения состояния на ноге

В MQX такой сценарий для лучшего случая дает 1 мкс (без оптимизации кода, со всеми проверками стека и проч.)
А худший случай по осциллографу увы не смотрят.
Нужно делать нормальный лог статистики. И ради чего?

Для realtime задач такие исследования делаются индивидуально. Никакая заявленная скорость RTOS здесь в учет не принимается.

[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 вполне реалистична. Теперь верю

[ArtDenis]

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

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

[Mahagam]

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

[den_po]

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

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

[Mahagam]

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

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

[MBR]

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

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

[seec]

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

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

[Aner]

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

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

[seec]

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

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

[ViKo]

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

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

[Lagman]

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

По эффективности целый раздел во введении. В частности это event-based HPET таймер с тайм-аутом до 1us и принцип построения безмьютексных систем. Здесь огромный выигрыш как в производительности, так и в энергопотреблении.

Касательно целевой задачи - механизм построения системы будет, в целом, такой же - в этом и есть вся суть ОСРВ. Чтение данных с сенсора выносится в драйверы, обсчет в более высокоуровневый приоритет, управление - в менее.

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

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

В частности, для STM32F1 при частоте 72mhz, время вызова ядра: 1.3us, время переключения контекста (включая непосредственно работу ядра и само вытеснение): 6us.

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