Polling vs Interrupt on MCU

[jproject]

Hello everyone,

from your experience, what is better for a MCU? Polling or interrupt? Examples of situations would be great!
Please specify regarding battery life (if there is a huge difference), use of the CPU, effects on the peripherals, etc.


Thank you!

[johnmx]

In general you should use interrupts, but it depends on each situation. The important is to avoid wasting CPU cycles. You can poll some bit, but avoid creating blocking routines. Use state machines for your functions.
If you need a fast response then the interrupts are the best option.

If your design is battery powered then you should put the microcontroller in sleep or idle mode whenever possible. Configure it to wake up on interrupt, but this doesn’t mean it needs to jump to the ISR after wake up. It can simply wake up and continue executing code in the main code. Lower the clock frequency as much as possible and use dual clocking speeds if needed.

The beauty of programming microcontrollers is that the only limitation is your imagination.

One important note in case you use interrupts, simulate your code to measure the time spent to enter in the corresponding ISR. In MPLAB you can use MPLAB SIM. Young players make several mistakes writing any ISR, like calling functions that are also called in main code. This can lead to very slow interrupt routines.

[DrGeoff]

Interrupt driven state machines are all I tend to use in MCU projects.
The ISR's should only be doing minimal things like setting a bit or adjusting a counter. Everything else works in the main loop by testing bits and counter values.

[jproject]

In general you should use interrupts, but it depends on each situation. The important is to avoid wasting CPU cycles. You can poll some bit, but avoid creating blocking routines. Use state machines for your functions.
If you need a fast response then the interrupts are the best option.

If your design is battery powered then you should put the microcontroller in sleep or idle mode whenever possible. Configure it to wake up on interrupt, but this doesn’t mean it needs to jump to the ISR after wake up. It can simply wake up and continue executing code in the main code. Lower the clock frequency as much as possible and use dual clocking speeds if needed.

The beauty of programming microcontrollers is that the only limitation is your imagination.

One important note in case you use interrupts, simulate your code to measure the time spent to enter in the corresponding ISR. In MPLAB you can use MPLAB SIM. Young players make several mistakes writing any ISR, like calling functions that are also called in main code. This can lead to very slow interrupt routines.

Very informative. Thank you!

[Frangible]

Interrupts provide a very powerful way of multi-tasking, and make processing bursty sorts of operations (especially communications functions) much more efficient than continuous polling.  Interrupts are sometimes the only way to code I/O operations when you're working under the supervision of an operating system.  However, some CPUs are not particularly efficient when it comes to context switching, and can waste quite a few cycles just saving stuff to the stack.  Sometimes it's wise to avoid interrupts because of the uncertainty they introduce into operations that may be under extremely tight tolerances.  Tightly coded DSP routines can be adversely affected by the introduction of random interrupts.  Also interrupts can be a real PITA to debug, especially if you're not working with a proper in-circuit emulator.

Checking up on I/O via polling is usually simpler than writing interrupts, as you don't have to contend with all of the headaches they produce.  For small, simple projects, this is usually a good way to go.  You can concentrate on the algorithms and work directly with whatever I/O is necessary.  The bad side to this is that polling code can be very hard to maintain and update down the line, as it usually degenerates into a mass of spaghetti.

What I'm trying to get across here is that there is never a set way of doing things.  Engineering is always a trade - you will never have unlimited resources at your disposal.  Become familiar with the ups and downs of each method and apply them when it seems most logical to do so.

[Mechatrommer]

the OP ask about battery performance. so i'm obligue to give a simple answer. interrupt let your cpu into sleep mode, polling not. thats it. there are many other points, but are already mentioned and i leave to other to answer. it depends on your requirement/application.

[tsmz]

The important thing to remember is that interrupts are function calls. So if an interrupt is triggered, some registers (at least the PC) are usually pushed on the stack and then the ISR is called. After the ISR is done, the PC is popped off the stack again and the program resumes.
This is not fast at all! Polling usually needs fewer cycles to react, so if you're waiting for that one pulse to set off a chain of events as quickly as possible, you'll most likely have to use polling. However, Interrupt efficiency is highly dependent on the MCU's architecture, so you'll really have to go through the datasheet and find out the interrupt performance penalty for yourself.

Interrupts allow for a nicer program flow, though. Polling can easily miss short events if it runs in a loop with actual processing instructions. Interrupts will just inerrupt the program flow, do their stuff and then return. So unless you really want to lock up your program to wait for a specific event, interrupts are much more suitable. Also, interrupts generated by peripherals usually only act on correct and consistent values; some microcontrollers have peripherals with several data registers which have to be read in a specific order to yield consistent data (ADCs come to mind), so if you can use an interrupt for this situation, I'd recommend you do (unless you really know what you're doing).
Polling will also waste power. With polling, the MCU is actively waiting for a signal. You can't enter any low-power modes. Depending on the microcontroller, most are happy servicing interrupts while the main CPU is in a low-power mode--do note, however, that handling interrupts while the CPU is in a low-power mode will take even more time because the CPU has to wake up first.

So, in short: Generally use interrupts, but remember that polling can be more suitable if you need to be extra fast.

[xygor]

Interrupts for low latency, polling for high throughput.  If the required processing volume varies, use both and switch modes as needed.

For one example see:
http://www.linuxfoundation.org/collaborate/workgroups/networking/napi

