Может хватит со своими очевидно? Были тут такие уже...

Представьте, что с суперциклом ничего представлять не надо. Все процедуры в цикле четко заданы и время исполнения в худшем случае представит собой простую сумму времен исполнения всех функций, входящих в суперцикл, которую легко просчитать и протестировать и в итоге гарантировать определенное время реакции при любых вариантах событий. А с вашими неопределенно когда возникающими прерываниями как считать? Сколько их будет за конкретное время? Как вы будете это тестировать и гарантировать?

Я конечно извиняюсь, что влез, но действительно не все очевидно.
То, с чем долбусь я. Есть 2 реализации проекта - на цикле на на RTOS (scmRTOS, freeRTOS)
Блок работы с внешней флеш-памятью. После подачи команды на флеш (запись, стирание) флеш работает асинхронно.
И таймауты на эту работу не детерменированы. При реализации на ОС код намного читабельнее и логичнее чем на цикле
(в цикле приходится работать с флагами и прокручивать основной цикла на время ожидания )

В ОС
. . . .
while( !CompleteFlash() ) Sleep(100);
. . . .

Как альтернатива - использовать ОС в кооперативном режиме (в freeRTOS - coroutine)

Посчитали и оказалось, что в одной из веток алгоритма иногда надо выполнить тяжёлый фильтр (когда накопится достаточное кол-во сэмплов), а в другой - БПФ, тоже иногда. При этом в другой функции надо быстро реагировать на какие-то события, время этой реакции - должно быть много меньше времени выполнения фильтра или БПФ.
Ваши действия? Что будете делать с вашим "легко просчитанным временем"??
С РТОС я БПФ и фильтр легко вынесу в низкоприоритетную задачу и решу проблему. А что делать с суперциклом?


Это понятно. Вот для таких случаев как раз удобно использовать ОС.
Просто некоторые люди не имеют дела с задачами сложнее "подрыгать парой ног и передать пару байт в UART" им сложно представить, что в системах реального времени приходится одновременно обслуживать сразу множество устройств с кучей разных состояний и событий. Просчитать все возможные времена просто нереально (да и бессмысленно).
Зато можно разбить процессы по приоритетам на более и менее важные.


Это усложнит код программы. Вам придётся каждую функцию приспосабливать под вашу ОС, просчитывать время её выполнения и пр. Но зачем? Мартышкин труд. Если можно использовать вытесняющую ОС. Другое дело - когда не хаватает ресурсов (памяти например для стеков задач), тогда можно объединить некоторые операции в пределах одной задачи вытесняющей ОС.
Я нередко делаю так (чтобы сократить объём необходимой памяти под стеки задач): объединяю несколько (2-3) процессов с примерно одним временем реакции и временем выполнения в один суперцикл и помещаю его внутрь одной задачи вытесняющей ОС. Процессы с другим временем выполнения (и с другой требуемой скоростью реакции на события) - в другую задачу, с другим приоритетом.

В моем случае приходится извращаться, так как в максимальном приоритете - экономичность (батарейное питание).
А вытесняющая OC подразумевает тики для планировщика. В нашей реализации тикало с периодом 16 мс - очень
не экономично. Можно конечно переключать этот период (на 250мс) для неактивно-рабочего режима (без оператора).
В общем, эта тема у меня недостаточно раскурена.

В какой статье какого кодекса значится описанное в статье требование?
На ту статью был дан адекватный ответ другой статьей. (Альтернативный подход к проектированию ПО для Embedded)

Не обязательно.
В момент времени когда нет полезной нагрузки (управление передаётся в фоновую IDLE-задачу) можно просмотреть список задач и объектов синхронизации (майлбоксы, мьютексы и т.п.), найти из всех них ближайшее время пробуждения и уснуть до этого времени. А ещё лучше - сделать группировку времён сна разных задач ОС в более крупные интервалы, в которые можно уйти в более глубокий сон.
Я так делал в одном батарейном проекте с uCOS. Делал надстройку над функциями ОС - каждая задача вызывающая объект с синхронизации с таймаутом или просто уходящая в IDLE на N тиков, сообщала при этом вызове минимально- и максимально-возможное время этого IDLE-состояния которое ей требуется. Это всё запоминалось и когда шедулер обнаруживал момент простоя всей системы, он анализировал эти времена и выбирал оптимальное время сна, так чтобы максимально оптимально уложиться в интервалы требований для разных задач (не превышая максимально-допустимый сон для каждой задачи и стараясь максимально увеличить время сна).
Если полученное значение интервала сна получалось менее какого-то порога, то просто выполнялась WFE, если более - выполнялся вход в глубокий сон (вход и выход в который естественно дольше).

Спасибо за инф. по варианту решения.

Добрый день, для своих программ использовал Switch подход, но до пары до времени...
Понадобилась спортировать свою программу на другую плату, а там почти вся периферия сидит на I2C
а это 2 термодатчика, календарь, расширитель порта->(Светодиоды,Кнопки и LCD). И все это должно работать
и отрабатывать замыкания линий и тд, и в случае если отвалится термодатчик то LСD Должен работать.
Сначала пошёл городить Switch на это все, но получилось как-то запутано, и ешё не нравилось, что
есть куча проходов функций, пока там до LCD дойдет. Ну и соответственно с обработкой аварии были проблемы.
Так что сейчас решил написать свою ОС, с минимальными возможностями сохранения и переключения контента,
и во всех задержках(ожидания флага или времени LCD) поставить переключение на другие задачи.
Сделал пару процессов, и теперь думаю над тем как разделить опрос медленных процессов(Термодатчика) от быстрых(опрос клавиатуры(матричной)).

Но все же интересно, если другие способы это все организовать?

А и еше как можно ОС протестировать и погонять, что она не разваливается?

Если все ф-ии системы ограничены тем, что Вы указали, то можно обойтись и главным циклом,
переключать контекст не надо. "Планировщик" делаете на таймере и CCR - разбиваю период главного цикла на нужное кол-во фаз
с детерминированным времением исполнения каждой. Ожидание и приоритеты реализуются "прокруткой" главного цикла, софт-таймерами и флагами.
Мне на форуме посоветовали protothreads - тотже "упакованный" while - switch-case.
Если нужно переключение контекста - попробуйте scmRTOS - вполне себе работала у меня и с прерываниями и с I2C,
и с SPI, и с USART.