What is an Interrupt?

This article contains a good graphic. Keep in mind that an interrupt will occur at any time, even in the middle of reading or writing data.

Background Discussion

In the embedded systems world, the most thorny problems are related to software preemption. At bottom, preemption is provided by some form of interrupt. An interrupt is an event which steals the processor from the running program. An interrupt can occur at any time. This behavior will expose every weakness of a system design. The resulting defects are very resistant to problem solving analysis and have one or both of these characteristics:

• the defect occurs very rarely and can not be repeated!
• the defect completely crashes part or all of the system, destroying most evidence of its cause!

So, why use interrupts? There are some things for which interrupts are the perfect solution. An interrupt is a good solution in a system when:

• the system must not miss an event and respond to it within a short time.
• the triggering event can not be reliably predicted.

A typical (and common) use of interrupts is in any system where the processor must handle 2 or more external, independent events. Devices like hard disk drives, printers, displays and network connections always place strict service demands on a processor. These requirements are stated in terms of maximum response time or latency. Failure to meet such a demand usually results in loss of data and in some cases, recovery from the failure involves re-starting the transaction. An example of failure is a lost button press on a remote control. In that case, the user bears the full cost by having to press again!

Aside: Sometimes Polling is Faster Than Interrupting

When a sequence of events occur at a rate higher than the interrupt system can handle, an alternative is to use a tight polling loop to handle each successive event. The critical constraints are:

• total interrupt time = interrupt latency + interrupt service
• total polling time = loop overhead + condition service

If this comparison becomes necessary in your design, you might need a faster processor or some external hardware device to do the work.

Specific Example

In our class labs, we will use a delay routine to blink a light-emitting diode (LED) once per second. If this were all we needed to accomplish the delay routine is acceptable. However, as soon as we attempt to perform another task alongside the blinking LED, the delay routine gets in our way. The delay routine is called a busy-wait and while the processor is busy waiting it is unable to do anything else. Fortunately, our μC gives us a timer which we will use to do the waiting and an interrupt system to tell us the wait is over.

Purpose of an Interrupt

An interrupt is used to achieve all of the following:

• ensure the quickest possible response to an event.
• keep the burden of responding to a minimum. In other words, the overall throughput of the system should be virtually the same as if the event happened at the most convenient point!
• never corrupt any other data or ongoing calculations.

An interrupt process consists of 3 steps:

1. enable the event,
2. connect the event to a piece of software called an interrupt service routine (ISR), and
3. in the ISR, handle the event lightly by deferring as much of the work as possible to normal, ongoing software.

How to Create a Good Interrupt Service Routine

The secret to making interrupts work for you is to use the KISS principle (Keep It Simple Stupid). Because the ISR can run at any time, it must not manipulate data belonging to any ongoing software. The best technique to meet this condition is for the ISR to own its own data and for other software to have read-only, atomic access to it.

In most cases the ISR simply records the interrupting event by setting a Boolean flag (ideally a single bit) and nothing more. The mainline code periodically, at a convenient time, tests the Boolean flag and performs the necessary work. The Boolean flag must be implemented (by hardware) as something which can either be read or written by a single processor instruction.

If the ISR modifies a more complex data structure, then the mainline code must use mutual exclusion so that only itself or the ISR has access to the data at the same time.

In the class we will illustrate this situation with specific examples. But, this is one area where a solid understanding of the theory can keep you out of a lot of trouble.