Polling or Interrupt based method

Question

When should one use polling method and when should one use interrupt based method ? Are there scenarios in which both can be used ?

Answer 1

Always use a interrupt. That way you never lose data. In event driven or threaded applications even the slowest signals should be interrupt driven.

The only time that you should use polling is when you are using a scheduler and the buffers on your hardware are deep enough to ensure no data loss.

Answer 2

Basically, polled mode is used in case interrupt mode is unavailable due to some hardware or software reasons. So, interrupt mode is more preferable from power consumption, performance, etc points of view (agree with Paul R). Polled mode is also can be used at prototyping, for cores without peripheral needed and for some testing purposes.

Answer 3

Here are few interesting links that i came across while analyzing the polling vs interrupt methods - http://web.engr.oregonstate.edu/~traylor/ece473/lectures/interrupts.pdf - Very interesting link http://www.atarimagazines.com/compute/issue149/60_Interrupts_made_easy.php
http://www.electro-tech-online.com/micro-controllers/8440-interrupt-vs-polling.html http://www.microchip.com/forums/m397196-print.aspx http://www.cs.huji.ac.il/course/2006/67630/Lectures/interrupts.pdf http://sunsite.nus.edu.sg/LDP/LDP/tlk/node86.html

Hope this is helpful.

Answer 4

There are many design constraints that can drive the decision. My app has a combination of interrupt and polling:

• External and internal clock sources trigger interrupts - it's critical to timestamp both accurately so we can synchronize them.
• Incoming serial messages trigger interrupts. The recieve FIFOs must be serviced before they overflow.
• Outgoing messages trigger interrupts when the FIFO is partially empty - it must be refilled before it underflows.
• The ISR's set semaphores that are polled for in the background. This has 2 advantages:
  • The computation needed to handle incoming events can be lengthy; if it were left in the ISR it could delay other ISRs beyond their service deadlines.
  • Events can be sequenced. For instance, a polling loop can ensure that calculation X always occurs between ADC data collection and incoming message parsing, even if sometimes the message arrives a little earlier than expected.

Answer 5

the short answer is to use the interrupt method when polling is too slow. (by too slow, I mean if polling loses data, the interrupt method is necessary)

Answer 6

If the event of interest is:

1. Asynchronous
2. Urgent
3. Infrequent

then an interrupt based handler would make sense.

If the event of interest is:

1. Synchronous (i.e. you know when to expect it within a small window)
2. Not Urgent (i.e. a slow polling interval has no ill effects)
3. Frequent (i.e. majority of your polling cycles create a 'hit')

then polling might be a better fit.

Other considerations include whether you are writing a device driver for an OS or just writing bare metal code with no thread support. In bare metal situations the CPU is often just looping when it isn't busy so it might as well be polling something.