[ejeffrey]

The important thing to remember is that interrupts are function calls. So if an interrupt is triggered, some registers (at least the PC) are usually pushed on the stack and then the ISR is called. After the ISR is done, the PC is popped off the stack again and the program resumes.
This is not fast at all! Polling usually needs fewer cycles to react, so if you're waiting for that one pulse to set off a chain of events as quickly as possible, you'll most likely have to use polling. However, Interrupt efficiency is highly dependent on the MCU's architecture, so you'll really have to go through the datasheet and find out the interrupt performance penalty for yourself.

This is only true if you aren't doing anything while waiting for the event.  A polling loop is indeed the fastest way to respond to a single event, but as soon as you put other code in your idle loop the latency advantage goes to the interrupt.

Interrupts are also the hands-down winner if you need to make sure you don't miss short duration events, or if you care about power (because you can usually power down if you have nothing to do, and interrupts will wake the MCU).

Another application where polling is appropriate is something like keyboard/keypad scanning.  If you have a huge number of slow inputs, especially if they need software debouncing, scanning/polling can be easier than interrupt driven code.

[johnmx]

Another advantage of interrupts is the constant latency time. This is not true for polling.

[RayJones]

Using interrupts to maintain a data stream is a sensible use. eg a UART pumping data and similar.
Likewise collecting data for later bulk usage is another use. eg FFT analysis which requires consistent sample intervals.
ie interrupts are best used to sustain a background process that requires minimal input from the foreground application.

Using interrupts to set a flag that is polled later - hmmm, not so sure that is so sensible unless the interrupt is doing something more useful. You may as well just poll and be done with it.

Using polling to keep a high speed task up to speed is sensible, but it goes without saying that you must turn off interrupts if the high speed timing is critical.

At the end of the day, you must decide what is most appropriate for the task at hand.

[mikeselectricstuff]

Using interrupts to set a flag that is polled later - hmmm, not so sure that is so sensible unless the interrupt is doing something more useful.

This is pretty much standard practice. A good rule is to do as little as possible in the interrupt code, to minimise latency for other interrupts, as well as reducing the amount of code in which nasty bugs can creep in.

You may as well just poll and be done with it.

Not really - purpose of the interrupt is to ensure that latency-critical things are serviced promptly, while allowing the foreground task to have a much longer latency. The interrupt task and does only the things that absolutely need to be done within that time.
A good example is serial receive - the interrupt task puts each character in a buffer, and when a complete message is received, it does a buffer swap and sets a flag when a complete message has been received. It would also typically handle low-level error conditions like framing errors to avoid bothering the foreground task.
The interrupt guarantees the 1 character maximum receive latency, but the foreground task only has to have a 1 message time latency.

This becomes increasingly important where there are multiple  interrupt sources, as it becomes very hard to guarantee low latency on all interrupts if one interrupt routine takes a significant time to complete.

Of course every application is different and sometimes you need to do things differently to meet system performance/cost requirements - I recently did an AVR design which had about 4K of unrolled loop code in the interrupt code and almost nothing in the foreground task.

[RayJones]

Why go to the trouble of an interrupt routine if all you are doing is setting a flag and doing NOTHING else?
The existence of the ISR is actually more code that can go wrong and totally unnecessary, and can indeed stress the stack limits on smaller MCUs.

Most MCUs can still capture an interrupt event and register it in internal registers without actually generating an interrupt.
If all you wish to do in the foreground is react to a flag, then you can poll the interrupt registers and leave interrupts disabled. In fact this is a handy technique if the signal you wish to capture is of short duration and actually requires a fair bit of work, but is not needed to be acted upon within a few microseconds.

The example of serial receive is above and beyond the simple setting a flag I was disputing, and is in fact what I was exactly recommending interrupts for.
Congratulations of your ability to take my quote totally out of context. 

[ejeffrey]

Why go to the trouble of an interrupt routine if all you are doing is setting a flag and doing NOTHING else?

If you really do *nothing* else, then it is a bit dubious but even so it may be the best way to implement edge triggered events.  Polling can miss short events or multiple events in rapid succession.

Most MCUs can still capture an interrupt event and register it in internal registers without actually generating an interrupt.
If all you wish to do in the foreground is react to a flag, then you can poll the interrupt registers and leave interrupts disabled. In fact this is a handy technique if the signal you wish to capture is of short duration and actually requires a fair bit of work, but is not needed to be acted upon within a few microseconds.

Well, yeah.  If your MCU has a built-in capability to set a flag based on an interrupt input there is no reason to re-implement that yourself.  Unless you need to take some special action if a second interrupt is triggered before the first one is checked... or anything else that your MCUs built-in functionality can't accomplish.

But I think it is fair to say that in all but the simplest examples you are usually doing slightly more than setting a flag.  Incrementing an event count, putting a received character into a buffer, checking for overflow and throwing a tantrum... that sort of thing.

[codepinger]

It depends on your application.

I was once coding for a TMS320C6201, and needed to perform a FIR filter multiple times as efficiently as possible.
Due to the parallel architecture, this can be reduced to a single line loop, but that requires serious preloading of the processor's pipelines to allow such operation.
An interrupt during this single line loop would have flushed the cached data and be disatrous. The need for throughput in this case out ruled the use of interrupts, and thus the design used polling.

You can of course disable interrupts for such sections of code, but then predictable latency is no longer true.