AlexandrY 2 13 ноября, 2014 Опубликовано 13 ноября, 2014 · Жалоба А что такое прерывания ядра? Сейчас специально скачал свежую версию 4.1.0 для K60. Посмотрел функцию sem_post(), там все те же макросы _INT_ENABLE, _INT_DISABLE которые выливаются для CortexM3 в инструкции cpsie и cpsid. Да еще оно считает уровень вложенности запрета прерываний, что тоже скорости не добавляет. Так что все там банально в MQX, запрещает она прерывания как миленькая. Или я куда-то не туда посмотрел? Сильны же вы макросы смотреть. Там без поллитра ничего не высмотришь. Только пошаговая отладка позволяет понять какой там из кучи вариантов макросов реально выполняется. В моей тестовой конфигурации просто повышался приоритет разрешенных прерываний. На прерывания ядра (т.е. не проходящие через планировщик RTOS) у MQX выделено 4-е верхних уровня. Полное запрещение прерываний не производится. На STM32 порта MQX вообще-то нет. Забавно будет если кто-то его сделает. Ну этим уже тыщу лет никого не удивишь, это многие старенькие RTOS типа TNKernel/FreeRTOS давно умеют. Умеют они там или не умеют не так важно. Важно в честном сравнении это упоминать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 13 ноября, 2014 Опубликовано 13 ноября, 2014 · Жалоба Сильны же вы макросы смотреть. Там без поллитра ничего не высмотришь. Да ладно, все просто. В моей сегодня-скачанной версии 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 0 17 ноября, 2014 Опубликовано 17 ноября, 2014 (изменено) · Жалоба Эх, в итоге я так и не осилил scmRTOS и ChibiOS, которые хотел попробовать. scmRTOS у меня так и не завёлся с моим ассемблерным стартапом и скриптом линкера, а ChibiOS не завёлся без его HAL, который мне вообще не сдался. А на эти две ОС как раз была надежда именно в малом времени реакции... :( Придётся использовать FreeRTOS (который завёлся сразу и не навязывал свои стартапы, скрипты линкера или HAL), несмотря на его большое время реакции. Изменено 17 ноября, 2014 пользователем ArtDenis Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Mahagam 0 17 ноября, 2014 Опубликовано 17 ноября, 2014 · Жалоба ещё раз. смотрите в сторону кроссворка. стиль кода куда читаемее чем у фриртоса. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
den_po 0 18 ноября, 2014 Опубликовано 18 ноября, 2014 · Жалоба ещё раз. смотрите в сторону кроссворка. стиль кода куда читаемее чем у фриртоса. Чей стиль кода? Операционки? У рядового разработчика необходимости заглядывать в её исходники вообще не должно быть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Mahagam 0 18 ноября, 2014 Опубликовано 18 ноября, 2014 · Жалоба Чей стиль кода? Операционки? У рядового разработчика необходимости заглядывать в её исходники вообще не должно быть. на этапе выбора этой самой операционки - ещё какая! а если разработчик нерядовой? то что делать? )) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mbr 0 1 июля, 2015 Опубликовано 1 июля, 2015 · Жалоба Выбирать RTOS из-за очень синтетического параметра как время переключения контекста это очень странно - с таким подходом первое не во время прилетевшее прерывание разрушит всю систему. У меня в REx получается около 6us при 72MHz. При этом простой вызов ядра - 1.9us. Я считаю время более чем приемлимым. Мало того, если включить профилирование (время работы процесса, размер использованной кучи и стека и т.д.), время увеличивается до целых 11us, но какой-либо потери производительности от этого я не заметил. Код теста есть в примерах. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
seec 0 14 ноября, 2015 Опубликовано 14 ноября, 2015 · Жалоба Эх, в итоге я так и не осилил scmRTOS и ChibiOS, которые хотел попробовать. scmRTOS у меня так и не завёлся с моим ассемблерным стартапом и скриптом линкера, а ChibiOS не завёлся без его HAL, который мне вообще не сдался. А на эти две ОС как раз была надежда именно в малом времени реакции... :( Придётся использовать FreeRTOS (который завёлся сразу и не навязывал свои стартапы, скрипты линкера или HAL), несмотря на его большое время реакции. Остановились на чём нибудь окончательно? топчусь перед выбором ОС РВ не знаю куда податься... (STM32F7) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aner 3 14 ноября, 2015 Опубликовано 14 ноября, 2015 · Жалоба Остановились на чём нибудь окончательно? топчусь перед выбором ОС РВ не знаю куда податься... (STM32F7) ... а что за реалтайм задачи перед вами перед ... податься? И чем RTOS не устроил? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
seec 0 15 ноября, 2015 Опубликовано 15 ноября, 2015 · Жалоба ... а что за реалтайм задачи перед вами перед ... податься? И чем RTOS не устроил? подозреваю что совсем не эксклюзивные-обычное управление железкой (ну взрывоопасной малость) сейчас всё крутится на AVR, вообще без ОС - ручками память, ручками семафоры, ручками прерывания... но нельзя же вечно жить на 128кБ (тем более что их уже стало не хватать), да и хочется всяких готовых GUIёв, сетевых библиотек... на красивости потянуло, сечас код практически нечитаем людьми со стороны, если есть возможность привести базу к общему с другими людьми виду и заниматься только функциональной частью, то почему этого не сделать... (для меня увеличивается шанс успешно спихнуть проект в другие руки) +АТМЕЛ малость достала со своими маркетинговыми закидонами, но это к вопросу отношения не имеет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 15 ноября, 2015 Опубликовано 15 ноября, 2015 · Жалоба Остановились на чём нибудь окончательно? топчусь перед выбором ОС РВ не знаю куда податься... (STM32F7) Если пользуетесь Кейлом, посмотрите RTX. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Lagman 1 29 мая, 2017 Опубликовано 29 мая, 2017 · Жалоба Понимаю что тема старая и тут уже сам автор (MBR) написал , но случайно наткнулся в ЖЖ на "рекламу", исходники в открытом доступе (про лицензию еще не читал), документация присутствует на русском, OS в свободном доступе для STM32, присутствует ядро, свой std, куча драйверов, библиотек и стеков. Автор пишет про По эффективности целый раздел во введении. В частности это event-based HPET таймер с тайм-аутом до 1us и принцип построения безмьютексных систем. Здесь огромный выигрыш как в производительности, так и в энергопотреблении. Касательно целевой задачи - механизм построения системы будет, в целом, такой же - в этом и есть вся суть ОСРВ. Чтение данных с сенсора выносится в драйверы, обсчет в более высокоуровневый приоритет, управление - в менее. Преимуществами я бы здесь увидел энергопотребление, механизм аппаратной абстракции и масштабируемость решения. Т.е. замена всей целевой платформы (скажем, STM32 на NXP) заключается просто в правке конфигов. Я рекомендую по аппаратной абстракции посмотреть соответствующий раздел - там очень детально все описано. Особенно концепция файлов. Все рассчитано на межпроцессное использование с помощью DMA и для высокой нагрузки без излишнего копирования данных. В частности, для STM32F1 при частоте 72mhz, время вызова ядра: 1.3us, время переключения контекста (включая непосредственно работу ядра и само вытеснение): 6us. А кто нибудь уже пробовал эту ОСРВ (кроме автора MBR)? Как впечатление? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
