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

Задача в принципе решима... Но для начала следует понимать некоторые вещи, после чего придёт также понимаение, что не стоит пытаться её решать таким путём. Во-первых FreeRTOS. Данная "ОС" фактически -- это способ запуска многопоточных программ на одном CPU. Особенностью таких программ как раз и является отсутствие защитных механизмов между потоками. Потому, что потоки активно используют общую память для обмена даными. Это и динамически выделяемая память, и стек (передача ссылки на переменную в стеке), и программная память (callback-функции в теле другого потока), и data сегмент (глобальные или статические переменные) тоже. Практически MPU нечего защищать. Только, разве что, запретить запись в сегмент text и память ядра (SFR тоже). Другие ОС могут реализовать многозадачность с полной изоляцией процессов. Когда никакая часть памяти одного процесса не доступна из других процессов (по крайней мере, если не принимать специальных мер по получению участка разделяемой памяти). Но подход к программированию в таких ОС несколько другой, в частности нужны развитые средства межпроцессного взаимодействия. Типичный пример -- любая unix-подобная ОС. Насколько я понимаю, во FreeRTOS с поддержкой MPU так же и сделано, но использование malloc из коробки не предполагается. Можно сделать свою кучу в каждой такой задаче (что мало осмысленно, ибо она не может расти, см. ниже). Касательно C++, malloc и FreeRTOS. Меня всё удивляет, как это во FreeRTOS нет реализации TLS. В частности библиотека C не может корректно работать (начиная с errno). Дальше больше. Исключения в C++ тоже будут опираться на TLS. Без TLS их невозможно реализовать. Я понимаю, что TLS можно сделать самому... Функция malloc в eCOS, FreeRTOS и т.п. ОС (с потоками, а не процессами) обычно использует общую кучу для всех потоков. Её тяжело защитить от средствами MPU. Можно пытаться -- это как-то сделали в ucLinux. Фактически, как я понял, там постоянно возникают исключения ввиду попадания за пределы разрешённой памяти и дальше идёт программный анализ, переконфигурация MPU и продолжение работы. И таким вот образом можно MPU использовать для работы с кусочно-выделенной памятью, а не с несколькими непрерывними выровненными кусками. В unix-подобных ОС же куча (malloc) у каждого процесса своя. Поэтому защищать нужно только непрерывный кусок памяти в целом, что проще. Но в системах без MMU подход применяемый в unix не позволяет наращивать объём памяти выделенный процессу (функции sbrk и brk). Память нужно выделить заранее, при старте процесса, что кажется тупиковым путём. Т.е. подходит для случаев, когда malloc нужен скорей чисто формально, в каких-то небольших и примерно известных заранее объёмах. Иначе -- не вариант. Касательно выбора компилятора -- я бы очень хорошо подумал, о том, что C/C++ библиотека то же крайне важна. И мне не совсем понятно, как это компилятор сертифицируется, а библиотека? Библиотека фирмы Dinkumware может преподнести массу сюрпризов... И насколько она стыкуется с ОС? Если предполагается внешнее ОЗУ значительных размеров, то может ucLinux не самый плохой выбор (я не в курсе дела абсолютно)? С подходом "проф. уровня" (вспоминаем PIC) и отказом от C-библиотеки далеко не уедешь. Потенциально можно изучить и применить подход из ucLinux. Или самостоятельно сделать что-то вроде такого: общую на всех кучу, где в каждом выделенном сегменте памяти будет так же запись об id процесса, которому он принадлежит, а также все сегменты с одним id будут связаны отдельным списком (для массового высвобождения при завершении процесса). Обработчик исключения должен смотреть, куда пытается обратиться процесс. Нужен какой-то метод быстрого получения информации о сегменте по произвольному адресу в его середине. Если идёт обращение в свой сегмент в куче -- кусок памяти добавляется в MPU (тут отдельная непростая история, как быть с выравниванием и размерами). Если в чужой -- аварийная ситуация. И несколько (три -- абсолютный минимум, наверное, иначе будет очень сильно тормозить) динамически-перепрограммируемых сегментов MPU для того с алгоритмом типа LRU (какой исключать из исползования при нехватке).