Вам действительно нужно обратиться к документации по конкретному RTOS вы собираетесь использовать, поскольку они используют разные подходы.
в целом, однако природа ОСРВА такова, что она не должна запретить доступ ввода/вывода в пользовательском потоке или контексте процесса - если I/O был ограничен некоторым привилегированным контекстом ядра, вы по существу теряете контроль над производительностью и приоритетом в реальном времени, и ядро не может знать, какие приоритеты ваших приложений и в реальном времени ограничения - это то, для чего нужен планировщик реального времени; чтобы вы могли это определить.
Принимая во внимание, что ОС общего назначения (GPOS) имеет целью защитить пространство ввода-вывода от ошибочных пользовательских процессов и контролировать доступ к этим ресурсам, в RTOS, которая обычно работает с одним фиксированным приложением, обычно это разработчик приложения который контролирует доступ к ресурсу (через блокировки мьютексов или серверные задачи для примеров), а там, где это возможно, управление доступом MMU работает, назначая права доступа для каждого потока или процесса. Так, например, поток службы связи может иметь управление пространством регистров для UART, например.
Некоторые ОС реального времени может использовать неавтоматического подход порога все ввода/вывода и память, конкретно не отображается на конкретной задачи выходит за пределы, в то время как другие могут быть неавтоматического из, где задача может доступ к любой памяти, специально не защищенной для доступа по конкретной задаче. Я помню, что VxWorks относится к выбору отказа во многом, возможно, потому, что защита от MMU является опцией, и отказ в доступе уменьшает переносимость кода между системами с поддержкой MMU и без нее, в то время как QNX, с другой стороны, работает только на оборудовании MMU, выбор вариантов.