Architecture

ChibiOS/RT General Architecture

• Components
• Dependencies
• Kernel Architecture
• HAL Architecture

Components

ChibiOS/RT is composed of several major components, each component can be composed of one of more subsystems. The main components are:

• Kernel, this is the platform independent part of the OS kernel.
• HAL, 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 platforms.
• Port, this is the platform 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.
  The component usually contains very little code because the OS is very portable but the quality of the implementation of the Port component affects heavily the performance of the ported OS. It is probably the most critical part of the whole OS.
• Platform, this component contains a set of device drivers implementations.
• Various, a library of various extra components that do not belong to any particular component but can make life easier while developing an embedded application.

Dependencies

The following diagram shows the relationships among the various components 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.
The current kernel subsystems are divided in five categories:

• Base Kernel Services, this category contains the mandatory kernel subsystems:
  • System Management, low level locks, initialization.
  • Time and Virtual 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 user code.
  • Threads, thread-related APIs.
  Base services diagram:
  
  
  
• Synchronization, this category contains the synchronization-related subsystems, each one of the provided mechanism can be configured out of the kernel if not needed.
  • Semaphores, counter semaphores subsystem.
  • Mutexes, mutexes subsystem with support to the priority inheritance algorithm (fully implemented, any depht).
  • Condition Variables, condition variables, together with mutexes the condition variables allow the implementation of monitor constructs.
  • Event Flags, event sources and event flags with flexible support for and/or conditions and automatic dispatching to handler functions.
  • Synchronous Messages, lightweight synchronous messages.
  • Mailboxes, asynchronous messages queues.
  All the synchronization mechanisms are built on top of the Scheduler APIs except Mailboxes that are build on top of Semaphores and Condition Variables that implicitly refer to Mutexes:
  
  
  
• Memory Management, memory management, multiple non-alternative schemes are available:
  • Core Memory Manager, centralized core memory manager, this subsystems is used by the other allocators in order to get chunks of memory in a consistent way.
  • Heaps, central heap manager using a first fit strategy, it also allow the creation of multiple heaps in order to handle non uniform memory areas.
  • Memory Pools, very fast fixed size objects allocator.
  • Threads (dynamic), usually threads are static objects in ChibiOS/RT but there is the option for dynamic threads management, please see the article Threads Lifecycle.
  The various allocators follow a precise hierarchy:
  
  
  
  Please also see the article How to manage memory.
• I/O Support, the kernel also provides mechanisms and abstract data interfaces that can be used by non-kernel components, the HAL as example.
  • 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, debug services and APIs. The Registry susystem 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 current internal HAL organization is the following:

See HAL for details about the various HAL subsystems.