ChibiOS/RTTMHomepage
Current Version 0.6.5
-
Project on SourceForge
Documentation
Downloads
Wiki
Forum
Contact me
-
History
Description
Current ports
Design
Performance and Size
Future
-
Credits

SourceForge.net Logo

Support This Project

History

This RTOS is something I wrote back in 1990 for use on boards equipped with M68K processors, the development was made on an Atari ST. The OS worked well for its intended purpose, Internet was not widespread at that time so the system had a limited use.
Recently I decided to release this system, formerly known as mkRTOS, as Free Software. I cleaned up the code, improved the documentation, made a port on a more modern architecture (ARM) and it is finally ready.
While ChibiOS/RT is a new product it is based on a proven system so the alpha/beta phases should not last long, the project was started as an alpha version mainly to be able to incorporate the feedback into the product easily.

Description

ChibiOS/RT is designed for embedded applications and it is meant to be linked with the application code. The design philosophy is to make it easy to use so I hope that all the APIs are meaningful, easy to understand and with the parameters you would expect from them.
The system offers threads, semaphores, mutexes, messages, events, virtual timers, queues, I/O channels with timeout capability and much more. The Priority Inheritance algorithm is implemented through the Mutexes mechaninsm, the implementation supports any number of threads and nested mutexes.

Current ports

Currently the ChibiOS/RT is ported to the following architectures:
  • ARM7TDMI-LPC214x, the port to other LPC2000 chips should be trivial. Both ARM and THUMB modes are supported.
  • ARM7TDMI-AT91SAM7X256, this port also supports other Atmel chips: SAM7XC, SAM7S and the various sizes (128, 256, 512) with minimal changes.
  • ARM Cortex-M3, ST Microelectronics STM32.
  • Atmel AVR: AT90CAN128 and ATmega128 demos included.
  • Texas Instruments MSP430, complete but untested.
  • x86 as a Win32 process, this port allows to write your application on the PC without the need of a development board/simulator/emulator. Communication ports are simulated over sockets, you can telnet on the simulator ports for the debug. I am considering to create a similar simulator into a Linux process.
  • M68K, this was the original target but it is currently removed from the source tree because currently I have no way to test it, my old Atari ST is long dead. It should be very easy to revive the port to the M68K or Coldfire CPUs.
In general the port is very easy on architectures that can handle well linked lists, the kernel is entirely reliant on lists so this is a very important efficiency factor. 16 and 32 bits architectures are always fine, 8 bit architectures should be evaluated case by case but are not ruled out, something like an H8 would not have problems. You could port it to a Z80/Z180 (I considered that too, and made tests using the SDCC compiler) but the resulting code is not much efficient because the instruction set is missing the indirect addressing for 16 bits values that is important for efficient linked lists traversal.

Design

The system was designed to be stable and avoid trouble as much as possible so some rules were set:
  • No arrays or tables, I don't like to have to configure limits for data structures, only use lists or other dynamic data structures. See the Documentation and the demos.
  • No memory allocation inside the kernel, an allocator can be troublesome for RT applications. All the data structures are declared in the application code and not allocated from a shared system heap. This does not prevent the application code to use an allocator if needed, it is just the kernel that does not require it.
  • No weird macros in the user code, everything should look and feel like normal C code with a normal main() function. I don't like to bring someone else weird programming habits in my code and I think this is true for everybody.
  • Encapsulate all the things that need changes while porting the OS to new architectures in few template files, fill the code into the templates and the port is done.

Performance and Size

ChibiOS/RT has a wide set of APIs but all the subsystems can be included or removed from the memory image by editing the kernel configuration file chconf.h. On ARM processors, the kernel size starts at just 1.5KiB depending on the included subsystems and the choosen compiler optimizations.
As reference, a kernel configured with...
  • System startup code
  • Chip initialization code
  • Multithreading APIs
  • Virtual Timer APIs
  • Semaphore APIs
  • System time + Sleep API
  • Suspend/Resume APIs
  • Small main() program with flashing LEDs demo and 3 threads
...just takes 2.11KiB of program space when compiled using THUMB code and space optimizations. Note that this is quite a typical configuration not a minimal one. A kernel configured with all the options and optimized for speed takes about 6KiB. See the documentation about the many available subsystems.

About performance, on a 48MHz LPC ARM7 processor the kernel is capable of context switch time ranging from 3 to 6 microseconds depending on the code type (ARM/THUMB) and the choosen complier/kernel optimizations. In the distribution is included a spreadsheet with the exact values and the various space/time trade offs.
The context switch time is *measured* using 2 threads exchanging messages and doing *real* work, it is not a calculated peak value. See the demo code, it includes the benchmark.

Future

Expect:
  • Documentation improvements.
  • Ports to more architectures/boards when I am able to put my hands on new hardware/tools.
  • More demos.
  • Creation of new subsystems.
  • Integration with existing other free projects like: TCP/IP stacks, File Systems etc.

Credits

ChibiOS/RT was created using: