Starting from version 7, ChibiOS/RT offers support for multiple cores. There are 3 separate scenarios:

• Single Core.
• Weak SMP.
• Full SMP.

This is the classic ChibiOS/RT mode, it is activated when CH_CFG_SMP_MODE == FALSE in chconf.h. In this mode there is a single CPU running the OS.

• Only one CPU.
• No SW overhead.
• Compatible with previous RT versions.

In this mode a separate instance of ChibiOS/RT runs on each core, the various instances cannot interact each other, this means that it is not possible to share objects (semaphores, queues, mutexes, etc) between threads belonging to different cores.

This mode requires CH_CFG_SMP_MODE == FALSE in chconf.h but multiple instances of the RTOS can be started using chInstanceObjectInit(), basically it is the same of Single Core mode but it requires specific support in the port layer.

Note that the multiple instances are not multiple copies of the RT code, there is a single OS image, what is duplicated is just the OS object os_instance_t which is quite small.

• Mutiple CPUs.
• Very small SW overhead.
• Various OS instances cannot interact directly each other but can still synchronize/communicate using HW mechanisms like mailboxes, semaphores, spinlocks, interrupts etc.
• Each instance has its own Registry listing only its own threads.
• Each instance has its own Virtual Timers list and handling.
• OS objects belong to the instance who initialized them and must not be touched by other instances.

The full SMP mode is one OS running on multiple cores, it is activated when CH_CFG_SMP_MODE == TRUE in chconf.h. Threads are assigned to cores and can interact each other using normal OS mechanisms without limitations.

• Multiple CPUs.
• Moderate SW overhead.
• Critical sections are core-aware and protect from IRQ and other cores as well.
• Virtual Timers are processed by the OS instance that started them, the callback is invoked by an IRQ served on the same core.
• There is a centralized Registry listing thread assigned to all cores.
• Support for core affinity, threads are statically assigned to the core who started them, threads do not “migrate” across cores.
• Support for memory affinity, it is possible to allocate stacks/variables/structures/objects to RAM areas closer to specific cores for performance optimization.

HAL can work in SMP modes following some simple rules:

• A core starting a driver is also the core serving its interrupts, this allows to spread the IRQ workload over multiple cores.
• In Weak-SMP mode a driver started by an instance should only be used by threads belonging to that instance. This restriction does not exist in Full-SMP mode where any thread can use anything.

Everything else works as usual.