Вам действительно нужно ознакомиться с документацией для конкретной RTOS, которую вы собираетесь использовать, поскольку они используют разные подходы.
Однако в целом природа RTOS такова, что она не должна запрещать доступ ввода-вывода в пользовательском потоке или контексте процесса — если ввод-вывод ограничен некоторым привилегированным контекстом ядра, вы по существу теряете контроль над производительностью и приоритетом в реальном времени и ядро не может знать, каковы приоритеты ваших приложений и ограничения в реальном времени — для этого и нужен планировщик реального времени; чтобы вы могли это определить.
В то время как ОС общего назначения (GPOS) предназначена для защиты пространства ввода-вывода от ошибочных пользовательских процессов и управления доступом к этим ресурсам, в RTOS, которая обычно запускает одно фиксированное приложение, обычно разработчик приложения контролирует доступ к ресурс (например, с помощью блокировок мьютексов или серверных задач), и, где это возможно, управление доступом к MMU работает путем назначения прав доступа для каждого потока или процесса. Так, например, поток службы связи может контролировать пространство регистров, например, для UART.
Некоторые RTOS могут использовать подход opt-in, когда все ввод-вывод и память, не привязанные конкретно к конкретной задаче, выходят за рамки допустимого, в то время как другие могут opt-out, где задача может получить доступ к любой памяти, не защищенной специально для доступа конкретной задачей. Я припоминаю, что VxWorks относится к категории отказоустойчивых, возможно, потому, что защита MMU является опцией, а опцион снижает переносимость кода между системами с поддержкой MMU и без нее, в то время как QNX, с другой стороны, работает только на аппаратном обеспечении MMU, поэтому опциональное разнообразие.
person
Clifford
schedule
26.01.2016
