This is a brief introduction to basic Real Time Operating Systems concepts.
An RTOS is an operating system specialized for real time operations. In order to be classifiable as an RTOS an operating system must:
Other qualities like speed, features set, small size etc, while important, are not what really characterize an RTOS.
Any system can classified in one of the following categories.
A non real time system is a system where there are no deadlines involved. Non-RT systems could be described as follow:
”A non real time system is a system where the programmed reaction to a stimulus will certainly happen sometime in the future”.
A Soft real time system is a system where not meeting a deadline can have undesirable but not catastrophic effects, a performance degradation for example. SRTs could be described as follow:
”A soft real time system is a system where the programmed reaction to a stimulus is almost always completed within a known finite time”.
An Hard Real Time (HRT) system is a system where not meeting a deadline can have catastrophic effects. HRT systems require a much more strict definition and could be described as follow:
”An hard real time system is a system where the programmed reaction to a stimulus is guaranteed to be completed within a known finite time”.
As you can see speed is not the main factor, predictability and determinism are. It is also important to understand that it is not the RTOS that makes a system SRT or HRT but the system design itself, the RTOS is just a tool that you can use in the right or wrong way.
Note that both SRT and HRT processes could coexist within the same system, even non critical processes without any RT constraints could be included in a design.
Most RTOSs, including ChibiOS/RT, implement “fixed priority preemptive” scheduling algorithm. The strategy is very simple and can be described using few rules:
If the system has N cores the above strategy ensures that the N highest priority threads are being executed in any moment. Small embedded systems usually have a single core so there is only one running thread in any moment.
An explanation of how priorities are organized in ChibiOS/RT can be found in the article ”Priority Levels”.
An important role of an embedded RTOS is handling of interrupts. Interrupts are an important events source to which a system designed around an RTOS is supposed to react. We can classify interrupt sources in two main classes:
A carefully designed RTOS should implement mechanisms efficiently handling the synchronization between threads and interrupt sources. Flexibility is important at this level, the capability to wake up single or multiple threads, synchronously or asynchronously is very valuable. On the other side threads should be able to wait for a single or multiple events.
Usually interrupt events are abstracted in a RTOS using mechanism like semaphores, event flags, queues or others, there is much variability in how this is implemented by the various RTOSs.
It depends, you don't have to use an RTOS in order to design a predictable system but an RTOS offers you a methodology that can allow you to design a predictable system, without an RTOS you are basically on your own. Note that this methodology is not necessarily the “priority based multitasking” as implemented by ChibiOS/RT and many other RTOSs, this is just the most common scheme.
You may not need extreme predictability in your system but still want to use an RTOS simply because it can be convenient to use compared to a bare metal system. An RTOS, especially one designed for embedded applications, can also offer other services like, for example, a stable runtime environment, device drivers, file systems, networking and other useful subsystems.
Assuming that all the candidates can be classified as RTOSs having the mentioned minimum requirements, then are all the other features that make the difference. Usually some specific features or measurable parameters are highly regarded in RTOSs.
An important parameter when evaluating an RTOS is its response time. An efficient RTOS only adds a small overhead to the system theoretical minimal response time. Typical parameters falling in this category are:
Of course an RTOS capable to react within 2µS is better than a system that reacts within 10µS. Note that what is really meaningful is the worst case value, if a system reacts in average in 5µS but, because jitter, can have spikes up to 20µS then the value to be considered is 20µS.
A good RTOS is also characterized by low intrinsic jitter in response time. Intrinsic because jitter is also determined by the overall system design. Some factors that determine the system behavior regarding jitter are:
See the article ”Response Time and Jitter”.
In an embedded system the RTOS is an important overhead in terms of occupied memory, a more compact RTOS is preferable being all the other parameters equal because memory cost.
There are design choices that make some systems intrinsically more reliable that others. Dynamic allocation is a good example of a poor design choice because both unreliability and response time unpredictability of some allocation schemes. Fully static designs do not have those intrinsic limitations.
Variety in available primitives is also an important factor to be considered. Having the correct tool for the job can reduce development time and often also helps when integrating external code with the RTOS.
A good example is the lwIP TCP/IP stack, it assumes an RTOS offering semaphores with timeouts, if your RTOS does not support semaphores and timeouts then you have a problem and will have to find a workaround.