Search code examples
kernelgpiortossysfs

Is it possible to access the I/O from user space in modern RTOS?


I was wondering if there is any existing functionality to access to I/O (in particular GPIO) from user space (instead of kernel space) in modern RTOSes (with MMU) such as QNX, Lynx, VxWorks, etc?

In Linux (e.g. Raspbian) you can do it via sysfs. Is there any similar functionality exist in RTOS? (it should not be exactly the same style of a file system for exporting kernel objects but anything that let the user control the GPIO. If there is, is it enabled by default? If it is enabled for other type of I/Os but not GPIO it is also fine.


Solution

  • You really need to consult the documentation for the specific RTOS you intend to use as they use different approaches.

    Generally however the nature of an RTOS is such that it should not disallow I/O access in a user thread or process context - if I/O were restricted to some kernel privileged context you essentially loose control of the real-time performance and priority and the kernel cannot know what your applications priorities and real-time constraints are - that is what the real-time scheduler is for; to allow you to determine that.

    Whereas a general-purpose OS (GPOS) aims to protect the I/O space from errant user processes and to control access to those resources, in an RTOS which generally runs a single fixed application, it is normally the application developer who controls access to a resource (via mutex locks, or server tasks for examples), and where available, MMU access control works by assigning access rights on a per thread or process basis. So for example a communications service thread may have control of the register space for a UART for example.

    Some RTOS may use an opt-in approach wher all I/O and memory not specifically mapped to a specific task is out-of bounds, while others may be opt-out where a task can access any memory not specifically protected for access by a specific task. I recall VxWorks is of the opt-out variety largely perhaps because MMU protection is an option and opt-in would reduce code portability between systems with and without MMU support, while QNX on the other hand only runs on MMU hardware, so is of the opt-in variety.