An RTOS is an operating system specialized for real time operations. In order to be classifiable as an RTOS an operating system must:

• Have response time predictability.
• Be deterministic.

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:

• Each thread has its own priority level, priorities are fixed and do not change unless the system is specifically designed to do so.
• Each active thread can be in one of the following states:
  • Running, currently being executed by a physical core.
  • Ready, ready to be executed when a physical core will become available.
  • Waiting, not ready for execution because waiting for an external event. Most RTOSs split this state in several sub-states but those are still waiting states.
• Each physical core in the system always executes the highest priority thread that is ready for execution.
• When a thread becomes ready and there is a lower priority thread being executed then preemption occurs and the higher priority thread is executed, the lower priority thread goes in the ready state.

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:

• RTOS-related interrupt sources. This class of interrupts are required to interact with the RTOS in order to wakeup threads waiting for external events.
• Non RTOS-related interrupt sources. Interrupt sources that do not need to interact with the RTOS. This class of interrupts could also be able to preempt the kernel in those architectures supporting maskable priority levels (ARM Cortex-M3) or separate interrupt lines (ARM7).

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:

• Interrupt latency, the time from an interrupt request and the interrupt servicing. An RTOS can add some overhead in interrupt servicing. The overhead can be caused by extra code inserted by the RTOS into the interrupt handlers code paths or by RTOS-related critical zones.
• Threads fly-back time, the time from an hardware event, usually an interrupt, and the restart of the thread supposed to handle it.
• Context switch time, the time required to synchronously switch from the context of one thread to the context of another thread.

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:

• Thread priorities assignment.
• Interrupt priorities assignment.
• Length and number of critical zones.
• Interactions between threads through shared resources protected by mutual exclusion.
• Use of priority inheritance or other jitter-reducing algorithms/strategies.

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.