Real Time Operating System (RTOS) is an operating system that supports real-time applications and embedded systems by providing a logically correct result within the deadline required. Such capabilities define its deterministic timing behaviour and limited resource utilization nature. Real Time Operating System are broadly classified into three types, namely, Hard Real-Time RTOS, Firm Real-Time RTOS and Soft Real. The selection of an operating system is done by considering the requirement of a system whether it is Soft Real-Time or Hard Real Time. Operating systems such as Windows, Linux, UNIX etc are General purpose Operating system which is used in a soft real-time based systems, whereas Real Time Operating System(RTOS) such as FreeRTOS, VxWorks, uCos etc are used in Hard real-time systems such as embedded systems where time is critical. The RTOS used in embedded systems that can be used to handle or schedule a task, execute a task on the basis of priorities etc.
Features of Real Time Operating System
A basic RTOS will be equipped with the following features:
Multitasking and Preemptibility
An RTOS must be multi-tasked and preemptible to support multiple tasks in real-time applications. The scheduler should be able to preempt any task in the system and allocate the resource to the task that needs it most even at peak load.
Task Priority
Preemption defines the capability to identify the task that needs a resource the most and allocates it the control to obtain the resource. In RTOS, such capability is achieved by assigning the individual task with the appropriate priority level. Thus,it is important for RTOS to be equipped with this feature.
Reliable and Sufficient Inter Task Communication Mechanism
For multiple tasks to communicate in a timely manner and to ensure data integrity among each other, reliable and sufficient inter-task communication and synchronization mechanisms are required.
Priority Inheritance
To allow applications with stringent priority requirements to be implemented, RTOS must have a sufficient number of priority levels when using priority scheduling.
Predefined Short Latencies
An RTOS needs to have accurately defined short timing of its system calls. The behavior metrics are:
Task switching latency: The time needed to save the context of a currently executing task and switching to another task is desirable to be short.
Interrupt latency: The time elapsed between the execution of the last instruction of the interrupted task and the first instruction in the interrupt handler.
Interrupt dispatch latency. The time from the last instruction in the interrupt handler to the next task scheduled to run.
Control of Memory Management
To ensure predictable response to an interrupt, an RTOS should provide way for task to lock its code and data into real
memory.
The basic functionalities of Real Time Operating System are:
An operating system generally consists of two parts: kernel space (kernel mode) and userspace (user mode). Kernel is the smallest and central component of an operating system. Its services include managing memory and devices and also to provide an interface for software applications to use the resources. Additional services such as managing protection of programs and multitasking may be included depending on the architecture of an operating system.
The architecture of an RTOS is dependent on the complexity of its deployment. For simple applications, an RTOS usually comprises only a kernel. For more complex embedded systems, an RTOS can be a combination of various modules, including the kernel, networking protocol stacks, and other components. The basic functionalities of RTOS are:
1. The Scheduler
The Scheduler is the part of the kernel responsible for deciding which task should be executing at any particular time. The kernel can suspend and later resume a task many times during the task lifetime. The scheduling policy is the algorithm used by the scheduler to decide which task to execute at any point in time. Tasks can have four states.
Ready –When the task has all the resources to run, but not in running state. It’s called a ready to run the task. It’s the state before running.
Running– When a task is executing currently. It is known as running.
Blocked– When a task doesn’t have enough resources to run, it is sent to a blocked state.
Suspended – When a task goes in the suspended state they are also not available for scheduling. It seems that the tasks in both Blocked and Suspended are in the waiting state. But the difference is, a suspended task can’t be in the Ready state unless the user manually resumes it.
To schedule a task, three techniques are adapted.
Co-operative scheduling: In this scheme, a task runs, until it completes its execution.
Round Robin Scheduling: Each task is assigned a fixed time slot in this scheme. The task needs to complete its execution. Otherwise, the task may lose its flow, and data generated or it would have to wait for its next turn.
Preemptive Scheduling: This scheduling scheme includes priority dependent time allocation. Each task is assigned a unique priority level. While some system may support more priority levels, and multiple tasks may have same priorities.
In RTOS the Kernel takes care of the task. It involves the following functions:
Creating a task
Deleting a task
Changing the priority of the task
Changing state of the task
2. Real Time Operating System Services
The kernel manages and allocates the resources for a particular task in RTOS. As tasks cannot acquire CPU resources all the time, the kernel provides some services like,
Memory management services – When a process is created the memory manager allocates the memory addresses to it by mapping process address space. are two types of memory management in RTOSs. They are Stack and Heap
The allocation of memory for different context such as registers contents, program counter, etc is done by task control block. This block of memory is known as Kernel Stack and its management is called Stack management
After the completion of a program initialization, the physical memory of the MCU or MPU will usually be occupied with program code, program data and system stack. The remaining physical memory is called Heap. This heap memory is typically used by the kernel for dynamic memory allocation of data space for tasks. The memory is divided into fixed size memory blocks, which can be requested by tasks. When a task finishes using a memory block it must return it to the pool. This process of managing the heap memory is known as Heap management
Timer services – In embedded Systems for proper scheduling of system and user tasks there is a need for a periodical interrupt to keep track of time delays and timeout, these timer services are used for this proper management. Another timer service provided is in meeting task deadline by cooperating with task schedulers to determine whether tasks have met or missed their real-time deadlines.
Interrupt handling services – One of the central tasks of real-time software is the processing of interrupts. As soon as several tasks run in a program, it is virtually impossible to achieve good response times by polling. Continuous polling would prevent tasks with lower priorities from running and thus waste precious CPU time. To avoid this RTOS uses Interrupt, a hardware mechanism to let know the CPU that an asynchronous event has occurred. The interrupt handler may be thought of as a task running with a priority higher than all other tasks. While an interrupt handler is active, no other interrupts with lower priorities can be processed.
Device I/O management services – In an embedded system there are differ device drive ISRs for each device. Each driver function of a device calls a separate ISR. The device I/O manager is the software that manages all these in the RTOS.
3. TASK Synchronization and messaging
Task Synchronization and Messaging provides a means of communication with other system and between the tasks. This service includes
Event flags– Event flags are used when task synchronization is required without resource sharing. They allow one or more tasks to keep waiting for a specified event to occur. An event flag can exist in either of two states: triggered and non-triggered. An event flag in a triggered state indicates that a waiting task may resume. In contrast, if the event flag is in a non-triggered state, a waiting task will need to stay suspended.
Semaphores– A semaphore is a protocol mechanism offered by most multitasking kernels. Semaphores were originally used to control access to shared resources. A semaphore functions like a key that defines whether a task has the access to the resource. A task gets an access to the resource when it acquires the semaphore. The resource count of a semaphore determines the number of times the semaphore can be acquired. When a task acquires the semaphore, its count decrement by one. Likewise, its count increment by one when a task releases the semaphore. Generally. There are three types of semaphore:
Binary Semaphores (semaphore value of either 0 or 1 to indicate unavailability and availability respectively)
Counting Semaphores (semaphore value of 0 or greater indicating it can be acquired/released multiple times)
Mutually Exclusion Semaphores (semaphore value of 0 or 1 but lock count can be 0 or greater for recursive locking)
Message queues– A message queue is an object used for intertask communication through which task send or receive messages placed in a shared memory. Tasks and ISRs send and receive messages to the queue through services provided by the kernel.
Pipes– A pipe is a unidirectional data exchange facility for opening, closing, writing to and reading data between two given interconnected tasks or two sets of tasks. Data is written into the pipe as an unstructured byte stream via one descriptor and read from the pipe in the FIFO order from the other. Unlike message queue, a pipe does not store multiple messages but a stream of bytes. In addition, data flow from a pipe cannot be prioritized.
Mailboxes– A mailbox is a data buffer that can store a fixed number of messages of a fixed size. Tasks can store messages in a mailbox. If the mailbox is full, the task is blocked until space becomes available. In this case, the task is blocked if no message is available in the mailbox. Any number of tasks can use the same mailbox for storing and retrieving messages.