After laying out the groundwork of the startup code and the vector table in the previous lesson, you’re finally ready to tackle the subject of interrupts. In this lesson, you will learn what interrupts are and how they work.
After laying out the groundwork of the startup code and the vector table, you’re finally ready to tackle the subject of interrupts. In this lesson #16, you will learn what interrupts are and how they work.
Lesson 16 – Interrupts, Part 1: What are interrupts, and how do they work
poll
In a nutshell, embedded programming is all about reacting to events. Even the simple “blinky” code you have used so far was responding to events (the timeout events). So far, this has been accomplished by poll, which means periodically checking the status of some conditions. But polls, especially busy-polling inside a tight loop (like the one in the delay() function), is very wasteful and makes the system unresponsive to other events.
Interrupts: Hardware Aspects
A clever alternative to polling is the use of iinterrupts, which are events that alter the sequence in which the processor executes instructions. Specifically, a processor has dedicated hardware that checks the interrupt-request signal after every machine instruction. If the interrupt-request signal is asserted, the processor executes the special interrupt-entry instruction instead of the next instruction. The actions performed by the interrupt entry depend on the processor. In ARM Cortex-M, the interrupt-entry instruction pushes several registers to the stack (MSP) and loads the PC with the corresponding entry in the vector table [1]. This causes the CPU to start executing the interrupt handler.
Interrupts: Software Aspects
To use the interrupt machinery briefly described above, the software must: (1) configure the interrupt source that triggers the interrupt request and (2) provide the interrupt handler. The video for this lesson shows how to configure the SysTick timer as the interrupt source for the timeout events and how to write the SysTick_Handler to toggle the LED on the TivaC LaunchPad board. You also witness the complete transformation of the program structure from polling to interrupt-driven.
End Notes
Interrupts might seem merely like an incremental improvement, and perhaps they are — in hardware. In software, however, they represent a tectonic shift. This was recognized right from the beginning. For example, the computer science pioneer, Edsger Dijkstra, wrote: “In 1957, the idea of a real-time interrupt created a vision of a program with non-reproducible errors because a real-time interrupt occurred at an unpredictable moment. My hardware friends said, “Yes, yes, we see your problem, but surely you must be up to it…” It was a great invention, but also Pandora’s box.” [2,3].
And so, to this day, interrupts remain Pandora’s box for software developers. They create an entirely new class of concurrency problems. This programming course will discuss some of these problems and solutions. Among others, you’ll learn about: race conditions, the “foreground-background” architecture, real-time operating systems (RTOSes), event-driven systems, and state machines. Stay tuned!
[1] Joseph Yiu, “The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors, 3rd Edition”ISBN: 978-0124080829
[2] Communications of the ACM, “An Interview with Edsger W. Dijkstra,” August 2010, Vol. 53, No. 8
[3] Edsger W. Dijkstra, “My recollections of operating system design,” EWD1303
 Dr. Miro M. Samek is the creator of the open source QP real-time embedded frameworks and the freeware QM graphical model-based design tool. He is also the founder and CEO of Quantum Leaps — the provider of modern embedded software based on active objects and hierarchical state machines as well as tools for visual modeling, automatic code generation, and unit testing of deeply embedded software. Miro teaches the popular YouTube “Modern Embedded Systems Programming” video course on which this article series is based. |
Related Contents:
For more Embedded, subscribe to Embedded’s weekly email newsletter.