When is it a good idea to use hardware interrupts?

In my hardware (computer) organization course, I’ve learned that the processor (and therefore the pipeline of instructions with which it processes) gets interrupted whenever data is received from peripheral devices.

I don’t exactly know what happens when the processor gets interrupted but I venture to guess that if we were to think of the computer as a system that operates on user input (as a general-purpose computer isn’t “autonomous” per se) then whatever information we input to the general computer, it must process immediately in order to complete the task the user issues (effectively doing “useful” work; can you imagine if whenever you left click on a mouse, there is the possibility that computer responds with the message "nope, don’t care that you’re trying to open this folder, I’m busy reading through a pdf :smiley: ). Hence, the interrupt gives the highest priority to information provided by the user.

Being so powerful, is there a guideline for when (and when not) to use interrupts? Are processor units the only component of a system that can be interrupted?

You have a slightly misguided sense of interrupts.

A hardware interrupt does exactly what it says, it interrupts the code for a second while it does its job. WHen it is done, the code goes right back to what it was doing. It is imperative that interrupt handling routines (ISR) are very very fast and take a few microseconds at most to run. This way, it all happens so fast the user never knows there was an interruption.

So the answer to when is it appropriate? Well, they are appropriate only for very fast things that might get missed. A signal pulse that only lasts for 30us or something of that sort. The routines that service them should be very fast. If there is any processing to do then let the ISR set a flag and let the main program find time for the processing.

They are also appropriate for things that must be timed exactly. A clock pulse that must happen within a 20us window or something like that might need a timer interrupt. But again, the service routine must be very very fast. Set a pin and get out.

I don't exactly know what happens when the processor gets interrupted but I venture to guess

Don't guess - LOOK IT UP!

that if we were to think of the computer as a system that operates on user input

Wrong. The computer does what ever it is programmed to do. Humans just don't matter.

(as a general-purpose computer isn't "autonomous" per se)

Wrong. The computer does its own thing. Ditch the philosophy.

then whatever information we input to the general computer, it must process immediately in order to complete the task the user issues (effectively doing "useful" work;

Wrong. Humans are slow so slow they get very low priority!

can you imagine if whenever you left click on a mouse, there is the possibility that computer responds with the message "nope, don't care that you're trying to open this folder, I'm busy reading through a pdf :D ). Hence, the interrupt gives the highest priority to information provided by the user.

And again wrong. Oh and mouse clicks/movement and other human interface devices are normal dealt with by polling not by interrupts.

Mark

Mark

holmes4: Oh and mouse clicks/movement and other human interface devices are normal dealt with by polling not by interrupts.

Maybe at the OS level - but deeper in the bowels of every computer system, interrupt mechanisms are responsible for handling peripheral requests:

http://en.wikipedia.org/wiki/Interrupt_request_(PC_architecture)

http://en.wikipedia.org/wiki/Interrupt_handler

ElusivePi: I don't exactly know what happens when the processor gets interrupted

You use interrupts to detect or service events which can occur at any time.

For example, imagine you had a large loop that checked, say, 1000 pushbuttons to determine if one was pushed.

Well, what if someone quickly tapped "button 10" while the code was scanning higher number buttons (say, buttons 25 to 80 got scanned in the time it took to tap button 10). The press of button 10 would get MISSED!

Now, imagine different code. Wire all the buttons to an interrupt input. Now, when any button is pressed, it triggers an interrupt service routine (code that runs when an interrupt is received). That code knows that SOME button was pressed, and it checks to see WHICH button was pressed and places the result somewhere (maybe an external volatile variable).

You see the difference? The interrupt method can NEVER miss a button.

Now granted that was a rather absurd example (you wouldn't really wire 1000 buttons to an interrupt pin) but it explains the IDEA.

Make sense?

Krupski: Now granted that was a rather absurd example (you wouldn't really wire 1000 buttons to an interrupt pin) but it explains the IDEA.

And even if you did, I'd still bet you can check all 1000 of them faster than a human can press and release a button.

I'm in line with Krupski.

If you know that random (in time domain) events will happen, and you want to service it, you must have a way to do it, not losing track of the main code executing at any time.

As said earlier, the interrupt handler routine ("interrupt subroutine") will usually only set an event flag, to let your code know at some place, that it will have work to do for the interrupt event.

This is usually done in an if statement, which lets you traverse a block of code in your program. Or it may call an external function ("subroutine").

The idea is that the interrupt should be acknowledged at once, at any given time, but hey, wait a second, I dont have time right now, you have to wait until its your time in my work qeue

Another way to answer the orginal question ...

If you know how to write code for handling interrupts (i.e. if you know how to make it work without needing to ask advice) then you can use interrupts whenever they seem convenient.

If you don't know how to write code for handling interrupts DON'T use them unless you have to. You probably would have no choice but to use an interrupt to + detect something that has a very short duration (a few microseconds) + detect things that repeat quickly (more quickly than 1000 per second) + accurately time when something happens (accurate to a few microseconds)

As someone else has said things that happen at human speeds can easily be detected using polling. An Arduino can check the value of an I/O pin hundreds or thousands of times per second without using interrupts.

Also, while interrupts are useful and essential in certain cases, the extra behind-the-scenes code to divert the CPU from what it was doing, and then redirect it back to its original task, actually makes the interrupt process slower than polling. There is a price to pay for the extra responsiveness.

...R