To interrupt or not interrupt? That is the question...

[SixRingz]

Hey boys and girls!

I'm looking for opinions on the use of interrupts. Some are pro, some are con. So my questions are: Do you use them? If you do, for what? If you don't, why not?
Wow, that almost rhymed... 

[benji]

if oneday you will be programing an mcu to control a microwave oven,when someone opens the door while its heating then you should interrupt everything and turn it off ..

there are many things that can be done with or without using interrupts ,totally depends on the application

[Rebelgium]

I am pro the use of interrupts.
It is a much better use of the microcontrollers resources.

[hgordon]

I don't use them.  Period.

It is always possible to structure code in polled loops in such a way as to service asynchronous events. Resulting code is much more robust and orders-of-magnitude easier to debug.

Note that I use microprocessors with coprocessing features such as DMA and built-in timers/counters that offload tasks that traditionally required interrupts, and I also have a bias toward multi-processor architectures that can divide tasks up in such a way that nothing requires interrupts.  Though I haven't worked with it, I like the concept of the Propellor processor for this type of approach.

[Webbot]

Surely this splits into two scenarios:-
1. If you are talking about output pins then you can/could control this in your main loop - depending on how much tolerance the output devices have in the signals you send them
2. If you are talking about input pins then it depends on the maximum polling time of your main code (including any interrupts that might happen). So if you are looking for a very short pulse on an input pin then you might miss it (since you are busy processing interrupts for output pins, timers etc).

The decision is made more difficult by the number of potential interrupts and how long it might take to process each one. ie if your mcu spends all of its time servicing interrupts, then it may actually miss some anyway. Hence the need to keep ISRs (interrupt service routines) as small as possible. If the number of interrupts become an issue then consider making your ISR store data in variables (so that it can exit quickly) and then use these variables in your main loop.

[Rebelgium]

Surely this splits into two scenarios:-
1. If you are talking about output pins then you can/could control this in your main loop - depending on how much tolerance the output devices have in the signals you send them
2. If you are talking about input pins then it depends on the maximum polling time of your main code (including any interrupts that might happen). So if you are looking for a very short pulse on an input pin then you might miss it (since you are busy processing interrupts for output pins, timers etc).

The decision is made more difficult by the number of potential interrupts and how long it might take to process each one. ie if your mcu spends all of its time servicing interrupts, then it may actually miss some anyway. Hence the need to keep ISRs (interrupt service routines) as small as possible. If the number of interrupts become an issue then consider making your ISR store data in variables (so that it can exit quickly) and then use these variables in your main loop.

Or use interrupt priority...

[paulstreats]

I use interrupts most of the time. Even when creating thread type application I always use timer based interrupt threads rather than polling based threads. But thats just my way of doing it.

I am also a great believer in using multiple processors etc. But for home use you can easily divide tasks up on several uc's for greater efficiency.

[ALZ]

Hi SixRingz:

"When you say they take time, are you referring to the amount of clock cycles each call to an interrupt takes? (Finishing instruction, push, pop etc)
At my University I've been taught to try keep real-time programs event-driven, which is basically 100% interrupts. I'm not saying you are wrong, just want to learn more! "

You have the right idea but there is still more to it.  First off just to get to the
 interrupt vector location takes an instruction that is 2 cycles. Then you need to do:


;------------ INTERRUPT ISR PROGRAMS ---------------
 ORG 0x004  ; interrupt vector location
 ;SAVE REGS
 movwf w_temp  ; save off current W register contents
 movf STATUS,w  ; move status register into W register
 movwf status_temp ; save off contents of STATUS register
 movf PCLATH,w ; move pclath register into w register
 movwf pclath_temp ; save off contents of PCLATH register

 ; isr code can go here or be located as a call ...
 ;subroutine elsewhere
 PAGESEL CHIPCOMISR
 CALL CHIPCOMISR
 
 ;RESTORE REGS
 movf pclath_temp,w ; retrieve copy of PCLATH register
 movwf PCLATH ; restore pre-isr PCLATH register contents
 movf status_temp,w  ; retrieve copy of STATUS register
 movwf STATUS ; restore pre-isr STATUS register contents
 swapf w_temp,f ;USED SO THAT FLAGS DON'T CHANGE
 swapf w_temp,w ;restore pre-isr W register contents
 ;Global Interrupt are able again by retfie
 retfie ; return from interrupt
 ;--------- END OF interrupt ROUTINE ---------------

