Средства и методы разработки

Про бытовой асинхронизм, Пентковского и Сафонова ничего не понял. Про итерации тоже. По-сути претензии к имеющимся RTOS: 1) вытесняющие требует много ОЗУ на стеки, 2) вытесняющие вызывают проблемы реентрабельности, 3) кооперативные с раздельными стеками то же самое, что п.1, но нет проблем с реентрабельностью, 4) кооперативные с одним стеком (трюк с return, switch-case или goto в gcc) подходят для малых МК хорошо, но... алгоритмы заданные изначально в терминах конечных автоматов, где в каждом состоянии автомат реагирует более чем на одно событие, напираются на ограничение в виде невозможности ожидания более чем одного события в простых OС (что возвращает к тому же "поллингу", неэффективному при необходимости экономии энергии). В полноценных ОС последнее ограничение всё же обходится. В более простых основанных на uTRON, например, для этого флаги есть. В совсем простых -- таймауты. Либо можно в каждом состоянии автомата, на каждое ожидаемое событие порождать отдельную задачу (благо они весьма легковесные)... что как-то не очень способствует созданию надёжного ПО. Собственно по поводу автоматов и последнего в голове начинает формироваться понимание того, что необходимо отделить собственно автоматы от многозадачности. Для исполнения небольшого количества задач (для большого не хватит ОЗУ) существующие вытесняющие (или кооперативные, с раздельным стеком, если библиотека C не реентабельна) ОС подходят хорошо. Но если архитектура ПО подразумеваете одновременное исполнение ~сотни параллельных конечных автоматов -- попросту нужен механизм их (псевдо)параллельного исполнения в одной-двух-трёх задачах ОС и не нужно пытаться всё переложить на саму ОС. Наверное я нахожусь в поиске этого механизма. Широко известная технология автоматного программирования Шалыто, например, подразумевает по-сути тот же big loop, с проверкой переменных состояния (можно считать, "флагов") в цикле. Это хорошая технология вне рамок многозадачной ОС, где процессорное время нежелательно тратить впустую, и вне рамок приборов где потребление энергии на бесполезные проверки переменных состояния (флагов в big loop) исключительно расточительно. Коммуникацию через переменные необходимо заменять на каки-либо механизмы синхронизации ОС, что угодно, что будет связано с планировщиком. Я не знаю ни готовых библиотек, ни ОС, которые бы дали описываемое.