Homepage

distortos

object-oriented C++ RTOS for microcontrollers

  • fully preemptive
  • round-robin and FIFO scheduling
  • all basic primitives aim for maximum compatibility with POSIX, thread support library from C++11 and other established standards
  • support for various mutex types (normal, error-checking, recursive) and mutex protocols (normal, priority inheritance, priority protection)
  • software timers
  • POSIX-style signals
  • static design where it is possible and makes sense
  • object-oriented design
  • written in C++11

Targets

Currently supported targets for distortos are:

  • ARMv6-M architecture (ARM Cortex-M0(+), ARM Cortex-M1): STM32F0, STM32L0
  • ARMv7-M architecture (ARM Cortex-M3, ARM Cortex-M4(F), ARM Cortex-M7(F)): STM32F1, STM32F4, STM32F7, STM32L4

Motivation and goals

First of all – distortos doesn’t aim to be the smallest or the fastest RTOS available. It’s size and execution overhead are proportional to the features offered. This of course doesn’t mean that it uses hundreds of kilobytes of ROM and RAM or all available processing power! It uses “just enough” to implement its functionality in a portable and efficient way.

There are many RTOSes available in many flavours and for many platforms, so why another? There are many reasons, but generally distortos was born of dissatisfaction with all of these existing solutions… Distortos aims to have all good features and none of the broken ones.

The second important reason is the state of support for various C++ features in existing RTOSes, which usually varies from “non existent” to “explicitly disabled” (with minor exceptions of course).

Despite the popular belief, using C++ does not automatically lead to slow/bloated/incomprehensible/… code, which distortos will try to demonstrate. Source code of distortos is self-explanatory, simple and consists of short functions. This contrasts with “typical” RTOS source code in the form of extremely long functions with very complex control flow and heavy use of macros. And that would be the third reason – showing that source code of fully-featured RTOS can be simple, while still being efficient and feature-rich.

Last, but not the least, most of these existing RTOSes require the developer to state some values during configuration – max number of threads in the system, max number of supported priorities, etc. – this makes no sense at all, because a good, scalable design doesn’t need such values.

License

This project is licensed under the terms of Mozilla Public License Version 2.0. This relatively new license is something in between other popular open source licenses like GPL or BSD. Most of the questions are answered in the MPL 2.0 FAQ.