[Engineering Essentials]
The RTOS Motto: On Time And On Budget
Scheduling and resource allocation are the dominant factors in determining what real-time operating system fits best.
Of the required features for an operating system, one is optional in an RTOS environment—reentrant libraries. In a typical operating system, this is a requirement because the tasks and programs tend to be arbitrary and changing, as well as prone to sharing libraries.
In an embedded environment, there’s usually more control over the programs and tasks running in the system. Often, tasks never share any code except for the operating-system interface, which may or may not be reentrant. Programmers, especially those dealing with device drivers, need to be aware of reentrancy issues.
A plethora of task synchronization mechanisms is out there, from mutexes to messaging systems. From an RTOS perspective, no difference exists between them with respect to synchronization issues, such as race conditions.
The timer tends to be common among microcontrollers and operating systems. Minimally, a timer will be used as a timeof- day clock. But because they’re so useful, they tend to be implemented in a special fashion. The POSIX specification even defines timers as a component. Timers can also provide watchdog support.
In many microcontrollers, a timer can be set up to wake up the system when it’s in sleep mode. Some implementations allow operating systems to use it as a general timer, even though this wakeup feature is independent of the operating system.
Some systems have different types of timers with different characteristics to meet various requirements. Some timers can be synchronized to deliver simultaneous pulse-width-modulation (PWM) streams for motor-control applications. For an RTOS, a single timer will usually provide the necessary support to implement a time-of-day clock as well as providing time-slice support.
Timers also support time slicing. Usually found on time-sharing systems, it gives applications a “fair” amount of time to execute. This type of round-robin scheduling can be implemented for any interrupt level.
Normally, the interval provided by a clock “tick” will be fixed and tasks will be given the same amount of time to execute before being preempted. Of course, this policy is arbitrary and a variety of implementations is possible. For instance, variable time-slice durations would allow time to be allocated on a per task basis, with some tasks receiving more time than others, versus a task priority scheme that would potentially lock out lower-priority tasks.
Many RTOSs feature a fixed scheduler. Others permit replacement or customization, while another segment of RTOSs supports a variety of policies. This flexible approach is what enables operating systems such as Linux to provide real-time support at the same time they’re running a mix of applications in a time-sliced environment. Real-time tasks have a high priority and run before the typical user tasks.
Linux actually has a more complex scheduling system that specifies a task on whether it will relinquish control to another task of the same priority in a roundrobin methodology or continue to run to completion. (For more, see “Hypervisors And Separation Kernels”) Virtualization RTOS platforms like Open Kernel Labs’ OKL4 address this issue.
BASIC COMMUNICATIONS Some texts separate task synchronization and communication, but generally they’re the same thing. It’s just a matter of what information is exchanged. Nowhere is this more apparent than with messagepassing- based RTOS. Here, the messaging system handles all communication with no distinction between communication and synchronization.
Minimally, an RTOS must provide a mutual exclusion primitive, such as a mutex. Everything else can be built upon this primitive. In many cases, as with a message-passing system, the mutual exclusion support is hidden within the operating system. Only higher-level messaging functions are exposed.
Messaging systems have a range of names, from pipes to queues, and their implementations can span from singleprocessor, single-memory models to multicore clustering systems. Enea’s OSE RTOS and QNX’s Neutrino are two mainline RTOSs based on message passing.
Regardless of the approach or API chosen, the communication system must be integrated into the operating system’s scheduler at some level. Therefore, a task can be removed from the active queue if it must wait for an event. Likewise, a task that initiates an event, causing another task to become active, will result in a scheduling action.
Communication, events, and scheduling may be tied to the hardware, something that the RTOS must also handle. Texas Instruments’ DSP/BIOS is an RTOS designed to run on the DSP side of a dualcore system like TI’s DaVinci line. Among other things, DSP/BIOS handles communication between the ARM core and the DSP core.
Reprints
