ChibiOS/RT offers a variety of mechanisms and primitives, often it is better to focus on a single approach for the system design and use only part of the available subsystems.
Correct, single thread, it is not mandatory to use the multithreading features of the OS. You may choose to implements everything as a complex state machine handled in the main thread alone. In this scenario the OS still offers a variety of useful mechanisms:
In this configuration the kernel size is really minimal, everything else is disabled and takes no space. You always have the option to use more threads at a later time in order to perform separate tasks.
In this scenario there are multiple threads in the system that never share data, everything is done by exchanging messages. Each thread represents a service, the other threads can request the service by sending a message.
In this scenario the following subsystems can be used:
The advantage of this approach is to not have to deal with mutual exclusion, each functionality is encapsulated into a server thread that sequentially serves all the requests.
For example, you can have the following scenario:
Example: Note that the threads should not exchange complex messages but just pointers to data structures in order to optimize the performance. Also note that a thread can be both client and server at the same time, the FS service in the previous scenario for example.
This is the most common scenario, several threads have access to both their private data and shared data. Synchronization happens with one of the mechanisms described in the ”ChibiOS/RT mutual exclusion guide”.
All the above approaches can be freely mixed in a single application but usually it is preferred to choose a way and consistently design the system around it. The OS is a toolbox that offers a lot of tools but you don't have to use them all necessarily.