If you have more than 1 interrupt it even takes more time. If you allow an interrupt of an interrupt still more time.

"At my University I've been taught to try keep real-time programs event-driven, which is basically 100% interrupts. " 

If you are learning to program on a P.C. no one really cares how much time is wasted.

If you are learning to program on a microcontroller then that would be very poor teaching.

Now before someone says that I said never to use interrupts, that isn't what I am saying. I am saying think before using them; in most cases you can use polling which is many times faster.

[Rebelgium]

You're right ALZ,
but there aren't alot of situations that polling is actually faster than ints.
If you know that the event you are waiting for in your code will only take a few cycles, then I also use polling. But most of the time ints are just much faster...
They may be a bit more advanced programming, but it's better, so I think it's worth it.

[JonHylands]

I don't use interrupts in "application-level" programming, because they are really hard to debug. I do use them at a more "system" level, for things like timers, serial input, A/D processing, and such.

The important thing is to write a base of support code that uses them properly, and then just use that code whenever you write a new application.

As an example of an interrupt I find indispensable, I use one of the hardware timer interrupts to increment a 32-bit counter. That counter is a variable called 'millisecondClockValue', and the timer fires exactly once per millisecond.

That gives me a nice, stable time-base in units that means something to me, to use in any other piece of code. Having a timer like that is especially important when you use finite state machines for programming, like I do, where you can't just do something like delay for 300 milliseconds.

- Jon

[Tsukubadaisei]

I agree with Jon 100%.

[SixRingz]

Well, it's certainly not a black or white, yes or no question that's for sure! In my real-time course we did context switching and the interrupts would be used for timing/scheduling task and that seems to be a suitable thing for an interrupt since a busy-wait solution would not suffice. But I actually never thought about the time a call to an ISR actually takes... I'll definitely keep that in mind now when creating mcu code!

[Admin]

I've only ever needed interrupts for use on encoders . . .


edit: forgot to mention I use timer interrupts for sonar

[JesseWelling]

I use them for anything that has tighter timing requirements that plus or minus 1ms (yes that would mean servos), or any kind of external signal like quadrature. I think busy waits waste processing power in most cases and polling is generally more error prone and even harder to debug than interrupts.

And here is my thoughts on where this thread (and topic?) is going:


But aside from that, It's a case by case thing. I don't think you should over use them, nor dismiss them out right.

[ALZ]

Hi Admin:

I wrote a how to on interrupts; I sent you an e-mail about posting it on your site but didn't get answer back. In the few post here, there has been so much wrong info. give.   

I've only ever needed interrupts for use on encoders . . .

As for timer interrupts . . . I've never needed them . . . I just poll my timer when I need timing data . . . but polling isn't very useful if you require high precision event timing . . .

[Rebelgium]

Hi Admin:

I wrote a how to on interrupts; I sent you an e-mail about posting it on your site but didn't get answer back. In the few post here, there has been so much wrong info. give.  

I've only ever needed interrupts for use on encoders . . .

As for timer interrupts . . . I've never needed them . . . I just poll my timer when I need timing data . . . but polling isn't very useful if you require high precision event timing . . .

Why don't you post your How to here then?

[ALZ]

If I post it on the forum, maybe a hand full of people will see it.  Also it is not a line or two long. If you want to read it it is at: http://robotics.scienceontheweb.net/

Hi Admin:

I wrote a how to on interrupts; I sent you an e-mail about posting it on your site but didn't get answer back. In the few post here, there has been so much wrong info. give.  

I've only ever needed interrupts for use on encoders . . .

As for timer interrupts . . . I've never needed them . . . I just poll my timer when I need timing data . . . but polling isn't very useful if you require high precision event timing . . .

Why don't you post your How to here then?

[dunk]

hi ALZ,
while i agree with the over all point of your article that you have to carefully think about exactly what happens when a microcontroller interrupts before you call one, i disagree with your initial standpoint:

If your program does everything you want it to and does it faster than another program then that program is better.

at work i occasionally have to put together monitoring scripts using other people's libraries. (nothing microcontroller related but the point is the same.)
there are hundreds of people contributing to these libraries and using them.
as long as a task is not too processor intensive the "best" examples of programming are usually the ones that are easiest to use and debug because they are the ones that take the least time to understand and therefore the ones people use.

