Есть несколько задач (программ) которые должны выполнятся с минимальным временем, можно организовать как линейный список функций, которые последовательно вызываются из главной функции main() при условии что время выполнения каждой функции ограничено т.е. внутри функции нет кода который задерживает выполнения (ожидает чего либо).
Например одна функция обрабатывает принятый массив с USARTа. другая расшифровывает принятую команду и выполняет ее, подготавливает ответ к отправке (квитирование).
Еще пару функций, которые что-то делают (обслуживают клавиатуру, исполнительные устройства). Получается все запутанно, если делать все функции в виде конечных автоматов с минимальным временем работы каждой. Хорошо было бы, если каждая функция выполнялась в виде задачи, ожидает, данные с параллельного потока пускай ждет, получила что хотела, выполняет. Есть задержка в функции скажем, на 20 секунд, пускай ждет, в это время выполняются другие функции. С операционными системами как-то все сложно, может планировщик задач да и все. Какие есть решение не сложные? Механизм взаимодействия функций друг с другом.

Ну для этого и придуманы прерывания, например для UARTа.

-->Получается все запутанно, если делать все функции в виде конечных автоматов с минимальным временем работы каждой. Хорошо было бы, если каждая функция выполнялась в виде задачи, ожидает, данные с параллельного потока пускай ждет, получила что хотела, выполняет. Есть задержка в функции скажем, на 20 секунд, пускай ждет, в это время выполняются другие функции.

Сильно смахивает на параллельность операций. В контроллере врятли получиться.

В прерываниях долго сидеть нельзя, там можно формировать массив из принятых данных и отслеживать конец посылки. А внешне проверять адрес контрольную сумму.

Ну так ясное дело в прерывании, например для юарта забираете посылку, а в функции уже разбираете ее.

А других вариантов-то и нет. Единственное, если есть функции с наивысшим приоритетом (например, приём/передача данных по интерфейсу на максимальной скорости в большом объёме), их придётся целиком запихивать в прерывания. Можно ещё в некоторых режимах блокировать ненужные функции. Главное - не запутаться в системе флагов.

Да флагов рожлается огромное количество на сыром коде, но после оптимизации половина выкидывается. Главное, при расположении большого кода в прерывании не забывать об их приоритетах.

Можно и без вложенных прерываний в одном прерывании все обслуживать, если наименьший период вызова других прерываний не превышает времени работы в данном прерывании. Например, на скорости 9600 прерывания от UART будут не чаще чем через 1 мс. Дребезг клавиатуры за это время конечно не устранишь, а вот разобрать пакет и подготовить ответ вполне можно при достаточной производительности МК. Да и клаву тоже можно обслужить, если вызывать процедуру один раз через 9 (при дребезге клавиш не более 10мс). По крайней мере у меня на MSP430 при работе UARTа на 115200 в 10мс прерывании и клавиатура обслуживается и транспортная процедура (прием/передача/подсчет CRC/выдача ответа "занят", без разбора самого пакета) RTU-ного протокола крутится.

В винде вот красиво сделано. Там есть обработчики событий. Вся прога при этом пишется из обработчиков, которые сами себя вызывают друг за другом. Конечно, там ещё и разделение во времени чтобы тупые обработчики не завешивали систему. Вобщем есть три механизма:
1. Прерывания
2. Обработчики событий
3. Разделение во времени
Хотя может чего ещё и забыл.

Наклёвывается необходимость применения RTOS.
По крайней мере никакой мороки с машинами состояний, флагами, и прочим геморроем, не относящимся напрямую к постановке задачи.
Ссылок на популярные RTOS, применительно к микроконтроллерам, даже на этом форуме - море.

Если используется какой-нибудь высокоуровневый протокол, то да. А если там требуется прочитать клавиатуру да выкинуть что-либо на LCD-дисплей, то получится только напрасная трата ресурсов.

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

Насколько я понимаю это в любом случае RTOS. Просто в одном случае реализованная своими силами и сильно упрощённая, ну а в другом написанная сторонними производителями, и, возможно сильно усложнённая.

Если свой упрощённый вариант, то я пишу так как не рекомендует писать уважаемый 'IgorKossak'.
То есть ввожу флаги состояний, задачи замыкаю на себя, данные напрямую не передаю, общаюсь только ч/з флаги и ОЗУ. (то есть вых. данные одной проги - входные другой). Блоки пишу таким образом, что их перестановка местами м/у собой не влияет на работоспособность программы.

Есть функции, есть планировщик задач. Функции зациклены. Выход из функции невозможен. Функция сама передает процессорное время по команде планировщику, планировщик отдает процессорное время другой функции по приоритету. Возникает вопрос как (для AVR IAR) вернутся в прерванную функцию по адресу где функция отдала управление и как в IAR сохранить рабочие регистры и какие нужно сохранять.

Программа должна выглядеть так:

do{
ReadKeys();
UpdateDisplay();
}while(true);

Всё остальное - дело флагов, указателей и счётчиков.
Главное - в ассемблерном листинге это выглядит точно так же.

В одном из своих проектов я решил подобный вопрос с помощью нехитрого планировщика , который занимался тем, что запускал функции "задачи" по расписанию.
Ввел три типа задач:
TASK_PERIODIC - запускать постоянно через определенный интервал
TASK_SINGLECALL - запустить однократно через определенный интервал
TASK_KERNEL - запускать в отдельном _idle_ цикле постоянно (к этому типу относятся всевозможные Dispatcher'ы)

Задачи помещаются в отдельные очереди и при вызове могут добавлять/удалять в/из очереди любые другие задачи. Если потребуется выполнение довольно длительной задержки (у меня таки потребовалось) внутри "задачи", то задача обязана вызывать _idle_ цикл, чтобы отрабатывали все "системные" задачи типа TASK_KERNEL (обслуживание времени, I/O и т.п.).

От флагов такой подход полностью не избавляет, но все-таки минимизирует чуть-чуть, и экономит ПП. Для сравнения этот планировщик отнимает всего ~500 байт ПП и может занимать меньше, ну а кол-во занимаемого RAM'а регулируется взависимости от потребностей проекта. (по 16 задач каждого типа займет 10*16*3 байт ОЗУ).