How Interrupts Work
Here’s where the terms Foreground and Background come into play. We call main() the Background
thread since it is our “default” thread; that is, the program is designed such that we start running main() and
go back to it whenever we’re done with our other threads, such as ISR1.
Whenever an interrupt causes another thread to run,
we call that a Foreground thread. The foreground
threads preempt the Background thread, returning to
the Background once completed.
The words “Foreground” and “Background” aren’t
terribly important. They just try to provide a bit of context that can be visualized in this common way.
It should be noted that it’s important to keep your interrupt service routines short and quick. This, again, is
common practice for embedded systems.
Note: We realize that our earlier definition of “Thread” was a little weak. What we said was true, but not complete. The
author’s favorite definition for “Thread” is as follows:
“A function or set of functions that operate independently of other code – running within their own context.”
The key addtion here is that a thread runs within its own context. When switching from one thread to another, the
context (register values and other resources) must be saved and restored.
How Interrupts Work
Now that we have a rough understanding of what interrupts are used for, let’s discuss what
mechanics are needed to make them work. Hint, there are 4 steps to getting interrupts to work…
How do Interrupts Work?
Slide left intentionally blank…
If you’ve been reading this chapter, you might notice that we’ve already covered these four items.
Over the next few pages we enumerate these steps again, filling-in additional details.
MSP430 Workshop - Interrupts 5 - 7