Electronics > Microcontrollers

Polling vs Interrupt on MCU

(1/3) > >>

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:

--- Quote from: johnmx on June 04, 2011, 11:24:47 pm ---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.

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version