Real-time vs. conventional operating system: how to choose an RTOS Generally, microcontrollers (MCUs) do not have an operating system. In the past, most embedded systems ran on microcontrollers that ran the same program all the time without requiring human intervention. Despite this, the line between microcontrollers and processors is quite blurred. MCs have general-purpose input/output (GPIO) port lines, often connected to one or more sensors and devices that are activated according to a user-written program for the microcontroller.
As the cost of computing operations has dramatically decreased and, conversely, their performance has increased, many embedded devices have become equipped with high-performance processors with a variety of peripherals and functionality. The more tasks and computations involved, the more an operating system is needed to simplify the organization and overall coordination of the embedded device.
The main task of an OS is to allocate system resources to applications that depend on those resources. Operating systems contain some important elements such as process scheduler, tasks, memory management, and the system itself: interface, file system multitasking and synchronization, interrupt handling, timers and clocks, task-to-task communications, I/O, and memory management.
For example, in the case of fault-tolerant software, the RTOS must prevent a lower-priority process from executing when a higher-priority task is running. For example, the LIDAR and video image processing used by autonomous systems for fail-safe operation of unmanned vehicles require significant computing power. Any complex system with a life safety function must have an RTOS so that the processor can make quick decisions. The RTOS should not be used when it is not absolutely necessary, but you cannot do without it if there is at least one process in the system that should be interrupted so that there is an opportunity to respond to higher priority tasks. Traditional MCs do not run multiple threads simultaneously and do not have a complex interrupt system. Embedded systems were once widespread thanks to such MCs because they were sufficient for simple tasks and the cost of high-performance solutions was high.
Modern embedded systems include microcontroller-based solutions for simple, single-cycle data processing and high-performance, processor-intensive systems that can quickly perform any required task. Fault-tolerant software has become widespread: programmable logic controllers (PLCs) are equipped with such software at the production stage. At the same time, hardware-based fault tolerance is still used in critical processes or systems, such as cancer treatments, nuclear power plants, and life support systems.
When is it necessary to use an RTOS?
An RTOS is needed when, with multiple processes and devices, process execution time is more important than average throughput. In other words, an RTOS is needed when the task is to run multiple processes at a specific time. It guarantees timing of required tasks, has less latency, can accurately determine if a task is complete, and enables both urgent and non-time-critical tasks.
RTOS makes efficient use of interrupts based on priority in the schedule. Unlike a general-purpose OS, it will ensure that tasks are completed on time, regardless of the emerging scenario.
The distinguishing feature of an RTOS is that it must be multithreaded, work ahead of the curve, and ensure thread prioritization. RTOS includes a system of priority inheritance, predictably supports thread synchronization and has a mechanism to prevent priority inversion. Priority inversion is a situation in which a less important task uses the resources of a more important task, postponing its solution. In addition, one of the main properties of RTOS is the predictability of interrupt processing latency.
RTOS developers need to inform users in detail about system interrupt levels, system calls, and timings. They need to know the maximum time for which the OS and drivers mask interrupts. The latency of an interrupt, that is, the time between its occurrence and the start of the interrupt-initiated task, should be predictable and appropriate to the application’s requirements.
What to look for when choosing an RTOS:
- What real-time capabilities does the system have? Does it incorporate soft or hard interrupt handling, and what scheduling services are available?
- Does the target processor support the required RTOS? Has it been used for such tasks before?
- How big is the memory footprint of the RTOS? IoT devices require the system to take up a small amount of memory, so it is best to use Zephyr or possibly FreeRTOS. How you configure the RTOS will also affect the amount that the system will occupy in the device’s memory, as the amount of memory depends on the services that are used by the application.
- What are the interrupt processing latencies?
- How long does context switching take? (Context switching latency is the time it takes for a process or thread to record the state of a process or thread and then run it from the point where it stopped. In this situation, multiple processes will be able to utilize a single processor).
- What interfaces are required for the task, and are they possible with the selected RTOS?
- Is it possible to debug and customize the RTOS with the selected processor, and are the drivers required for the application present?
- What development and debugging tools are compatible with RTOS?
- What is the cost of RTOS, availability of source code? In case of open source code, clarify license compatibility and check the stability of the kernel.
- Availability and quality of technical documentation or developer support forum.
- What is the reputation of the RTOS vendor?
- Can a competing company purchase the RTOS (and then withdraw support for it)?
- How flexible is the scheduling algorithm? For example, FIFO algorithms, cyclic algorithm (round Robin), monotonic, sporadic and so on.
- Is there a possibility of remote diagnostics?
- What kind of RTOS is needed: hard or soft?
Hard and soft real-time systems
A hard real-time system ensures that tasks are completed within a set deadline – the deadline time for task completion. Such a system is usually required when loss of life is possible if processing (deadline) deadlines are not met. An example of a hard real-time system is a nuclear power plant shutdown system or a flight control system.
A soft real-time system is more forgiving; deadlines are important, but only in a weighted average sense. An example of a soft real-time system is a data acquisition system. Firm RTOS-something in between soft and hard. This system basically operates as a soft system, but can also have some hard deadlines.
Note that hard and soft real-time modes are not necessarily related to the absolute value of time.