Interrupts can be scary. They are one of the things that make embedded systems different from traditional application software. Interrupts swoop in from out of nowhere to change the flow of the code. They can safely call only certain functions (and usually not the debug functions). Interrupts need to be fast, so fast that they are a piece of code that is still occasionally written in assembly language. And bugs in interrupts are often quite difficult to find because, by definition, they occur asynchronously (outside the normal flow of execution).
However, interrupts are not the bogeymen they’ve been made out to be. If you understand what happens when an interrupt occurs, you’ll find where they can be a useful part of your software design.
A Chicken Presses a Button
Consider interrupts as a Rube Goldberg machine1 with the goal of telling your software that something happened outside the normal flow of code. Let us consider the chicken in Figure 5-1.
Figure 5-1. A chicken presses a button leading to a cascade of actions ending with the code in the event loop taking an action
The chicken presses a button. The interrupt signal goes to the processor. The processor saves where it is and then looks up what code to call. It calls that code, which does something (maybe sets a variable). The interrupt ends, the processor returns to where it was before all this happened. ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month, and much more.
