Device drivers
Phoenix-RTOS implements device drivers as device servers running on the user level. The communication with drivers is done via message passing using a well-defined interface for exchanging data between programs and drivers.
To control the device, two mechanisms are necessary and should be provided by the operating system kernel: access to device hardware registers and method of handling interrupts triggered by it. The architecture of these Phoenix-RTOS mechanisms has been presented in the chapter’s subsections.
Generic driver architecture
Each typical driver in Phoenix-RTOS consists of the main function which typically parses command line parameters, creates a driver communication port, registers it in the operating system, namespace, initializes a device, and starts processing the incoming messages.
The message is fetched from the queue using the msgRecv syscall. This syscall blocks the thread until a message is
available, so the device server should implement a thread pool to process the incoming request. The client is blocked
until the server responds to the message using the msgRespond syscall. There are two approaches to message
processing - concurrent processing and iterative processing.
Concurrent processing
Messages which can be processed instantly may be serviced by one of the main loop threads.
Iterative processing
If delays are expected (e.g. waiting for I/O) message should be inserted into the server's internal queue and processed by the internal thread.
Source code
The source code of Phoenix-RTOS device drivers could be obtained using the following command
git clone http://git.phoenix-rtos.com/phoenix-rtos-devices
The documentation of a particular driver is provided within its source code repository.