Using Interrupt ... Where ? When ? Pro & Con ?

[BravoV]

I've been following the discussion on topic using interrupt with great interest at this thread -> FPGA Vs µC

A bit of my background, as a hobbyist, I came from Atmel MCU (no, not Arduino)  , and used quite bit of C and very tiny of assembly part just for fun & learning. 

Recently .. arrhhmm actually its almost a year now, I jumped ship into ARM, TI M4F core to be exact, still slow in progress, and during learning, I was in awe with ARM's power, like when I understand NVIC for the 1st time, and was thinking why not just slap in everything using interrupt as its powerful (compared to 8 bit mcus), noob's journey I guess. 

Now reading that thread I pointed, to experience fellows, please, enlighten us noobies like me on using interrupt at mcu, discuss please, like the pro, con, when, where etc .. or never ? 

... preparing pop corn ... 

[Matje]

Recently .. arrhhmm actually its almost a year now, I jumped ship into ARM, TI M4F core to be exact, still slow in progress, and during learning, I was in awe with ARM's power, like when I understand NVIC for the 1st time, and was thinking why not just slap in everything using interrupt as its powerful (compared to 8 bit mcus), noob's journey I guess. 

Now reading that thread I pointed, to experience fellows, please, enlighten us noobies like me on using interrupt at mcu, discuss please, like the pro, con, when, where etc .. or never ? 

Where/when: if you need to react to some event immediately.

Pro: you can react immediately (well, maybe not, that depends).

Con: using too many interrupts enormously complicates things.

An interrupt can occur at any time. If e.g. your program is reading a variable larger than the processors wordsize (i.e. it needs more than one machine instruction to read it) than the value of that variable may change *while it is read*, if the ISR is changing it. Some hardware fiddling may be sensitive to timing, so you need to remember to disable interrupts for it.

ISRs may nest, with priorities, or they may not. Either way, predicting the worst case timing becomes "interesting", and with non-nesting ISR or priorities the "react immediately" thing may practically disappear.

Depending on the actual workings of the program nasty things like dead-locks and race conditions (the "variable changes while read" is an example of that) can occur.

So I say use interrupts when you really need to for hard technical reasons. Don't overuse them, that turns nasty, fast. The human mind just isn't built for dealing with multiple things (potentially) happening in parallel.

[rx8pilot]

Where/when: if you need to react to some event immediately.

Pro: you can react immediately (well, maybe not, that depends).

Con: using too many interrupts enormously complicates things.

An interrupt can occur at any time. If e.g. your program is reading a variable larger than the processors wordsize (i.e. it needs more than one machine instruction to read it) than the value of that variable may change *while it is read*, if the ISR is changing it. Some hardware fiddling may be sensitive to timing, so you need to remember to disable interrupts for it.

ISRs may nest, with priorities, or they may not. Either way, predicting the worst case timing becomes "interesting", and with non-nesting ISR or priorities the "react immediately" thing may practically disappear.

Depending on the actual workings of the program nasty things like dead-locks and race conditions (the "variable changes while read" is an example of that) can occur.

So I say use interrupts when you really need to for hard technical reasons. Don't overuse them, that turns nasty, fast. The human mind just isn't built for dealing with multiple things (potentially) happening in parallel.

+1

I use them for timer overflows and 'emergency' inputs. My projects have a lot of hardware monitoring fault conditions like over-current and over-voltage that rarely occur but need immediate attention when they do. Those sections will trigger an interrupt where the ISR shuts down the offending area of the circuit gracefully and goes on trying to figure out what just went wrong. For buttons, I generally use polling during the TIMER ISR and simply change a flag if the button press is detected. I also have hardware de-bounce so I don't have any debounce code slowing down the ISR.

[KL27x]

I also have hardware de-bounce so I don't have any debounce code slowing down the ISR.

It takes very little bandwidth to debounce buttons. You could debounce 50 button presses in the same total time it takes to do, say, an ADC reading or a simple mathematical calculation. On any reasonable clock speed and with a good code, software debouncing is essentially free, aside from the code space. I don't see this slowing down the ISR. External debouncing can realistically free up internal resources, if you are out of memory, I suppose. But in any higher volume application, it will usually be cheaper to use more microcontroller and save on the external components.

[TerminalJack505]

