Комментарии 49
Интересно, обходил RTOS стороной, думая, что там все уж очень сложно.
FreeRTOS взлетит на STM32?
FreeRTOS взлетит на STM32?
По всей видимости, да: www.freertos.org/a00090.html#ST
сам её на stm32 использую, на avr кстати freertos работает очень плохо, хотя и есть порт
О, а можно подробнее про «на avr кстати freertos работает очень плохо». Я сам недавно на avr сильно ругался, но вот про freeRTOS на нем ничего плохого сказать не могу, работает без проблем.
freeRTOS отличная операционка, простая, легкая и стабильно развивается в правильном направлении )
Совсем не согласен с фразой:
она не для поиграться, она для настоящих серьезных проектов. В театре Современник она отлично уже не один год управляем некоторыми приводами сценической миханики. Привода в IP-сети, стек lwIP, работает как часы )
Совсем не согласен с фразой:
Для «поиграться» можно взять FreeRTOS
она не для поиграться, она для настоящих серьезных проектов. В театре Современник она отлично уже не один год управляем некоторыми приводами сценической миханики. Привода в IP-сети, стек lwIP, работает как часы )
Хорошая и очень наглядная статья.
Где-то RTOS на практике применяли? Если не секрет, где?
При желании планировщик можно реализовать и без RTOS, только хорошо железки надо знать и правильно всё инициализировать\мониторить. Как вариант делать минимальный SWPulse, перещёлкивать его, и смотреть приоритеты задач, активируя или выбрасывая Interrupt Handler'ов в планируемый фрейм.
Где-то RTOS на практике применяли? Если не секрет, где?
При желании планировщик можно реализовать и без RTOS, только хорошо железки надо знать и правильно всё инициализировать\мониторить. Как вариант делать минимальный SWPulse, перещёлкивать его, и смотреть приоритеты задач, активируя или выбрасывая Interrupt Handler'ов в планируемый фрейм.
FreeRTOS — на текущем проекте, многоканальное измерительное устройство, большего увы рассказать не могу. Ранее работал с uCOS-II и vxWorks — FreeRTOS практически ничем не хуже аналогов.
Планировщик самому реализовать-то можно, но зачем, если это уже многократно сделано (и оттестировано!) в RTOS?
Планировщик самому реализовать-то можно, но зачем, если это уже многократно сделано (и оттестировано!) в RTOS?
Спасибо, интересно.
По поводу написания планировщиков. Иногда есть особые требования, чтобы был для работающей системы исходный код, и в особых случаях, написанный по определённым правилам. Тогда бывает проще переписать свой планировщик, чем отбрасывать ненужное из кода ос (если он вообще доступен).
По поводу написания планировщиков. Иногда есть особые требования, чтобы был для работающей системы исходный код, и в особых случаях, написанный по определённым правилам. Тогда бывает проще переписать свой планировщик, чем отбрасывать ненужное из кода ос (если он вообще доступен).
Работаю с STM32F2 и FreeRTOS. Вопрос к автору: вы использовали какие-нибудь реализации IP стека?
На FreeRTOS — нет, на uCOS-II использовал стек от авторов операционки. Работал без проблем — но очень медленно. На vxWorks стек встроенный, тоже пользовались, была пара подводных камней — но в целом все работало.
На FreeRTOS успешно использовал uIP стек, со старой железкой CS8900A. Хотя если интересуют именно сетевые решения советовал бы посмотреть на Contiki OS. Один из разработчиков — главный разработчик uIP, да и в целом всю систему они позиционируют, как готовый стек для разработки связанных с сетью железок.
Плотно работаю сейчас по этой проблеме.
Есть несколько бордов на контроллере STM32F217, выбрал пока что LwIP (последний) который пропатчил немного — там чуть попроще сдалал с семафорами обвязку.
Довольно серьёзная штука крутится в FreeRTOS, проблем пока не замечено, но и доделать ещё кое-что нужно. Смотрел другие реализации сетевого стека, но увы, если нужен SSL, то на мой взгляд лучшая стартовая площадка — это LwIP. Есть хардкорщики которые свой стек пишут полностью, но это совсем другая задача.
Должен заметить что к сожалению качество исходников в демонстрационных примерах просто отвратительное. Во многих местах не проверяются коды возврата, неправильные комментарии (copy-paste), некоторые вещи просто не проверяются и вообще, такое ощущение что писалось это только для того частного случая что в демке показывают. Когда перешёл на этот чип, то я был очень наивен. Практически всю Board-Specific Package обвязку пришлось переписать, без этого запарился баги ловить. Скоро выложу на гитхабе, может кому пригодится.
Есть несколько бордов на контроллере STM32F217, выбрал пока что LwIP (последний) который пропатчил немного — там чуть попроще сдалал с семафорами обвязку.
Довольно серьёзная штука крутится в FreeRTOS, проблем пока не замечено, но и доделать ещё кое-что нужно. Смотрел другие реализации сетевого стека, но увы, если нужен SSL, то на мой взгляд лучшая стартовая площадка — это LwIP. Есть хардкорщики которые свой стек пишут полностью, но это совсем другая задача.
Должен заметить что к сожалению качество исходников в демонстрационных примерах просто отвратительное. Во многих местах не проверяются коды возврата, неправильные комментарии (copy-paste), некоторые вещи просто не проверяются и вообще, такое ощущение что писалось это только для того частного случая что в демке показывают. Когда перешёл на этот чип, то я был очень наивен. Практически всю Board-Specific Package обвязку пришлось переписать, без этого запарился баги ловить. Скоро выложу на гитхабе, может кому пригодится.
Хотя бы использовали (ассемблерную) команду halt, она есть в разных вариациях на всех ЦП с прерываниями. Обычно она останавливает выполнение программы (и выключает ЦП) до прихода любого прерывания, т.о. процессор не греется.
Конечные автоматы + программный таймер и в 90% случаев все будет решено им. С той же легкостью.
Либо простейший диспетчер + программный таймер.
Либо просто тупой большой case и программный таймер. В общем, программный таймер наше все :)
А загрузку контроллера можно очень легко определять осциллографом или стрелочным вольтметром, вот так:
easyelectronics.ru/avr-uchebnyj-kurs-ocenka-zagruzki-kontrollera.html
Либо простейший диспетчер + программный таймер.
Либо просто тупой большой case и программный таймер. В общем, программный таймер наше все :)
А загрузку контроллера можно очень легко определять осциллографом или стрелочным вольтметром, вот так:
easyelectronics.ru/avr-uchebnyj-kurs-ocenka-zagruzki-kontrollera.html
Собственно это и пытался показать на примитивном примере. Вот только сопровождать конечные автоматы — не самая простая задача, нет? Код над RTOS будет сильно проще в большинстве случаев.
это всё для простых проектов, если есть куча задач, которые нужно выполнять параллельно, то кооперативная rtos тут не справится, нужна вытесняющая. У freertos, тоже можно отлично узнать загрузку, там есть специальная задача IDLE простоя если нет задач, и там можно повесить что угодно, хоть таймер, хоть светодиод, она кстати очень помогает снизить потребление.
Я ж вроде именно это и хотел сказать — что при наличии ОС измерить загрузку ЦПУ весьма просто — будь то GPIO пин с осциллографом или printf в консоли. А суперцикл с многократными опросами эту задачу сильно усложняет.
Проблема суперцикла в том, что там нет idle задачи которая сжирала бы неиспользованное время, в результате оно все крутится быстрей чем это надо. Но что мешает перевести тот же суперцикл на событийную систему?
Проблема суперцикла в том, что неудобно реализовывать все, что связано с блокирующем чтением (IP, например), и с тем, что не возможности вытеснять долговременные задачи (вывод на экран).
А что, прерывания уже не в моде? Если есть столь критичные к выполнению задачи, то их можно и в прерывание сунуть.
Может быть и можно, но во-первых, не всегда, а во-вторых, зачем огород городить? Если FreeRTOS уже написана, отлажена и оттестирована, то есть смысл использовать ее для решения многих проблем. У меня тоже все программки — конечные автоматы в одном потоке, но есть и дополнительные потоки, выполняющие долгие или блокирующие операции (которые автомат может вытеснять). Получается, что если бы мне надо было использовать прерывания для критичных задач, пришлось бы сам конечный автомат в прерывание засовывать. А это сделать нельзя, потому что есть синхронизация с прерываниями, а nested interrupts на контроллере нет. Да и автомат тогда должен все делать очень быстро, чтобы не пропустить ничего (например, если во время обработки прерывания мы получим 2 символа по уарт, первый пропадет).
Медленней реакция, больше оверхед. Да и не везде rtos влезет.
В прерывании не надо ничего обрабатывать. В худшем случае нажрать буфер быстро тухнущих данных и поставить флажок, что их надо разгрести. Да хоть при следующем проходе автомата.
В прерывании не надо ничего обрабатывать. В худшем случае нажрать буфер быстро тухнущих данных и поставить флажок, что их надо разгрести. Да хоть при следующем проходе автомата.
Какой-то пустой спор, вы пытаетесь доказать, что РТОС — бесполезная штука?
Нет, не бесполезная. Сам юзаю с удовольствием. Но в большинстве случае можно обойтись без нее.
Так никто обратного не утверждал же :)
и всё же использование rtos даёт больше плюсов, например код читается проще, улучшается его структура и связность, в плане дебага гораздо проще, у IAR например вообще есть драйвер для FreeRTOS, классно работает, ну и куча других печенек
Если у тебя камень уровня stm32f1xx то конечно же, сложную аппликуху ты туда всё равно не зашьёшь. В таком случае конечно можно всё написать руками как ты говоришь.
Но когда люди выбирают камень уровня stm32f2xx у которого на борту 128К оперативки, то соответственно и задачи на нём крутятся посложнее.
В этом случае городить свой огород и косить на нём свои же баги будет только мазохист. Ты попробуй сначала сооруди что-нибудь посложнее, на сотню тыщ строк кода и порули потом этим делом с помощью этого таймера и цикла.
FreeRTOS даёт много удобных плюшек и легко настраивается в одном-единственном заголовочном файлике. Можно отключать ненужные вещи, код для них не будет генериться вообще.
RTOS реализаций много, представленная здесь FreeRTOS — одна из них, отлично сделана, код проверен многими людьми во многих проектах.
Но когда люди выбирают камень уровня stm32f2xx у которого на борту 128К оперативки, то соответственно и задачи на нём крутятся посложнее.
В этом случае городить свой огород и косить на нём свои же баги будет только мазохист. Ты попробуй сначала сооруди что-нибудь посложнее, на сотню тыщ строк кода и порули потом этим делом с помощью этого таймера и цикла.
FreeRTOS даёт много удобных плюшек и легко настраивается в одном-единственном заголовочном файлике. Можно отключать ненужные вещи, код для них не будет генериться вообще.
RTOS реализаций много, представленная здесь FreeRTOS — одна из них, отлично сделана, код проверен многими людьми во многих проектах.
Тоже использую FreeRTOS на STM32, удобно.
По поводу
>все же многозадачность априори сложнее и непредсказуемее, чем последовательно выполняющийся код. Обязательно хорошее понимание принципов работы в многозадачной среде, принципов потокобезопасного кода, синхронизации данных и многого другого.
Это, конечно, верно, вот только даже без фри-ртос код все равно становится многозадачным, как только начинают юзать интеррапты. И проблемы синхронизации встают, и потокобезопасности — только во ФриРТОС они… как бы сказать… более традиционно выглядят, типичный concurrency, а когда человек начинает работать с интерраптами и без ОС, еще не сразу может обратить внимание на необходимость учитывать то, что будет с кодом, когда придет этот самый интеррапт. Да еще и свои велосипеды для синхронизации придется клепать.
Так что это, имхо, неоднозначный вопрос — что проще — прочесть справочник по АПИ FreeRTOS и дальше пользоваться ее мультитаскингом, или самому городить.
Интеррапты, Интеррапты,
флаги прерыванья,
мультитаскинг расширяет
кодера сознанье!
По поводу
>все же многозадачность априори сложнее и непредсказуемее, чем последовательно выполняющийся код. Обязательно хорошее понимание принципов работы в многозадачной среде, принципов потокобезопасного кода, синхронизации данных и многого другого.
Это, конечно, верно, вот только даже без фри-ртос код все равно становится многозадачным, как только начинают юзать интеррапты. И проблемы синхронизации встают, и потокобезопасности — только во ФриРТОС они… как бы сказать… более традиционно выглядят, типичный concurrency, а когда человек начинает работать с интерраптами и без ОС, еще не сразу может обратить внимание на необходимость учитывать то, что будет с кодом, когда придет этот самый интеррапт. Да еще и свои велосипеды для синхронизации придется клепать.
Так что это, имхо, неоднозначный вопрос — что проще — прочесть справочник по АПИ FreeRTOS и дальше пользоваться ее мультитаскингом, или самому городить.
Интеррапты, Интеррапты,
флаги прерыванья,
мультитаскинг расширяет
кодера сознанье!
Хотел бы добавить пару слов от себя.
Для реализации поведения «interrupt_happened = 1;» нет необходимости писать обработчик прерывания — можно напрямую проверять флаг прерывания.
Ну и для того чтобы упростить работу с машинами состояний можно воспользоваться Protothreads.
Для реализации поведения «interrupt_happened = 1;» нет необходимости писать обработчик прерывания — можно напрямую проверять флаг прерывания.
Ну и для того чтобы упростить работу с машинами состояний можно воспользоваться Protothreads.
Из статьи не понятно откуда взялись функции os_start_sheduler/os_task_create.
В начале раздела «Применение операционной системы реального времени.»
Хорошо было бы указать, что сейчас мы будем использовать функции такой-то библиотеки.
В начале раздела «Применение операционной системы реального времени.»
Хорошо было бы указать, что сейчас мы будем использовать функции такой-то библиотеки.
Это функции некой абстрактной ОС. Они есть в любой ОС, делают одно и то же, только называются по-разному.
Это не библиотека, это собственно операционная система (на что, собственно, указывают префиксы os — про то, что примеры на псевдокоде, указал в самом начале).
Я это понял, но не сразу. Указать дополнительно или хотя бы в виде комментария не будет лишним.
Просто после столь детального и понятного описания подхода с «суперциклом»,
кусок кода, с непонятными вызовами, которые делают непонятно что, смотрится как-то не очень.
кусок кода, с непонятными вызовами, которые делают непонятно что, смотрится как-то не очень.
Статья и так немаленькая получилась, и добавить сюда еще и введение в RTOS — было бы перебором. Да и собственно написано уже все!
Всё верно в статье написано, начинающим самое оно.
Особенность работы с прерываниями такова, что обработчик прерывания (код, который будет вызван непосредственно в тот момент, когда прерывание произойдет) должен быть как можно более коротким.
— почему? В смысле я не спорю, а хочу узнать: почему обработчик прерывания должен быть коротким, если есть nested interrupts?
Вообще классно написано, просто и довольно точно.
А всякие комментарии типа «можно самому sheduller написать» — блин можно и РТОС самому написать :)
Лично для себя использую РТОС только для упрощения расширения проекта или лепки одного проекта из двух, добавления задач.
— почему? В смысле я не спорю, а хочу узнать: почему обработчик прерывания должен быть коротким, если есть nested interrupts?
Вообще классно написано, просто и довольно точно.
А всякие комментарии типа «можно самому sheduller написать» — блин можно и РТОС самому написать :)
Лично для себя использую РТОС только для упрощения расширения проекта или лепки одного проекта из двух, добавления задач.
почему обработчик прерывания должен быть коротким, если есть nested interrupts?
Ну как минимум чтобы не потерять следующее прерывание из того же источника. Плюс чтобы не нарушать работу остальной системы.
Вообще же абсолютного требования, чтобы прерывания были короткими, конечно же, нет — все очень сильно зависит от задачи и дизайна решения. Мы однажды реализовали систему так, что в прерывании проводилось 85% времени процессора при максимальной загрузке — и все стабильно работало.
Ну как минимум чтобы не потерять следующее прерывание из того же источника. Плюс чтобы не нарушать работу остальной системы.
Вообще же абсолютного требования, чтобы прерывания были короткими, конечно же, нет — все очень сильно зависит от задачи и дизайна решения. Мы однажды реализовали систему так, что в прерывании проводилось 85% времени процессора при максимальной загрузке — и все стабильно работало.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Два подхода к проектированию ПО для embedded