In this blog post, the first of a three-part series, I'd like to introduce FreeRTOS, a popular and freely available Real-Time Operating System (RTOS). You may not be familiar with the concept of an RTOS or why you would use one, so we'll cover that in this first installment.
What is FreeRTOS?
FreeRTOS is a Real-Time Operating System (RTOS) kernel for embedded devices. Primarily targeted at microcontrollers, it has been ported to over 35 different microcontroller platforms. It is free software, distributed under a very liberal MIT License, although there are commercial licensing and support options available as well.
What is an RTOS?
A Real-Time Operating System, or RTOS, is essentially a scheduler that supports running tasks with well-defined, consistent, fixed time constraints. RTOSes can be event-driven or time-sharing, and usually offer pre-emptive scheduling.
It may provide support for dynamic memory allocation (e.g. C++ new and C malloc) using a deterministic (in terms of time) algorithm. It may also support for applications that only allow static memory allocation.
Finally, an RTOS often provides primitives for intertask communication and resource sharing.
It’s worth mentioning that, unlike a full operating system, an RTOS may not support (though some do) features such as a file system, TCP/IP networking stacks, or even a command line interface.
It is also typically much smaller than a full operating system, potentially much less than a megabyte in size, depending on the features that are supported.
Why Use an RTOS?
Using an RTOS is often driven by the need to support a system with hard real-time requirements. Hard real-time systems have strict deadlines for when data must be processed and are considered to fail if an event fails to occurs or is performed late. An example could be a medical device such as a pacemaker, where a delay could be fatal.
In contrast, non real-time systems, such as desktops, can tolerate delays of potentially seconds at a time. In between are so-called soft real-time systems that can tolerate some loss of data or delays. An example could be a video decoder where the occasional lost frame may be acceptable, as long as it is able to keep up for the majority of the time.
Note that standard Linux does not support hard real-time scheduling of tasks although there are real-time extensions for Linux.
A second reason for using an RTOS is the need to run on low-end hardware, such as a microcontroller, that does not support the resources (CPU, memory, and storage) needed to run a full operating system like Linux.
Very simple applications may not need an RTOS at all. My electric toothbrush contains a small processor, for example, but I doubt that it needs to do more than one simple task. This is often called bare metal programming, where the code directly runs on the hardware.
But if you need to run more than one task, and possibly some kind of interprocess communication, it usually doesn't make sense to roll your own task scheduler and communication primitives: it is better to use an RTOS to do this. Avoiding reinventing the wheel reduces development time, debugging, and testing effort, especially in safety critical devices where you may need to demonstrate that all possible risks and faults have been addressed and mitigated.
Often a system is partitioned so that UX and/or business logic runs on an application processor with a full O, while real-time functions run on one or more microcontrollers running an RTOS or bare metal. For example, a typical automobile today can have as many as 200 processors, communicating over protocols such as CAN bus.
The line between microprocessors and microcontrollers is also becoming blurred. Some microcontrollers (sometimes called "crossover" processors) can run a full OS like Linux. Some microprocessors also have separate on-chip microcontroller cores.
An RTOS is not always the best solution for embedded systems. Alternatives include using an embedded version of Linux such as Yocto (sometimes with real-time extensions) or other embedded operating system. Very simple applications may use the bare-metal approach mentioned earlier.
While this series will focus on FreeRTOS, it is just one of many RTOS alternatives. A recent reference identified this list of popular RTOSes:
- Deos (DDC-I)
- embOS (SEGGER)
- Integrity (Green Hills Software)
- Keil RTX (ARM)
- LynxOS (Lynx Software Technologies)
- MQX (Philips NXP/Freescale)
- Nucleus (Mentor Graphics)
- Neutrino (BlackBerry)
- PikeOS (Sysgo)
- SafeRTOS (Wittenstein)
- ThreadX (Microsoft Express Logic)
- µC/OS (Micrium)
- VxWorks (Wind River)
- Zephyr (Linux Foundation)
In Part 2, we'll drill deeper into FreeRTOS and explore its features, licensing and supported platforms.