My opinion regarding the use of interrupts is that you can/will make more complex use of them on less complex systems (=lower-end hardware.)  The complexity will be easier to manage on a smaller system.  You also won't likely have an RTOS to leverage.

Once your system gets complex enough that you employ an RTOS, you will likely use tasks to do much of the processing that you once did in an interrupt handler.  There may still be a related ISR but it will likely just save some data (ADC value, for example) and flag a synchronization object (semaphore, for example) that causes a task to do the bulk of the processing.  Doing it this way makes the system more manageable and flexible.  It also makes it easier to port to different hardware since you'll have a cleaner delineation between hardware-related code (handled by the ISR) and hardware-neutral code (handled by the task.)

Edit: Said "mutex" but meant "semaphore."

[nctnico]

Even with an OS you'll need to thouroughly check if the system can meet its performance specs. You can't do without a proper analysis and testing! Not so long ago I have build an embedded video player using Linux. I did spend some time profiling the software to make sure the software/hardware didn't skip frames and it didn't had to wait unnecessary for things to happen (order of execution).

[Karel]

Interrupts are very important and many times there's no alternative than to use them.

An obvious example is when reading incoming data from a peripheral like SPI/UART.
Even with a hardware fifo of 8 or 16 bytes, it's practically impossible to do this with polling when data arrives at high speed.

The same when you connect an adc to an mcu. If the adc has a built-in clock and a "data ready" output,
the mcu need to act very fast to prevent that the data in the adc gets overwritten by the new sample.
If the adc does not have an internal clock but expects a "convert" pulse from the mcu,
you need to use a timer-interrupt to avoid jitter in the output samplefrequency.

So, despite interrupts can be nasty and hard to debug, they are necessarily used a lot.

[legacy]

interrupts are hard to be debugged if you do not have a true ICE

[hamdi.tn]

i think 8,16 and 32 bit variable are written in 1 operation in 32 bit MCU, so it can't be interrupted and when on other processor try to read it , it will end up with a correct value not half old half new value. am using STM32 a lot, and been asked to prove that , i can't find any information on ST document.

[legacy]

mips is also safe about that, even if mips-R3K is a bit more complex than mips32 about that

[nctnico]

interrupts are hard to be debugged if you do not have a true ICE

Utter nonsense. Just set a GPIO on entry and clear on exit. edit: and check with an oscilloscope / logic analyser.

[dmills]

However you do need to be careful about read-modify-write, as something like x+=y; can turn into a load, an arithmetic operation and a store, an interrupt in the middle that changes x can be lost, obvious but surprisingly easy to miss when writing in C (and the resulting race can easily be a once in 6 months thing).

Interrupts are very convenient in some ways (Sometimes to the point of being the only sane way to do things), but  NEVER forget that they can mess with your program flow almost anywhere.....

Regards, Dan.

[SL4P]

The best thing about understanding and using interrupts is - event driven programming...
(look it up)
Once you've mastered when to use them, your code will make a lot more sense, and functions become called (usually) in a more logical strategy.
I guess it also prompts you to think more carefully about variable scope, factoring and use of functions in general...

[hamdi.tn]

i think 8,16 and 32 bit variable are written in 1 operation in 32 bit MCU, so it can't be interrupted and when on other processor try to read it , it will end up with a correct value not half old half new value. am using STM32 a lot, and been asked to prove that , i can't find any information on ST document.

You may find the answer in an ARM architecture reference manual. If the processor saves the return (from interrupt) address as the next instruction to be executed then that would indicate that the currently executing instruction when the interrupt occured will be completed before branching to execute the interrupt service routine.

If it were possible to get into a situation where a variable is only partially updated by an unfinished instruction execution then the architecture would have to provide a means to detect it. Otherwise it would be chaos. That doesn't happen.

yap i did found the answer ... but i don't quite get what they are trying to say 

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/programming_manual/CD00228163.pdf

-first i do know now that higher priority interrupt will be always be executed even if the processor is handling an other lower priority interrupt ( that explain for me some good unexpected behavior and some weird unexpected behavior )
-i understand that there is some mechanism to prevent multiple access to memory, so the processor will not execute two op on the same memory location simultaneously, but this need to execute some instruction before executing the memory operation. Question is does the compiler add those instr.
-a memory error exception do exist ... so 

[IanB]

