Introduction to RTOS
INTRODUCTION TO RTOS
- What is RTOS?
RTOS or Real-Time Operating System is an operating system similar to those you are generally more aware of, like Windows, Linux, and the like. Wikipedia describes RTOS as "an operating system (OS) intended to serve real-time applications that process data as it comes in, typically without buffer delays." In essence, what this means, in RTOS, data is processed based on priority, and the time taken to process the data / execute the task is deterministic in nature, i.e. it is possible to predict the total time taken. Therefore, in RTOS, if the time taken to complete an event misses the defined "deadline" (provided it is realistic in nature), then the system is said to have failed. Some widely used RTOS are FreeRTOS, Zephyr, Mbed OS, embOS and others.
- What is GPOS?
You might be wondering, well, if both RTOS and Windows/Linux are examples of operating systems, how are they different? Operating Systems like Windows, Linux, macOS, iOS, and Android are all GPOS or General Purpose Operating System examples or Normal OS (general perception).
In GPOS, the design is such that the OS's responsiveness by the User is more critical than handling the underlying tasks. Moreover, the task scheduling in a GPOS does not happen based on the task's priority always. Instead, a GPOS always tries to achieve high throughput or complete the maximum number of processes per unit time.
To achieve this high throughput, the scheduling in a GPOS is typically 'fair', which allows for equal distribution of CPU resources between processes/users. As a result, sometimes the execution of a high priority process gets delayed so that 4-5 lower priority tasks can be completed. Thus one can easily make out that in a GPOS, there is no guarantee that high priority or, in essence, time-critical tasks will execute before lower-priority tasks.
For example, while copying the files, the time taken depends on the background processes running and the CPU resources available at that point in time.
- Why is RTOS needed when a GPOS already exists?
An RTOS comes into play when the situation demands the event to be completed within its timeline. There are so many time-critical events in our actual physical world where you simply cannot compromise even a delay of a millisecond.
Few examples include -
- Deploying airbags in an automobile as soon as a crash is detected.
- Generating electrical pulses at proper intervals in a pacemaker.
- Operation of Industries/Power Plants.
In an RTOS, the scheduler is designed to provide a deterministic or predictable execution pattern. This deterministic behaviour of RTOS guarantees the system meets its real-time requirements or, in other words, responds to a particular event within a deadline. The consequences (or features) of designing such a system where tasks must be completed within their timeline results in the task-scheduling being priority based.
To give an example: Assume a task with priority 1 takes 20ms to be addressed, and another task with priority 2 takes 100ms to be addressed. If only priority 1 task occurs every second, then we can say that the worst-case execution time (WCET) for priority 2 task is 120ms. This gives a sort of basic idea as to why prioritising tasks makes the system deterministic.
In most RTOS, a pre-emptive task scheduling method is implemented to achieve this. Here, suppose another task with a higher priority than the current task is introduced. In that case, the current one (low-priority) is paused midway, and the new task (high priority) is executed. This ensures that a high priority task is always executed before the low priority ones at any point in time.
Therefore, when compared to a GPOS, the throughput of RTOS is less, but it doesn't matter if the most critical factor in your system in time. Another stark difference between GPOS and RTOS is the way they manage shared resources. In an RTOS, the allocation of resources is very efficient and optimised based on the task's priority, whereas, in a GPOS, resources are allocated in a 'fair' manner.
- RTOS in Embedded Systems:
Unlike GPOS, RTOS are small in size and light-weighted because they aren't meant for general purpose use as a desktop but for stand-alone devices with limited hardware where running certain applications on specific hardware is of primary concern.
Since an embedded system is a computer hardware system with a microprocessor and software designed to perform a dedicated function with often real-time computing constraints, RTOS is a prevalent choice for complex embedded applications. But, an OS isn’t required if the system is relatively small/simple (few input sensors controlling one or more output devices), which can be handled using the application software. However, if the embedded system is a bit complex, including an RTOS makes the system more deterministic, aids in monitoring errors, eases debugging and ensures optimum resource use, leading to a more robust system.
A practical example is an ATM. Since the focus of an ATM is only specific functions and expectations (withdrawal, money transfer, etc.) in real-time, low-end hardware with RTOS is used rather than high-end hardware with GPOS. Other examples include GPS Navigation Systems, Guidance of Missile Systems, Space Rovers, Assembly Robots for manufacturing, Air and Road Traffic Monitoring and Collision Alert, and the like.
In conclusion, RTOS offers the most practical solution for use in embedded systems in scenarios with large interrupt sources, peripherals with multiple control loops to make the system behave predictably under controlled priority levels.
We will be continuing this series of blogs on RTOSes by demonstrating practical applications of the same for development platforms like Arduino and ESP32.
Do stay tuned for future blogs. Till then stay home, stay safe, stay creative!!!
KRSSG, IIT Kharagpur