it is the same when i am writing code for my microcontroller projects at home. if it takes me less time to write the code and it is easier to understand if i have to go back and change it a year after i first wrote it then it was probably the best way to write it.

a lot of the time the code that is easiest to read (and use) is also the fastest and most efficient in CPU resources
but the example you give of calling a microcontroller interrupt in C is a good example of when the compiled interrupt code may in fact be a lot more processor intensive than it's C code would imply.
this may be important if you need super accurate timing loops but a lot of the time it doesn't matter.
if speed of execution was the only variable we would all be writing our code in assembly language.

so to summarise my point.
i would say it's more complicated than just choosing the most CPU/microcontroller resource friendly way of programming.
it is also worth considering whether you are going to be short of CPU/microcontroller resources and if not go for the easiest code to read and write.

i accept there are a lot of purists out there who like counting clock cycles, i prefer to assess code on whether it does what it was written to do.


dunk.

[ALZ]

Hi dunk:

That is why I said "If your program does everything you want it to" If your goal was to write the program fast and get the program out the door and don't care how well it works. Then that was "everything you wanted".  We all know that M.S. rather have the software out the door so it can make money. Then worry about the 100's of bugs later. So if you have two junky programs, the junky one that works faster is still the better program.

[bens]

I think the most important things to know about interrupts are the following:

1) The kind of bugs you get from incorrectly written ISRs are typically far worse than the bugs you get from interrupt-free programming.  This is because they typically result from non-deterministic, difficult-to-repeat interractions between your ISR and your program.  Such bugs might only happen once every 7 hours, or maybe even once every 7 days, so you think you have perfect code and instead you have something that might fail at some critical time.  If you don't think this happens in professionally written code, note that the Arduino code has just such a bug with the ISR that's used to update its millis() counter.

2) Get out fast!  Do not do run long, time-intensive routines from inside your ISR.  Typically other interrupts will not be processed while you are in your ISR, which might cause you to miss an interrupt you didn't want to miss (or if not miss, delay your getting to that second interrupt).  You also need to note that if not explicitly forbidden, your interrupt can insert itself at any point in your main program's execution.  If the interrupt is long, this could potentially severely interfere with your vision of how your program should flow, especially if your program performs time-sensitive operations.  If you need your interrupt to trigger complicated, lengthy actions but can spare some time in the execution of those actions, have the ISR use globals to queue up the action and have your main loop carry out the actions outside of the ISR.

3) Pay attention to non-atomic operations.  An atomic operation is one that can be carried out by a single, uninterruptable instruction.  An example of an atomic operation would be incrementing a byte.  An example of a non-atomic operation that many people might think of as atomic would be incrementing an integer (a two-byte value).  In C this looks atomic, but several machine instructions are required to perform this operation, and an interrupt can happen right in the middle of them.  Where this becomes important is if your ISR writes to a global variable that is read via a non-atomic operation in your main program.  For example, consider the case of an ISR that increments a two-byte variable and a function in your main program that does something with that two byte value.

int foo = 0x00FF;  // global int

ISR()
{
  foo++;
}

void someFunction()
{
  foo++;  // this is a non-atomic operation that can be interrupted in a number of places
}

Reading the global foo requires we first load the low byte from memory and then load the high byte from memory (or we can load high followed by low, but not both simultaneously).  Let's look at the pseudocode assembly instructions for this and consider the case of an interrupt right in the middle:

load low byte of foo into R16   ;R16 now has the value 0xFF
(interrupt occurs now, incrementing the value of foo from 0x00FF to 0x0100)
load high byte of foo into R17  ;R17 now has the value 0x01
increment low byte of foo by 1  ;R16 now has the value of 0x00 (it has overflowed)
increment high byte of foo by 1 if low byte overflows  ;R17 now has the value of 0x02
save R16 to low byte of foo's RAM address
save R17 to high byte of foo's RAM address  ;foo now has the value 0x0200

Now our variable foo has jumped from a value of 0x00FF (255) to a value of 0x0200 (512) just because we got unlucky enough to have the interrupt occur in the one place we couldn't afford to have this particular interrupt happen.  Note that if our assembly instructions were to load the high byte before the low byte with an interrupt in the middle, foo would have jumped from a value of 0x00FF (255) to a value of 0x0001 (1).

