Phoenix-RTOS implements device drivers as device servers running on the user level. The communication with drivers is done via message passing using well-defined interface for exchanging the 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.
Each typical driver in Phoenix-RTOS consist of the main function which typically parses command line parameters, creates a driver communication port, registers it in the operating system, namespace, initializes device and starts processing of the incoming messages.
Message are fetched from the queue using msgRecv syscall. This syscall blocks thread until a message is available, so the device server should implement thread pool to process the incoming request. Client is blocked until server responds to the message using msgRespond syscall. There are two approaches for message processing - concurrent processing and iterative processing.
Messages which can be processed instantly may be serviced by one of main loop threads.
If delays are expected (e.g. waiting for I/O) message should be inserted to the server's internal queue and processed by the internal thread.
The source code of the Phoenix-RTOS device drivers could be obtained using the following command
git clone http://git.phoenix-rtos.com/phoenix-rtos-devices
The documentation of particular driver is provided within its source code repository.