The short answer is that all computers are interrupt driven, all the time. The more complicated answer is that on a desktop OS the existence of interrupts is largely concealed and you might never know they are happening. But even then, the hardware interrupts are often translated by the operating system (via device drivers) into "software interrupts", or events, and in your program code you write event handlers to deal with them. For example, in a graphical program when someone clicks on a bit of the screen with the mouse button, a "mouse button 1 down" event is generated and some code somewhere reacts to that in an event handler.

So with this in mind, they way you deal with interrupts depends on how close you are to the hardware. If you are programming a raw microcontroller and you don't have an operating system to manage it for you, then most of your code (all of it?) will be interrupt handlers. You will react to timer interrupts for regular events, and I/O interrupts for irregular events. Your code will look like a collection of finite state machines, and each interrupt handler will change the state of one or more of these machines.

[hamdi.tn]

-first i do know now that higher priority interrupt will be always be executed even if the processor is handling an other lower priority interrupt ( that explain for me some good unexpected behavior and some weird unexpected behavior )

Beginners often don't understand the causes (and ways to avoid) "priority inversion".

they do now   

[BravoV]

High reliability computers, very simple computers, and those with tight or predictable latency requirements tend to be based around polling.

Noted, never realized this important matter. 

[BravoV]

Are there good examples or scenarios, that you just can NOT escape from using interrupt in your previous projects ? Share it please.

Of course, I understand the different scale of complexities, lets make the scope of this topic narrowed to micro-controllers such as 8 bit up to ARM "micro"-controller class, not big powered processor class like the beasty intel cpu in desktop PC or high performance multi cores ARM.

[Brutte]

There are the events that can wait, there are those that cannot, with continnuum of constraints spanning in between.
As it is impossible to service  n events with p<n cores instantly, whole idea is to meet the events' deadlines with limited available resource/s. The known solution is to run-time pick some sequence and process accordingly. You can do sorting with NVIC, you can do sorting with bubblesort() or you can even poll() or roundrobin() if all of the events meet the deadline. The sequence is arbitrary and there are no generic commandments on „Ultimate Sequence” or „Thou shalt not poll on Sundays”.

Mind in a typical real-world scenario it is the event's deadline that has to be met so it is the ret of the event that matters, not the entry. However NVIC (Cortex M) is not able to sort the events/IRQs based on ret of events as that would be harder to implement. Sorting based on IRQ triggering time + priorities scheme only approximates the "deadline sorting" but in most cases it does the job (do not ask me about formal proof). Of course

Code: [Select]

assert(now<deadline);won't hurt at ret.

[mikerj]

Interrupts are very important and many times there's no alternative than to use them.

They can always be avoided, but your hardware might make it impractical.

They could be avoided given suitably designed hardware, but given a single core micro and high bandwidth asynchronous peripherals then impractical can easily become impossible. 

[boriz]

Are there good examples or scenarios, that you just can NOT escape from using interrupt in your previous projects ? Share it please.

It propably depends on how hard the mcu is occupied in your main loop, from having
to poll all sorts of inputs.

Personally i use interrupts where ever I can as I consider polling dirty business, taxing the
mcu when it isn't nessesary.

You might be fine not utilizing interrupts at all on your mcu, but then again you might be
able to get more responsiveness and performance out of your device, utilizing them or even
being able to use a lower priced mcu to do the same for less cost.

High speed UART you definately need interrupt based reception, else you wont be able to
get all the data from the point your polling loop detects reception till the point you read the
data out from the mcu's rx buffer. (that i have experienced myself)

[KL27x]

^ It sure sounds like you are suggesting that resorting to the use of interrupts is indicative of using inadequate hardware from the start. Devices that include hardware interrupts enjoy a pretty huge market.

Polling in a tight loop is efficient if you have a tight and predictable loop. It becomes entirely more efficient to poll with a timer interrupt if your code has significant branches and potential delays in these detours. Your code loop may also be too fast. For instance, u may want a decreased frequency of say an ADC, since each reading draws current.

With interrupts you can decide on your frequency up front, balancing current draw and latency, and adjust it independently from the main code loop. Rather than implementing delays or loop counts in code loop, which will then need to be tweaked every time you alter, edit, add any code. I'm not sure of what this interrupt overhead is, of which you speak. A few extra instructions for the jump and the servicing, is all.

