Reduce RTOS latency in interrupt-intensive apps

In hard real-time applications such as motor control, failure to respond in a timely manner to critical interrupts may result in equipment damage or failure. As a result, developers of such applications have tended to shy away from use of third-party real-time operating systems (RTOS). However, as communications peripherals such as Ethernet and USB become more pervasive in control applications, software complexity is pushing developers toward greater RTOS use.

In this article, we will examine the potential for an RTOS to introduce greater interrupt overhead when used inappropriately and then describe a practical design technique to bring the benefits of a multithreading operating system to control applications with high interrupt rates.

We will begin by providing a detailed overview of interrupt management inside an RTOS and compare it with how an interrupt might be handled outside an RTOS, including a comparison of overhead for use cases at different interrupt rates.

We will conclude with an illustration, including example code, of a hybrid interrupt-handling approach that greatly reduces interrupt overhead.

Understanding interrupt processing in an RTOS
When using an RTOS, the typical approach for responding to an interrupt involves the RTOS interrupt dispatcher invoking a user-defined interrupt service routine (ISR), which does a minimal amount of work before deferring most processing to another thread such as a task.

The RTOS will usually enable a developer to write the ISR in C since it automatically handles low-level operations, such as context save and restore operations, further simplifying ISR development. In applications where interrupt rates are relatively low, there is little reason to consider deviating from this methodology.

While RTOS vendors highly optimize their interrupt handling code, a commercial RTOS must address a broad variety of applications. As a result, a number of the operations performed by an RTOS may not be needed for a specific interrupt or application. In applications where interrupts are more frequent, developers need to consider whether the impact of RTOS overhead, such context switches, may cause the application to miss real-time deadlines.

Although commercial RTOS vendors provide detailed performance benchmarks that knowledgeable developers can use to determine if real-time deadlines can be met, it's important to fully understand the operations performed by an RTOS when handling an interrupt. It is equally important to understand the different options provided by an RTOS and what design trade-offs have been made, since these can affect interrupt processing times significantly.