When you are using ISRs that change global variables used by your main program, you must watch out for non-atomic operations involving those globals that might be interrupted.  The bugs this can produce can be a nightmare to track down.  If necessary, disable interrupts before the non-atomic operation and re-enable them afterwards.

4)  Any global variable that is changed by your ISR and read by your main program needs to be volatile.  Volatile means that the variable will be loaded from memory every time it is read, and saved to memory every time it is written.  This is important because writing to RAM and reading from RAM can be time-consuming, and compilers will often optimize these operations away if it doesn't think they are needed.  For example, consider the following boring function:

char singleByte;  // a non-volatile global

ISR()  // maybe this happens when a timer overflows or when a button is pressed
{
  singleByte = 1;
}

void anotherFunction()
{
  singleByte = 0;
  while (singleByte == 0)
  {
    // wait here for the ISR to change the value of singleByte to 1
  }
}

What the compiler will typically do to anotherFunction is to load singleByte from RAM into a register (e.g. R16).  The while loop will then involve repeatedly checking register R16 to see if it changes.  When the ISR occurs, it will change the value of singleByte in RAM, but since our while loop is just checking register R16, it never finds out about the change.  What we end up with is an infinite loop that definitely does not do what we want.  By declaring singleByte as volatile:

volatile char singleByte;

We tell the compiler that it should load singleByte from RAM every time we check its value.  This means that every time through the while loop we load singleByte from RAM into R16, so that when the ISR changes its value we will detect the change.

5) If your program has some incredibly time-critical component whose optimization is the main focus of that program, use just one ISR and devote it to that specific time-critical component.  Using other ISRs will potentially delay the primary ISR's execution, thereby increasing your worst-case estimate of performance.  For example, if your goal is to make an RC pulse reader that has an accuracy to the nearest microsecond, your only ISR should be the one that triggers on the rising and falling edge of the pulses.  If you have any other ISRs in your program and you get unlucky enough to be in them when a pulse's rising edge occurs, you will be late in detecting the rising edge and your timing accuracy will be decreased.

6) Interrupts are serious business; do not use them carelessly.  Make sure you know what you're doing and understand how your ISRs will interact with your program.  Make sure the benefit the ISR(s) confers outweighs your sacrificing deterministic program flow and potential readability.

- Ben

[TrickyNekro]

Interrupts are no good... They are well needed in time critical situations like the activation of the second coil in a coilgun when the projectile passes a certain point.... and such...

I used a very simple program with an LCD and a interrupt... it messed the LCD up... not in every interrupt... but it's annoying...

In a robot an interrupt can be used but only when the robot is at a homo-sapiens level of intelligence like a coffee machine let's say
or when something needs critical attention like the level of the battery and such...

When you use interrupts have in mind that everything is interrupted and new data arrive to the micro whatever they are...


Finally, I can't say if I'm for or against interrupts... they are hard to use and need care....

I advice as mentioned above that you do not interrupt when you do something that requires more than one clock circle...
Or else disable them...

Lefteris

[ahab]

I think a lot of this boils down to how much concurrency exists on the machine.

If the programmer is only using one monolithic thread and does not want to deal with inter-thread communication then polling might be the way to go.

but... if you're into concurrency (and I'd say language choice plays a part too, Ada or Erlang) then use interrupts when code needs to be executed based on an event.

Code execution, whether by the ending of a busy-wait loop or the start of an interrupt is still code execution. Neither one is easier to debug or is more static / dynamic / predictable / unpredictable.

Context switches aren't cheap. In a system that has multiple threads going two of them doing polling generate a lot of context switches. If those two threads had instead been programmed to be interrupt based there would be a lot less context switching.

I'm of the opinion that real time and embedded software should be as concurrent as needed, and that interrupts should be used wherever possible.

Bumper sensors, counters that have reached a set limit, finishing of an Analog to Digital conversion....

[JesseWelling]

Bumper sensors, counters that have reached a set limit, finishing of an Analog to Digital conversion....

Servo output timing, PID loops....

I use <a href="Bumper sensors, counters that have reached a set limit, finishing of an Analog to Digital conversion....">FreeRTOS[/url] on all my home projects, with 1ms time-slicing. For stuff like PID, and time sensitive sensor samples.