Safe and structured use of interrupts in real-time and embedded software

While developing embedded and real-time systems, it is usually necessary to write code that handles interrupts, or code the interacts with interrupt handlers. Interrupts are indispensable because they use hardware support to reduce both the latency and overhead of event detection, when compared to polling. Furthermore, modern embedded processor cores can save energy by shutting down when idle, leaving only simple circuitry such as timers running. For example, a TelosB [13] sensor network node drains a pair of AA batteries in a few days by running the processor continuously, but can run a useful application for months if the duty cycle is kept appropriately low. Interrupts have some inherent drawbacks from a software engineering point of view. First, they are relatively non-portable across compilers and hardware platforms. Second, they lend themselves to a variety of severe software errors that are difficult to track down since they manifest only rarely. These problems give interrupts a bad reputation for leading to flaky software: a significant problem where the software is part of a highly-available or safety-critical system. The purpose of this chapter is to provide a technical introduction to interrupts and the problems that their use can introduce into an embedded system, and also to provide a set of design rules for developers of interrupt-driven software. This chapter does not address interrupts on shared-memory multiprocessors, nor does it delve deeply into concurrency correctness: the avoidance of race conditions and deadlocks. Concurrency correctness is the subject of a large body of literature. Although the vast majority of this literature addresses problems in creating correct thread-based systems, essentially all of it also applies to interrupt-driven systems.