Performance is a topic that never strays far from the mind of most embedded systems developers. However, relatively speaking, many of us have it easy. We develop soft real-time systems in which a few extra microseconds, or even milliseconds, of delay in responding to an event are not a cause for concern.
There are plenty of other developers, though, who don’t enjoy this sort of luxury. Industrial control projects are an application area where hard real-time requirements are very common. For developers in this area, especially those whose work involves motor control, the microseconds that some of us take for granted can be of vital importance.
In order to meet tight response times, it can be necessary for industrial control engineers to make compromises that would otherwise seem absurd. Some engineers that make such design decisions have a tendency to avoid the use of a real-time operating system (RTOS). While, in many circles, an RTOS is viewed as an efficient software platform for writing multi-task application code, it is not uncommon for developers to forgo an RTOS because of its perceived overhead and, in particular, its impact on interrupt latency.
Interrupt latency basics
Why have RTOSes, despite their “real-time” label, acquired this negative reputation amongst certain embedded systems developers? To answer this question, we should first briefly review the concept of interrupt latency.
Though interrupts can be described as a means of immediately responding to hardware events, the transition from an event to execution of the code servicing that event is certainly not instantaneous. Every interrupt service routine (ISR) in a given system experiences some degree of delay, or latency. As Fig. 1 shows, this latency can be divided into hardware and software components.
Fig. 1: Hardware and software both impact interrupt latency.
Hardware interrupt latency typically reflects the time needed for operations, such as completing the current executing instruction in the CPU, locating the address of an interrupt handler, and saving all of the registers — operations that, for the most part, are out of developers’ control. And, of course, it is affected by the CPU architecture. Software latency, on the other hand, is predicated on a system’s interrupt-disable time and the size of that system’s ISR prologue — the code that manually saves registers and performs other housekeeping operations prior to the start of an interrupt handler. In application code at least, developers are often able to limit these quantities and thereby reduce their system’s interrupt latency to an acceptably low level.
The equation changes somewhat if an RTOS is used. An RTOS will often have its own ISR format — including a prologue, as well as an epilogue — and, perhaps more importantly, will incorporate numerous critical sections of code during which interrupts are disabled. The critical sections represent an additional source of interrupt latency for any system that would otherwise have a zero-interrupt disable time.
Certainly, to facilitate adoption of their software, RTOS developers try to keep critical sections as brief as possible and to minimize the number of these passages of code. However, this can be challenging work, since any RTOS variable or data structure that has the potential to be accessed in an ISR (through an API call, presumably) must be protected with a critical section in order to avoid race conditions. Even in efficient, well-written RTOSes, the longest critical sections might exceed the allowed bounds for a hard real-time control system.
The interrupt latency issue leaves developers of such systems in a difficult position, since an RTOS can confer a number of benefits. Despite any overhead that it may impose, an RTOS is ultimately a tool for efficient CPU utilization. Developers who leverage an RTOS have a portable, multi-task software platform that can be maintained and expanded with relative ease.
The zero-added interrupt latency RTOS
There is, fortunately, a means of eliminating the interrupt latency imposed by an RTOS, and it turns out to be quite simple, provided that the RTOS is running on a processor equipped with sufficiently configurable interrupt hardware. The idea behind the approach is that disabling all of a system’s interrupts during RTOS critical sections is unnecessary if only a portion of the system’s interrupt handlers have the potential (again, through API calls) to access RTOS variables. Instead of using a global interrupt disable and enable, RTOSes taking this approach simply update an interrupt priority or level register at the start and finish of critical sections, assuming that the underlying processor indeed offers such a register. Pseudocode illustrating this approach is shown below. (Note that this is a relatively simplistic implementation that would not support nested critical sections.)
#define CRITICAL_ENTER() set_int_prio(5)
#define CRITICAL_EXIT() set_int_prio(0)
void RTOS_function (void)
{
CRITICAL_ENTER(); /* Increase priority */
Access RTOS variables;
CRITICAL_EXIT(); /* Return priority to low level */
}
For the priority adjustments to work as intended, application developers using an RTOS that employs this technique for critical sections must prioritize their interrupt handlers according to the scheme illustrated in Fig. 2 . The highest priorities in this scheme correspond to handlers that do not make RTOS calls and do not depend on any RTOS services. These handlers (sometimes known as “non-kernel-aware” ISRs) are given priorities exceeding the level associated with critical sections, so they should never be delayed by the RTOS.
Fig. 2: The highest priority interrupts are never disabled by the RTOS.
Following the “non-kernel-aware” handlers are the “kernel-aware” ISRs that are able to take advantage of RTOS services. An interrupt controller used to implement this prioritization scheme would be expected to prevent the “kernel-aware” ISRs from executing during critical sections. Thus, the interrupt latency for these handlers would exceed that of the “non-kernel-aware” routines. The trade-off is that the lower priority handlers can invoke RTOS APIs to, for example, signal one of the tasks that lie at the bottom of the prioritization hierarchy.
Hardware and software support
Manipulation of priorities with the objective of establishing critical sections is not possible with all interrupt hardware, or all microcontrollers/processors. However, prioritized interrupt controllers have become the norm on modern 32-bit MCUs, and many of the hardware platforms currently being selected for industrial control projects are outfitted with highly configurable implementations of such controllers. This means that developers of hard real-time systems who once avoided RTOSes now have the option of bringing efficient multi-tasking capabilities to their projects. For example, most or all ARM Cortex-M-based microcontrollers and Renesas RX series devices work well with this interrupt scheme. The required resources amount to little more than a prioritized interrupt controller with a means of adjusting priority levels in software.
In deciding which particular RTOS to leverage for such capabilities, developers must proceed somewhat cautiously. Latencies in the nanosecond, microsecond, and millisecond ranges could all, conceivably, be construed by RTOS providers as “low,” but a prospective RTOS user who has operational speed requirements might take a different view.
Two RTOS examples are Micrium’s µC/OS-II and µC/OS-III. Both have a lengthy history of use in industrial control systems and support the critical section format described in this article. They are two viable options for developers hoping to bring the powerful multi-tasking capabilities of an RTOS to bear on the challenges of hard real-time systems in industrial designs.
Advertisement
Learn more about Micrium
