ARM, RISC-V контроллеры

Для этого ОС не нужна. Понимаю, закат солнца вручную... Против FreeRTOS у меня сильно предубеждение, после того как прочитал, что TLS у них нет и библиотека C там, практически -- минное поле с граблями. Как с такими особенностями её (FreeRTOS) http://www.youtube.com/watch?v=0_lc81P-R8k
где-то использовать -- не понимаю. Вообще это задача не ОС. Попробую пояснить: если процессор не предусматривает контроля стека, например, то и ОС мало чем поможет. А если предусматривает, то в любом случае будет какой-то обработчик исключений, т.е. контроль стека есть. Только одно но... это уже обнаружение ошибок. А нужно скорей исключение на этапе проектирования. И я здесь не знаю хорошего подхода, кроме как оценить какой-либо методикой, приближенно, требуемый размер стека и умножить, как минимум, на Pi потом. С контролем залочки задач -- аналогично. Здесь вообще FreeRTOS может оказаться АК-47 в руках обезьяны. Нужна в первую очередь методика проектирования алгоритмов в какой-либо форме. Хоть в виде конечных автоматов им. Шалыто. А потом уже кодирование. Обычно же подход "возьмём RTOS, там же всё само, всё автоматически, всё в кайф (а при коммунизме, наверное, вообще не нужно будет умирать), и как-нибудь закодируем"... Ещё проблемой большинства так называемых RTOS является невозможность ожидания более чем одного события одновременно. За этим теряется смысл RTOS вообще (в терминах конечных автоматов возможная только линейная структура переходов между состояниями: 1->2->3->4... без вариантов). Максимум, таймауты обычно есть. Более-менее отличаются только *TRON-подобные RTOS (tnkernel), где есть концепция событий. В "больших" (windows, linux) ОС, замечу, такого ограничения нет (есть select(), WaitForMultipleEvents(), есть асинхронные сигналы или обработка событий в отдельном потоке). По-моему проблема "залочки" в таком случае становится более актуальной. Когда программистом из головы создаётся 11 тысяч ненужных примитивов синхронизации и т.п. Вместо предшествующего проектирования на бумаге. А в последнем случае, моё мнение, удобнее была бы событийно-ориентированная система программирования, однопоточная и синхронная по-возможности (проблема залочки сразу делится на 11000). С небольшим числом независимых процессов (а-ля юникс), где действительно нужно вытеснение.