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

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

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

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

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

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

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

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

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

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

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

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

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Добавлено after 1 minute 23 seconds:
а я кто по-вашему?

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

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

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