Вытесняющая многозадачная ОС. Практика AVR

[ARV]

я тут своих тараканов гоняю... и забожалось мне делать это при помощи многозадачки.
изначально смотрел в сторону OSA - подкупило большое количество русскоязычной документации. но потом понял, что с ней возни больше, чем удобства - кооперативность и отсутствие локальных auto-переменных сводят весь кайф от многозадачности к минимуму.
поиск дал большое количество вариантов именно вытесняющих ОС, много и таких, что пригодня для AVR. но половина из них не сопровождена документацией и толковыми примерами, а вторая половина настолько сложно документирована и запутанно оформлена, что плохо поддается пониманию.

может, у кого-либо есть практический опыт применения подобных ОС, чтобы посоветовать? теория мне ясна, но вот нюансы практики...

разумеется, для AVR главный критерий выбора - минимальные требования к ОЗУ. и пока что я остановился (собственно, как взял, так и не бросаю, остальное не пошло с первого тыка, больше не предпринимал попыток) на YAVRTOS - пока что устраивет все, кроме весьма загадочной для меня системы mailbox-ов - не могу понять, в чем фишка и как ею пользоваться. это не очередь сообщений, а что-то странное, на одно сообщение, но с какими-то версиями... мне бы как раз очередь... причем, чтобы была готовая, чтобы на собственные грабли не наступать.

freeRTOS мне представляется слегка избыточно навороченной, хотя почти готов и ею заняться.

но прежде хотел бы послушать умных советов от практиков. таковые найдутся?

[Demiurg]

RTOS, диспетчеры - выполняют одну единственную задачу - очередь. Это очередь процессов, но не алгоритм программы. Конечные автоматы вам в помощь.

[ARV]

Мне нужна помощь в выборе и освоении конкретной RTOS, с которой "советчик" имел дело. Чтобы я мог задать конкретный вопрос по конкретной функции RTOS и получить ответ.

RTOS для меня реализует независимость нескольких бесконечных циклов (т.е. задач) "естественным" способом. То есть я не хочу заниматься тем, чтобы "дробить" свои циклы на состояния и потом по кусочкам их вручную исполнять. Я хочу написать while(1) и в нем свою логику так, как если бы это была полностью самостостоятельная программа, а не вот это вот все - я этих автоматов накушался, хочу легкой жизни!
И я так понимаю, что в этом и есть основное назначение любой RTOS.

[Demiurg]

Но я надеюсь, вы понимаете, что RTOS не заменяет алгоритм.
Альтернативу автоматам я не нашёл. Близкое - прототреды. Но все таки не то. Те же облагороженные автоматы.
Вам никто не мешает использовать конечный автомат как самостоятельный процесс.

[ARV]

У вас есть опыт работы с RTOS?

[Мурик]

ARV берите FreeRTOS и МК как минимум с 20 КБ ОЗУ, которое нужно для задач.

[ARV]

Порт FreeRTOS под AVR существует, я в курсе.
Вы можете консультировать по этой ОС?

[Мурик]

На AVR ее не запускал. Для задач нужна память. У каждой свой стек и служебные переменные. С минимальными параметрами получается больше 500 байт на задачу.
Про ОС можете прочитать в этом цикле статей. http://microsin.net/programming/arm/freertos-part1.html

[ARV]

Для задач нужна память. У каждой свой стек и служебные переменные. С минимальными параметрами получается больше 500 байт на задачу.

многовато. поэтому я как-то про freeRTOS в последнюю очередь думаю. упомянутая мною YAVRTOS в минимуме обходится 64 байтами стека и десятком байт на задачу. но не во всем устраивает, в частности, нет нормальной очереди сообщений. ну или я не понимаю, как сообщениями обмениваться в ней...

[Аlex]

В freeRTOS размер стека для каждой задачи отводится пользователем.
А 500 байт - это для мощных МК с кучей служебных регистров, которые нужно сохранять при переключении задач.

По поводу доки. Очень понравилась вот эта статья :

FreeRTOS.pdf

(4.1 MiB) Скачиваний: 981

Очень хорошо всё разжёвывает автор....

[Demiurg]

ARV писал(а):

У вас есть опыт работы с RTOS?

У меня следующий опыт: кооперативные диспетчеры. Самописный вытесняющий. Позже сделал смешанный. Кооперативный и вытесняющий. Какую то RTOS-ку пробовал. Всё это было, когда я начинал. Потом мне указали на конечные автоматы. Более я даже не приближался ни к диспетчера, ни к RTOS. Попросту не было необходимости. А последние проекты были непростые.

[oleg110592]

Мурик писал(а):

На AVR ее не запускал

Запускал FreeRTOS на меге8 в протеусе, 2 блинк светодиода:

Код:

Device: atmega8
Program:    3874 bytes (47.3% Full)
(.text + .data + .bootloader)

Data:        621 bytes (60.6% Full)
(.data + .bss + .noinit)

