Sorry for the Interruption
We exist in a world where we try to shy away from
interruptions — we teach our children that it’s rude to
interrupt; we become frustrated when colleagues interrupt
us and disrupt our thought processes. In short:
Interruptions are bad.
Many years ago, I was lucky enough to spend a
couple of years working as a guide at a luxury safari lodge
in South Africa, where interruptions were an integral part
of life. A herd of zebra would be “interrupted” by the
sudden arrival of a pride of lion, and my conversations
with my guests would be “interrupted” by a rustling in a
nearby bush. At dinner around a roaring fire, our chef
(who was from a local rural community) would arrive and
loudly declare “Sorry for interruption” as he prepared to
announce the menu for the evening — an interruption that
our rumbling stomachs always welcomed!
The point I’m trying to make is that sometimes
interruptions are useful and require your immediate
attention — particularly when we’re dealing with the world
of microcontrollers. This month, we’ll be interrupting our
microcontroller ... and without any apology at all!
Just What is an Interrupt?
An interrupt is, simply, a way to pause what your
microcontroller is busy doing (or not doing, as is likely the
case) and focus it on a task that needs attention. If your
background is similar to mine (originally software
development), you could (kind of) think of an interrupt as
the hardware equivalent of an event in event-driven
When an interrupt fires, the MCU drops what it’s busy
with and dashes off to process the urgent task that the
interrupt triggered — this task is contained in a function
called an ISR (Interrupt Service Routine). When the ISR
has completed execution, the MCU picks up where it left
As an example, you might want to use an interrupt to
handle an emergency button that shuts a motor down.
You don’t want to wait until a sequence of flashing LEDs
have completed their choreography — you want to action
the button-press immediately before you start losing
fingers in machinery! Once your fingers are safe, then the
LEDs can carry on with their blinking.
You may have used interrupts when working with
Arduino boards in the past, through the Arduino IDE’s
(integrated development environment) built-in interrupt
management functions: attachInterrupt(), detachInterrupt(),
interrupts(), and noInterrupts(). These functions control the
interrupts that we most commonly think of when we hear
the term: those triggered by I/O pins. However, these are
not the only types of interrupt. Let’s take a quick look at
the other types we can access on our microcontroller now
that we’re moving beyond the Arduino.
I/O interrupts are those triggered by — not surprisingly
— the I/O pins on the microcontroller. There are two types
of I/O interrupts on the ATmega328P: external interrupts
and pin change interrupts. This might start to sound rather
complex, but bear with me — it really isn’t.
Pin Change Interrupts are the simplest: Each I/O pin
on the microcontroller can trigger an interrupt when it
toggles (i.e., goes from low to high or from high to low). If
you refer to the pin configuration diagrams, you’ll see that
each pin has a PCINTxx associated with it. Figure 1
These PCINT numbers are what we use to configure
and handle the interrupts. Although each pin can trigger
an interrupt, the pins are grouped into three “banks,” with
26 July 2015
Please DO Interrupt Me
Sometimes interruptions can be a
good thing. This month, we look at
how to handle interrupts in your
Atmel AVR embedded projects, and
how they can make your projects
more efficient and easier to develop.