Lagman 1 8 ноября, 2014 Опубликовано 8 ноября, 2014 · Жалоба Есть две задачи. Одна низкоприоритетная и одна - высокоприоритетная. Высокоприоритетная задача ожидает бинарный семафор, и как только получает его, сразу сбрасывает ногу МК. Низкоприоритетная с некоторой периодичностью взводит ту же самую ногу МК и сразу же отдаёт семафор. На осциллографе контролируется длительность импульса на ноге МК. http://we.easyelectronics.ru/NiC/freertos-...heniya-v-2.html Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ArtDenis 0 9 ноября, 2014 Опубликовано 9 ноября, 2014 · Жалоба Lagman, время переключения контекста и время реакции - это разные вещи. Точнее сказать, во время реакции на событие входит время переключения контекста. Время же переключения контекста декларируется на сайте freertos в 84 цикла ЦПУ для кортексов: http://www.freertos.org/FAQMem.html#ContextSwitchTime Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Lagman 1 9 ноября, 2014 Опубликовано 9 ноября, 2014 · Жалоба время переключения контекста и время реакции - это разные вещи. Точнее сказать, во время реакции на событие входит время переключения контекста. Время же переключения контекста декларируется на сайте freertos в 84 цикла ЦПУ для кортексов: http://www.freertos.org/FAQMem.html#ContextSwitchTime Я это знаю, что это разные вещи, я давал ссылку там где приводились моменты от которых зависит время переключения контекста, и если вы хотите настроить систему на быстродействие то придется настраивать не только МК и ОСРВ, но еще указать правильные опции компилятору, как и написано в FAQ FreeRTOS, так что дерзайте. А вот тут http://electronix.ru/forum/index.php?showt...t&p=1290397 вам дали ссылку на независимую методику где приводят различные варианты и с мутексами и сообщениями и т.д. и т.д. для ChibiOS. Так что можете хоть что то с чем то сравнить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ArtDenis 0 9 ноября, 2014 Опубликовано 9 ноября, 2014 · Жалоба придется настраивать не только МК и ОСРВ, но еще указать правильные опции компилятору, как и написано в FAQ FreeRTOS, так что дерзайте. К тому моменту, когда я написал свои результаты, я уже успел попробовать разные опции оптимизации (-O2, -O3, -Os), а также включал/отключал оптимизацию LTO. Самый быстрый результат был -O3 + LTO. Так что я сомневаюсь, что можно выжать больше. К тому-же мои результаты очень похожи на результаты для FreeRTOS, найденные в интернете. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 9 ноября, 2014 Опубликовано 9 ноября, 2014 · Жалоба К тому моменту, когда я написал свои результаты, я уже успел попробовать разные опции оптимизации (-O2, -O3, -Os), а также включал/отключал оптимизацию LTO. Самый быстрый результат был -O3 + LTO. Так что я сомневаюсь, что можно выжать больше. К тому-же мои результаты очень похожи на результаты для FreeRTOS, найденные в интернете. И что интересует только бинарный семафор? Другие сервисы оси не интересуют? Например как быстро происходит вход в критическую секцию и какие способы предоставляются. Я бы на вашем месте заинтересовался именно этим, поскольку это чаще всего используемый сервис в том числе и самой осью. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ArtDenis 0 9 ноября, 2014 Опубликовано 9 ноября, 2014 · Жалоба Бинарный семафор вроде как самый быстрый. Другие объекты синхронизации должны работать либо также либо медленнее. Хотя согласен, что полезно оценивать не только по бинарному семафору. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Lagman 1 9 ноября, 2014 Опубликовано 9 ноября, 2014 · Жалоба Бинарный семафор вроде как самый быстрый. Другие объекты синхронизации должны работать либо также либо медленнее. Хотя согласен, что полезно оценивать не только по бинарному семафору. Не хочу расстраивать, но все semaphore во freertos основаны на queues, для этого достаточно посмотреть исходники. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ArtDenis 0 10 ноября, 2014 Опубликовано 10 ноября, 2014 · Жалоба С горем пополам запустил scmRTOS и померил время реакции на том же камне - 5.52 мкс Спасибо AHTOX-е за его консультации при запуске ) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Mahagam 0 12 ноября, 2014 Опубликовано 12 ноября, 2014 · Жалоба попробуйте ещё CTL запустить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 12 ноября, 2014 Опубликовано 12 ноября, 2014 · Жалоба С горем пополам запустил scmRTOS и померил время реакции на том же камне - 5.52 мкс Спасибо AHTOX-е за его консультации при запуске ) На Kinetis MK60 120 МГц RTOS MQX при переключении контекста через сервис флагов получается время 3 мкс (369 тактов) При этом: -флаги могут быть с автоматическим сбросом или без, -время не зависит от маски флагов, -не запрещаются прерывания ядра, -у задач разрешен планировщик time slice, -на ожидании флага может стоять очередь задач. Т.е. сервис остается еще довольно навороченным. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
LightElf 0 12 ноября, 2014 Опубликовано 12 ноября, 2014 · Жалоба К тому моменту, когда я написал свои результаты, я уже успел попробовать разные опции оптимизации (-O2, -O3, -Os), а также включал/отключал оптимизацию LTO. Самый быстрый результат был -O3 + LTO. Так что я сомневаюсь, что можно выжать больше. К тому-же мои результаты очень похожи на результаты для FreeRTOS, найденные в интернете. Еще хорошо бы померить время реакции для худшего случая, а не для сферического коня. Не удивлюсь, если FreeRTOS всех порвет на тряпки. Ну и там всякие мелочи, типа длительность входа в прерывание в худшем случае. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 12 ноября, 2014 Опубликовано 12 ноября, 2014 · Жалоба Еще хорошо бы померить время реакции для худшего случая, а не для сферического коня. Не удивлюсь, если FreeRTOS всех порвет на тряпки. Ну и там всякие мелочи, типа длительность входа в прерывание в худшем случае. Так худший случай можно затянуть до бесконечности, нет никаких проблем. Один только вклад прерываний ядра чего стоит. Чтобы результаты имели смысл надо четко специфицировать условия. Да и то мало смысла сравнивать оси с разной функциональностью. Скажем смешно сравнивать scmRTOS с MQX. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
LightElf 0 13 ноября, 2014 Опубликовано 13 ноября, 2014 · Жалоба Так худший случай можно затянуть до бесконечности, нет никаких проблем. Один только вклад прерываний ядра чего стоит. Чтобы результаты имели смысл надо четко специфицировать условия. Ну взять такой пример: 1) высокоприоритетная задача помещена в состояние спячки 2) две задачи с одинаковым приоритетом непрерывно шлют друг другу сообщения размером 8 байт через очередь длиной 16 сообщений (одна задача шлет, другая принимает) 3) на вход внешнего высокоприоритетного прерывания подается импульс 3) обработчик прерывания пробуждает задачу из пункта 1) 4) проснувшаяся задача изменяет состояние ножки Измеряем время от импульса прерывания до изменения состояния на ноге Да и то мало смысла сравнивать оси с разной функциональностью. Скажем смешно сравнивать scmRTOS с MQX. Ходить - так по большому! :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 13 ноября, 2014 Опубликовано 13 ноября, 2014 · Жалоба Ну взять такой пример: 1) высокоприоритетная задача помещена в состояние спячки 2) две задачи с одинаковым приоритетом непрерывно шлют друг другу сообщения размером 8 байт через очередь длиной 16 сообщений (одна задача шлет, другая принимает) 3) на вход внешнего высокоприоритетного прерывания подается импульс 3) обработчик прерывания пробуждает задачу из пункта 1) 4) проснувшаяся задача изменяет состояние ножки Измеряем время от импульса прерывания до изменения состояния на ноге В MQX такой сценарий для лучшего случая дает 1 мкс (без оптимизации кода, со всеми проверками стека и проч.) А худший случай по осциллографу увы не смотрят. Нужно делать нормальный лог статистики. И ради чего? Для realtime задач такие исследования делаются индивидуально. Никакая заявленная скорость RTOS здесь в учет не принимается. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 13 ноября, 2014 Опубликовано 13 ноября, 2014 · Жалоба На 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 давно умеют. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться