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

Подумай вначале о том, как ты бы сделал на PC. И после недолгих размышлений придёшь к выводу, что: задачи и многозадачность вообще практически не нужны. Скорей нужен механизм событий наподобии очереди событий в GUI Windows. Не обязательно очередь, но ключевое слово event driven programming. Если ты думаешь, мол по процессу (ОС) на задачу -- надо понимать, что число процессов (или потоков, а вообще стеков) всегда будет ограниченное. И разделение на задачи должно вестись скорей по функциональному признаку (например, работа с модемом -- одна задача, а не по 2 шт. на каждый буфер UART), и число задач должно быть весьма ограниченным (аналог -- отдельные процессы на PC). Средства коммуникации -- файлы и средства IPC (pipe, семафоры, сообщения, сигналы, общая память...) Ниже пишут про автоматы. Да, автоматы это здорово, на автоматах можно сделать что угодно, но... это крайне утомительно и трудно потом поддерживать, всё само сведётся к event driven programming в итоге (да, внутри могут быть автоматы, для частных функций, но не как основная парадигма для всего проекта в целом). Что касается конкретных RTOS, то я бы обратил внимание на поддержку библиотеки C в контексте вытестнения и на возможность ожидания более чем одного события (отсутствие такой возможности автоматически порождает ещё одну задачу и в итоге годится только для мелких проектов...) См. тут: http://caxapa.ru/266984.html Касательно описываемой задачи работы с модемом: сильная параллельность -- зло. Увы, но придётся смириться, что большая часть кода будет автоматы или "event driven", т.е. без собственного стека. Причём если так подумать, то вообще задач П обычно много, задачу М нет смысла выделять в отдельную (может исполняться на уровне П, но нужно разделение доступа), UART реализуется, с буфером, на уровне прерываний (драйвер ОС) и нужен ещё один буфер для разбора ответов модема... И вообще всё это делается в big loop без всякой многозадачности.