тут это было:
https://radiokot.ru/forum/viewtopic.php ... 4#p3099914

[ARV]

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

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

аналогичные проблемы наверняка будут и с любой иной ОС. поскольку любое чтение документации требует последовательности, я могу погрязнуть в теории... поэтому и обратился с просьбой. литература, статьи - это все понятно. в каждой статье рассказывают о том, как два или три светодиода мигают параллельно - я это еще в институте изучал, и читать по 100 раз одно и то же (только названия функций разные) утомительно. 80% статей, которые я уже пытался изучать, дальше мигалки и не идут, дескать, после того, как помигал, очередь - это плевое дело и нехрен тут об этом писать... а мне надо именно обеспечить асинхронный обмен сообщениями между задачами, причем такой обмен, чтобы задача выбирала "задания" пока они есть, и исполняла их, а потом ждала, пока придут новые. классика - очередь сообщений. без ОС все простои понятно, в парадигме ОС должны быть системные штуки... при том, чтобы были простые и "маложрущие".

википедия дает примерно с 3 десятка ОС, пригодных для AVR - перепробовать все, чтобы найти подходящую, я не в состоянии. тем более, что кроме OSA и freeRTOS ни у одной нет нормального русскоязычного опсиания... кажется, еще scrmOS, что ли русская, но зато на C++ что тоже ме по мне.

[Demiurg]

Лично я считаю, что у вас в данный момент смутное понимание текущего проекта или общих хотелок. Мой вам совет. Сесть и хорошо продумать текущую проблему, задачу. Когда будет четкое ТЗ, будет четкое понимание, что вам в действительности нужно.

[ARV]

У меня следующий опыт: кооперативные диспетчеры

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

как я уже писал: есть задача, которая в бесконечном цикле ожидает команду от другой задачи, по команде посылает то или иное сообщение по USART, ждет ответа из него же и, при необходимости, посылает кому надо овет о выполнении. я бы хотел, чтобы все это выглядело как-то так:

Код:

while(1){
   switch(get_msg_from_queue()){
      case MSG1 : usart_send(STR1); break;
      case MSG2: usart_send(STR2); break;
      ...
   }
   while(!reseive_usart()) sleep(1);
   respond = usart_get();
   switch(respond){
   case RSP1 : // ну вы поняли...
   }
}

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

вероятно, вам мило, когда ничего понять нельзя... мне же мило, когда код читается, как простое словесное описание алгоритма, только на ограниченном словаре Эллочки-людоедки.

у вас в данный момент смутное понимание текущего проекта или общих хотелок. Мой вам совет. Сесть и хорошо продумать текущую проблему, задачу. Когда будет четкое ТЗ, будет четкое понимание, что вам в действительности нужно

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

[Demiurg]

Когда изобретете красивый способ замены конечных автоматов, дайте знать. В личку. Я не возвожу конечные автоматы в абсолют. Попросту не нашел альтернативы.

[oleg110592]

ARV писал(а):

"блинки" блимкали, но мне надо больше

форум же тут "радиолюбительский", возможно надо спрашивать, например, где разделы соответствующие есть:
https://electronix.ru/forum/index.php?a ... ums&id=189

[Мурик]

А 500 байт - это для мощных МК с кучей служебных регистров

14 регистров это много, согласен.

[ARV]

Когда изобретете красивый способ замены конечных автоматов, дайте знать. В личку. Я не возвожу конечные автоматы в абсолют. Попросту не нашел альтернативы.

конечные автоматы - это соль программирования, как я уже говорил. но время о времени надо пробовать и сахар.
сумеете так же понятно и просто описать вашим методом конечных автоматов вышеприведенный мной цикл? вряд ли. а простота кода лично для меня одно из основных критериев качества кода в принципе. меня нимало не беспокоит, что это внешняя красота, достигнутая чем-то невидимым и, возможно, уродливым (это я про ОС). но пользоваться этим кодом приятно и легко.

Добавлено after 1 minute 23 seconds:

форум же тут "радиолюбительский"

а я кто по-вашему?

[Reflector]

ARV писал(а):

сумеете так же понятно и просто описать вашим методом конечных автоматов вышеприведенный мной цикл? вряд ли. а простота кода лично для меня одно из основных критериев качества кода в принципе.

Там вроде простой пример, всего 2 состояния, главное чтобы USART был буферизированный. Проверили очередь сообщений, если что-то есть, добавляем строку в очередь USARTa, переключаем состояние и выходим, в следующий раз проверяем входящую очередь USARTa, если ответ пришел, посылаем команду о выполнении и возвращаемся в первоначальное состояние ожидания сообщений.

Добавлено after 1 minute 8 seconds:

Мурик писал(а):

14 регистров это много, согласен.

Если есть FPU, а речь шла о мощных мк, то 128 байт уйдет только на 32 дополнительных регистра.