What is an interrupt handler?

[Adam Y.]

I have seen so much information about how the Picc microcontrollers have interupt handlers. What are they and what do they do?

[Mike Betts]

Adam,

Without getting too detailed, an interrupt is usually a signal to the microprocessor which causes the processor to momentarily halt execution and "call" a subroutine at a specified address.

One of the most popular is a UART (Universal Asynchronous Transmitter/Receiver) for a RS232 communications link. The UART issues an interrupt when it receiver's a character and the interrupt handler takes the character from the UART register and puts it in a queue for use by your program.

After the interrupt handler is finished, it returns to the code where it was interrupted.

Another popular one is a low battery interrupt. The handler saves all your work in temporary files and then initiates a shutdown.

You have interrupts for your hard drive, floppy drive, CDROM, DMA, et cetera. There are also interrupts for a timer to allow multitasking by the operating system.

Interrupts are processed an a priority basis (a higher priority interrupt can interrupt a lower priority).

Hope this short explanation helps.

[Lloyd Burns]

Skip over the next paragraph - goto '2'

'1' - Write your thoughts out and store them, you'll want 'em later. On the PIC's (Microchip's abbreviation of "Programmable Interface Controller"), when an interrupt request is sensed, the program counter, which has the location of the instruction being executed, is saved, and refilled by the PIC with "4", the location at which you've cleverly put a small program which saves the registers, figures out which interrupt has occasioned this call, and the "services" the interrupt with an appropriate action. Then it stuffs the old values back in, and resets the program counter to what it was, and goes on from where it left off. Read your thoughts so you recall them, then Return From Interrupt.

'2' - You cleverly put a jump to a location beyond your interrupt service, so the PIC will jump to an executable program on start-up. Before you go on, service an interrupt by going to '1': remember what we're talking about, and where you came from. Carry on with '3'

'4' - At the risk of hearing from interrupt junkies, if you have a loop in your program which is fast enough that you won't notice the time it takes to act on an arising external condition, you don't NEED to use interrupts if you poll your inputs regularly. Return From Subroutine.

'3' - interrupts are available on demand - meaning you program the PIC to respond to things like internal timer overflows, internal watchdog timer timeouts (same thing-different time reg), change in the state of a chosen input pin, overflow from the count associated with a particular pin; all depending on the model of PIC and how you've designed your circuit. As mentioned, some communication processes are capable of generating interrupts, too. Do subroutine '4', now: remember where you are so you can come back. On return, goto '5'.

'5' - You may have noticed that the interrupt service was little different from a subroutine, except that a subroutine is called during the flow of a program, and you have an idea of what you're doing. Time is not as important, so finish what you're doing, and gosub. In an interrupt, it is important to do it NOW - the delay from int to service is called the "Latency" of the interrupt. Just store everything, service it, recall your "thoughts', and get back smoothly to what you were doing before. You want to make the service take as little time as possible, too, because multiple interrupts are sometimes possible.

[Ian W.]

Do interrupt handlers matter though?

If we could send out data as soon as an interrupt occurred, so the robot reacted right away, it might matter, but if we just have a similar "Get Input, Process Data, Ouptut, Redo" loop, it won't matter when you process a set of data, because it's all outputted at the same time, no?

I can't see having any system better than we did last year, beyond upping the speed and a better language. Beyond that though, it starts to get really complicated, and most teams would get lost, I think, in programming.

[FotoPlasma]

Originally posted by Ian W.
[Ian's post here.]

The original question wasn't about the robot's control system. It was a general question, with reference to PIC microcontrollers.

[Matt Leese]

Originally posted by Ian W.
Do interrupt handlers matter though?

If we could send out data as soon as an interrupt occurred, so the robot reacted right away, it might matter, but if we just have a similar "Get Input, Process Data, Ouptut, Redo" loop, it won't matter when you process a set of data, because it's all outputted at the same time, no?

I can't see having any system better than we did last year, beyond upping the speed and a better language. Beyond that though, it starts to get really complicated, and most teams would get lost, I think, in programming.

In a word, yes. The main advantage to interrupts is that they allow you to immediately process an event that occurs (whether that be a low battery condition or data being ready to read) without having to sit in a busy-wait loop looking for it. This means that you can be doing additional background processing at the same time.

Now, it's possible to implement a similiar system without interrupts, but it's significantly much harder and more complicated. Interrupts make the programming cleaner and easier to use.

The way the controller is set up now, interrupts are useless for the most part because all the data is read in at one point in time. If different sections of data were read at different times, this could make quite a bit of difference.

Matt

[Adam Y.]

Another question should I learn assembly or go with a compiler? I will probably go with a compiler but I don't know which one. I have narrowed it down to:
http://www.basicmicro.com/ProductDet...x?productID=24
http://www.melabs.com/products/pbc.htm

[Matt Reiland]

Here is a free C compiler for the PIC devices, it is pretty nice

http://www.picant.com/c2c/c.html