ChibiOS/RT General Architecture

This document describes the ChibiOS/RT general architecture, it also introduces terminology and concepts used in other documents.


ChibiOS/RT is a very modular design, it is internally divided in several major independent components. The components themselves are divided in multiple subsystems.


This is the platform independent part of the OS kernel. Note that the kernel together with its port layer is a totally stand alone system and can work even without the HAL or any other component.

Port Layer

This is the architecture/compiler dependent part of the OS kernel. This component is responsible of the system startup, interrupts abstraction, lock/unlock primitives, context switch related structures and code.
This component usually contains very little code because most of the OS is very portable but the quality of the implementation of the Port component can affect heavily the performance of the ported OS. This is probably the most critical part of the whole OS.

Hardware Abstraction Layer

This component contains a set of abstract device drivers that offer a common I/O API to the application across all the support platforms. The HAL code is totally portable across the various architectures and compilers. Drivers are classified in several classes:

Normal Drivers

This class of drivers is composed of a portable abstract High Level Driver (HLD) and a platform-specific Low Level Driver (LLD). Normal drivers are supposed to be generic enough to be ported on various platforms by just writing a specific LLD.

Complex Drivers

This class of drivers is entirely portable and does not have any hardware dependencies, this class relies on other drivers for its I/O needs. Complex subsystems like a File System or a networking stack can be seen as Complex Drivers in the general architecture.

Platform Drivers

This class of drivers is specific of a platform and it is not meant to be portable. Code shared among multiple drivers is usually implemented as a platform driver.

Platform Layer

This layer contains a set of device drivers implementations. Device driver implementations are usually dedicated to a whole products family rather than a specific MCU model.

Board Initialization

Board files are used by the system startup in order to initialize the target board, the HAL and the Kernel before launching the application.


This is a library of various extra utilities that do not belong to any particular component but can make life easier while developing an embedded application.


The following diagram shows the relationships among the various components/layers that compose the system:

Kernel Architecture

The kernel itself is very modular and is composed of several subsystems, most subsystems are optional and can be switched of in the kernel configuration file chconf.h.

Base Kernel Services

This category contains the mandatory kernel subsystems:

  • System, low level locks, initialization.
  • Timers, virtual timers and time APIs.
  • Scheduler, scheduler APIs, all the higher level synchronization mechanism are implemented through this subsystem, it is very flexible but not recommended for direct use in application code.
  • Threads, thread-related APIs.

Base services diagram:


This category contains the synchronization-related subsystems, each of the provided mechanism can be configured out of the kernel if not needed.

  • Semaphores, counter and binary semaphores subsystem.
  • Mutexes, mutexes subsystem with support to the priority inheritance algorithm (fully implemented, any depth).
  • Condvars, condition variables, together with mutexes the condition variables allow the implementation of monitor constructs.
  • Events, event sources and event flags with flexible support for and/or conditions and automatic dispatching to handler functions.
  • Messages, lightweight synchronous messages.
  • Mailboxes, asynchronous messages queues.

All the synchronization mechanisms are built on top of the Scheduler APIs except Mailboxes and Binary Semaphores that are build on top of Semaphores and Condition Variables that implicitly refer to Mutexes.
Synchronization services diagram:

Memory Management

This category contains the memory management related subsystems:

  • Core Allocator, centralized core memory manager, this subsystems is used by the other allocators in order to get chunks of memory in a consistent way.
  • Memory Heaps, central heap manager using a first fit strategy, it also allows the creation of multiple heaps in order to handle non uniform memory areas.
  • Memory Pools, very fast fixed size objects allocator.
  • Dynamic Threads, usually threads are static objects in ChibiOS/RT but there is the option for dynamic threads management.

Memory Management services diagram:

Streams and I/O Channels

This category contains I/O and data exchange related subsystems:

  • Data Streams, abstract streams interface.
  • I/O Channels, abstract I/O channels that inherits from the abstract stream interface.
  • I/O Queues, generic, byte wide, I/O queues APIs.


Debug related subsystems and options:

  • Assertions, debug time integrity checks.
  • Parameter Checks, debug time API parameter checks.
  • Stack Checks, runtime stack checks.
  • Trace Buffer, context switch circular trace buffer.
  • Registry, the Registry subsystem can be seen as part of the debug category even if it finds use in non-debug roles.

HAL Architecture

The HAL is a collection of abstract device drivers, it relies on the Platform component for the low level implementation on specific hardware. The purpose of the HAL is to offer a cross platform API to access common peripheral types.
It should be noted that, while the API is really cross platform, the low level driver implementation is not. The driver configuration data is defined in the low level driver and is thus not necessarily portable.

Device Driver Types

In ChibiOS/RT there are two kind of device drivers. The device drivers are classified differently depending if they interact directly with the hardware or not.

Normal Device Drivers

This kind of drivers are split in an high level driver (HLD) part and a low level driver (LLD) part. Any access to the hardware is performed in the dedicated LLD driver. Examples of normal device drivers are the SPI and the UART drivers.

Complex Device Drivers

This kind of drivers implement a complex, high level, functionality and do not access any hardware directly. Complex Device Drivers use other device drivers, either complex or normal, in order to interact with the hardware. An example of this kind of drivers is the MMC/SD over SPI driver that uses a generic SPI driver in order to perform its function.

HAL Diagram

The overall current internal HAL organization is the following:

chibios/documents/architecture.txt · Last modified: 2014/08/28 12:42 by giovanni
Except where otherwise noted, content on this wiki is licensed under the following license:GNU Free Documentation License 1.3