[Part 2 introduces the concept of multitasking, and explains how an RTOS schedules tasks for execution. Part 4 shows how to detect and recover from deadlock, and how to avoid unsafe states. It also explains how to avoid corruption of shared resources.]
The RTOS Kernel
A kernel can be defined as the essential center of an operating system. The kernel is the core of an operating system that provides a set of basic services for the other parts of the operating system. A kernel consists of a basic set of functions:
- An interrupt handler to handle the requests that compete for the kernel's services.
- A scheduler to determine which tasks share the kernel's processing time and in which order they shall use this time.
- A manager of resources that manage system resources usage such as memory or storage and how they shall be shared among the various tasks in the system.
There may be other components of operating systems such as file managers, but these are considered outside the essential requirements of the kernel needed for core processing capability.
A RTOS consists of a kernel that provides the basic operating system functions. There are three reasons for the kernel to take control from the executing thread and execute itself:
- To respond to a system call.
- To perform scheduling and service timers.
- To handle external interrupts.
The general priority of an RTOS scheduling service is as follows (Figure 1):
Highest priority: Hardware interrupts – Hardware interrupts have the highest priority. One hardware interrupt can interrupt another.
Next Highest Priority: Software interrupts – The RTOS may also support a number of software interrupts. Software interrupts have a lower priority than hardware interrupts and are prioritized within themselves. A higher software interrupt can pre-empt a lower priority software interrupt. All hardware interrupts can pre-empt software interrupts. A software interrupt is similar to a hardware interrupt and is very useful for real-time multitasking applications. These interrupts are driven by an internal RTOS clock module. Software interrupts run to completion and do not block and cannot be suspended.
Next Highest Priority: Tasks – Tasks have lower priority than software interrupts. Tasks can also be pre-empted by higher priority tasks. Tasks will run to completion or yield if blocked waiting for a resource or voluntarily to support certain scheduling algorithms such as round robin.
Figure 1. The relative priority of activity in a DSP RTOS; hardware interrupts, software interrupts, and tasks.
The application can access the kernel code and data via application programming interface (API) functions. An API is the specific method prescribed by a computer operating system or by an application program by which a programmer writing an application program can make requests of the operating system or another application. A system call is a call to one of the API functions. When this happens, the kernel saves context of calling task, switches from user mode to kernel mode (to ensure memory protection), executes the function on behalf of the calling task, and returns to user mode. Figure 2 describes some common APIs for the DSP/BIOS RTOS.
(Click to enlarge)
Figure 2. Example APIs for DSP/BIOS RTOS.
Dynamic Memory Allocation
Dynamic memory allocation allows the allocation of memory at variable addresses. The actual address of the memory is usually not a concern to the application. One of the disadvantages of dynamic memory allocation is the potential for memory fragmentation. This occurs when there is enough memory in total but an allocation of a memory block fails due to lack of a single large enough block of memory. RTOS must manage the heap effectively to allow maximum use of the heap.