I can not even comprehend NOT using timer interrupts, if given the availability. It would seem downright stupid. It would be like choosing a multicore device and only using one core. Or using a device with a hardware math processor and doing the calculations in the code.

[KL27x]

With a little imagination it can be seen that doesn't need to be the case.

I'll bow out. I don't have enough competency in C to go here. I can't even imagine how C manages to work with any degree of code/resource efficiency without using timer interrupts, itself. Take PWM an output as an example. I can imagine that a compiler could calculate and spit out perfectly calculated and balanced code loops for doing god knows how many things at once. To where all the branches are either the same number of instructions, or the code loop counter will keep tabs on the branches and add everything up. But it seems like that would be somewhat complex and code-inefficient, compared to using timers (or of course a hardware PWM module.)

"Efficiency" is only one metric. Correctness is another.

Who cares about efficiency if it gives the wrong answer? Or - more corrosively - if you aren't sure whether it will always give a correct answer.

OTOH, coding in assembly, I have absolutely no problem with using interrupts and getting correctness.

It seems like all the talk is interrupts vs polling. And in my mind that doesn't even make sense. Timer interrupts are perfect for polling.

[KL27x]

I can totally see how a compiled language can be tricky with interrupts, since interrupts (and the specific problem you mentioned) are often device specific. I imagine compilers screw that pooch, quite frequently.

Prove it. Seriously. You will find it to be extraordinarily difficult.

Oh, I agree on this. Even if my code works as expected, I know there are bugs in there, somewhere. I have maintained complex code for years. But in assembly, the problems you mention are just another potential source of bugs out of a million. And interrupts make many tasks so much simpler to code, the coding (and the debugging) is much easier by employing them. I am more confident in my code when I'm using the tools that make it way, way simpler, shorter, more efficient, and easier to follow.

FWIW, the datasheet (hopefully, not the errata!) should specify which instructions must not be interrupted, and you should temporarily disable interrupts where needed. Things like this would be the least of my worries when coding a project.

I think TerminalJack has an insightful observation:

My opinion regarding the use of interrupts is that you can/will make more complex use of them on less complex systems (=lower-end hardware.)  The complexity will be easier to manage on a smaller system.  You also won't likely have an RTOS to leverage.

Maybe the question is loaded, depending on the application/device/language.

On another note, I'm still having a real hard time understanding how a RTOS operates without timers. It seems to me that the device must be using timers in the background, perhaps just hidden from the user.
Yes, you can easily have as many counters as you want in the code loop, but calculating the total delay with the variety of the code branches would be ludicrous. The clock is most certainly incrementing counters and prescalers and storing and acting on that information very similar to the way timers are implented directly by the user in lower level devices.

[KL27x]

Eli5 me. 

Silicon errata happens so interrupts suck?

But your IDE, compiler, libraries are 100% bug-free by default.

I didn't know we were arguing, let alone insulting each other. But if that's the case:

They can always be avoided, but your hardware might make it impractical.

Well, if you choose inadequate hardware then of course it is impractical! But I already stated that.

You basically said that choosing hardware with interrupts and having to use them is choosing inadequate hardware. You said this in response to an example of using a UART. Why does the UART generate an interrupt, in the first place? Just in case you chose inadequate hardware? And what if power consumption is a priority, and you do not want to run at upteen MHz? Or maybe you want the device to even be asleep and still receive communication?

avoid the interrupt handling overhead

And when you talk about overhead of an interrupt, I wonder if even you know what you're talking about. The resource overhead for, say independently PWMing some output pins using timer interrupt with concurrent, asynchronous processing is almost nothing. Do you imagine that your compiled code loop is going to be anywhere near as efficient as that? It won't be in the same universe. "It's not about efficiency." Ok, then. The interrupt code will also have more bandwidth leftover for concurrent processing. "But it's not about speed, either. It's about "correctness."" Ok, I missed that memo, and I don't think of "overhead" as correlating to "correctness," nor understand why that is the now the discussion. But since we're here, which solution do you think will be more "correct" regarding PWM timing accuracy, while also dealing with asynchronous events (hence the main code loop potentially taking many different branches)?

I didn't receive any notice that this thread was about life-critical proof-able code. If I responded to that question, it was inadvertent. OP asked when/where to use interrupts, and my answer is anywhere it makes my life easier. There are a lot of good examples in this thread.