In this chapter we will start describing specifically ChibiOS in its high level details.
The first thing that should be specified is that ChibiOS does not refer to just an RTOS scheduler but to a set of embedded components part of an overall architecture defining a typical embedded system. In this book we will cover:
The first thing to explain are the target systems for ChibiOS application. ChibiOS is meant to be used in 8, 16 and 32 bits micro-controllers starting from 2KB of RAM and 16KB of flash. It can be ported to any CPU architecture as long:
A clean CPU architecture usually makes the porting process easier.
Now we need to define the kind of applications we can create with ChibiOS, the application model is: Single Application with Multiple Threads. This means:
The ChibiOS system is strongly layered, the structure is always the same regardless of the target architecture:
The various elements will be described in greater details in next chapters, this is a brief description:
It is the code executed after the reset. The startup code is responsible for:
In ChibiOS the startup code is provided with the OS and is located under
./os/common/ports for the various supported architectures and compilers, scatter files and everything else is required for system startup are also provided.
It is the user code, ChibiOS provides a simple template of
main() function, everything else starts from there.
This is the RT scheduler kernel which is divided in two internal layers:
HAL is the acronym for Hardware Abstraction Layer, a set of device drivers for the peripherals most commonly found in micro-controllers. The HAL is split in several layers:
Note that in the above architecture it is clear that RT does not need HAL and can be used alone if HAL is not required. On the other hand, in this architecture HAL uses RT's services through the OSAL but it could use another RTOS or even work without RTOS by implementing an OSAL over the bare metal machine.
The examples in this book will cover RT and HAL both together and alone.
An important point about having an Operating System is the abstraction of the inner details in order to keep the general application code as portable as possible. Code written over well designed abstractions increase the portability of applications to newer micro-controllers, even from different vendors.
Code portability is hard in embedded software, there are an amazing series of details which are specific of the compiler, the architecture and the specific micro-controllers. An incomplete list is:
In general there is lack of complete solutions, developers are responsible for integrating bits and pieces of code from different sources into a working system, often most effort goes into resolving integration problems.
ChibiOS offers an end-to-end solution, the provided components are already well integrated each other and the application can be written to ignore most HW details using the provided high level API.
In ChibiOS the API is constant, the HW-specific details do exist, of course, but are encapsulated into platform-dependent configuration files. The application can be ported as long there are equivalent features and new configuration files are created, the rest of the code remains the same.
Among the abstractions provided by RT and HAL: