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

[ArtDenis]

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

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

[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, найденные в интернете.

[LightElf]

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

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

[AlexandrY]

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

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

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

[LightElf]

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

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

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

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