Ага. А с чего будет снижение затрат-то? На борьбу с ОСью не будет
не потрачено ничего, особенно на синхронизацию? В одном большом
проекте половина багов -- синхронизация (дедлоки, data race и т.п.)
А у тебя Valgrind (DRD, Hellgrind) не будет. Ты ж про
"синтетический порт" на ПК и слышать небось не хочешь. Мол одной
левой и так отладим. Основной функцией ОС является распрделение
ресурсов вычислительной системы. И она нужна, если ты это руками
сделать не можешь. И в частности, распределение памяти, и распределение процессорного времении. Вытесняющая ОС -- преимущественно способ запустить параллельно независимые задачи и повысить время реакции системы (потому, что можно быстренько вытеснить и переключиться на поток способный быстро обслужить данный конкретный сигнал). Способ распределить процессорное время для организации длительных вычислений, например, которые самостоятельно прерываться не умеют. В задачах логического управления, когда их много, они параллельны и все взаимосвязаны RTOS поможет мало. Т.к. синхронизация между задачами станет исключительно сложной. Пример: практически все GUI системы можно сказать являются задачей логического управления. И практически все -- однопоточные, работают в какой-либо событийно-ориентированной системе. Многопоточных нет, потому, что задача синхронизации станет практически не разрешимой. Все события обрабатываются строго синхронно.
И наконец зачем тебе чей-то чужой опыт. Я офигеваю от вопрос "а кто-нибудь так делал?" А если тебе ответят, мол, мы так не делаем и не будем -- и ты не будешь?
Практически в рамках любой RTOS у тебя в отдельные задачи ты сможешь выделить относительно независимые процессы. Основная часть у тебя будет исполняться в некотором главном потоке, скорей в котором будет очередь событий, события из которой, предназначенные совершенно разным подсистемам, ты будешь обрабатывать в цикле. По сути основной цикл управления останется однопоточным. И скорей у тебя появится такая сущность как "планировщик" (не путать с планировщиком уровня ОС), который позволит отправлять события в очередь в наперёд заданное время, или вызывать обработчики в заданное время, между циклами чтения очереди событий, это не важно. Сам факт, что появится некоторая однопоточная система обработки событий предназначенная для использования всеми компонентами системы. В которой будет крутиться основная логика. А дискретные и относительно изолированные задачи могут крутиться в отдельных потоках.
Фактически грубый аналог libevent. И по-другому ты никак не сделаешь, иначе зашьёшься. Это только в демках одна задача мигает одним диодом, а другя другим. Как до дела дойдёт, так не выйдет, потому, что нужно взаимодействие задач и чем оно сложней, тем сложней их синхронизация с одной стороны, с другой дробить на очень маленькие задачи тоже не получится, т.к. место в стеке и число задач у тебя очень ограниченным окажется. Ну и удобство отладки -- СИЛЬНО СЛОЖНЕЙ. Потому, что появится широкий класс багов, с которыми ты ранее не сталкивался.