Interrupts vs. Polling: What’s the Dif-(Interrupt)-ference?

Welcome back to the Digilent Blog!

 

For those of you that have been coding for awhile, you likely have heard about both interrupts and polling. These are both techniques that can be used to alert your system board, such as a chipKIT microcontroller, when an input has occurred. But what is the difference between these two methods? Is one better than the other? Let’s find out.

 

When working with a chipKIT board, one of the earliest projects that you might do is to set up a circuit so that when you press a button an LED turns on. The way the program knows whether or not you pressed a button is by digitally reading the current voltage state of the pin attached to the button and then appropriately turning the LED on or off. However, by digitally reading, the microcontroller has to constantly check the voltage state on that pin to see what the next action should be (turning the LED on or off). This method of continually checking is known as polling. It can get processor-intensive, though, since the microcontroller is always checking for that change, but it is also an easy way to make sure that as soon as a change happens your desired effect take place immediately after the change.

Is the button pressed? Is the button pressed? Is the button pressed?
Is the button pressed? Is the button pressed? Is the button pressed?

So what about interrupts? An interrupt is also a way to detect if a change occurred within your system, but it does not need to continually check if something as occurred. Rather, an interrupt changes a bit in hardware and causes an interrupt service routine (ISR) to occur immediately, even if the chipKIT board is in the middle doing something else, like printing something to a serial monitor (hence the name of “interrupt”). Typically, the interrupt service routine would set some sort of flag (a boolean) to indicate to the system board that an interrupt has occurred, which the system board would then address more fully once it specifically checks on the status of that flag.

An interrupt happening in the middle of a Serial.print command
An interrupt happening in the middle of a Serial.print command.

But if an interrupt occurs immediately, why not have everything associated with that interrupt be executed as soon as the interrupt happens? In all reality, the answer is you could have everything happen in the ISR. Realistically though, most applications are time sensitive to some degree, so it would be counterproductive to run large amounts of code in an interrupt that is designed to just briefly occur. Additionally, time dependent functions such as delay() will not work inside an ISR, nor would the counter for millis() continue to tick inside the interrupt. Because of this, it tends to be much easier to run an occasional poll within the main to check to see if the interrupt flag has changed in order to keep the system board running smoothly as designed.

The interrupt can be triggered at any time, but only checked at certain time.
The interrupt can be triggered at any time, but checked at a certain time.

So what’s the major difference between interrupts and polling? One analogy would be receiving a text on your cell phone; if you keeping pulling out your cell phone to check to see if anybody has texted you, that is polling. If you instead are going about your day and then suddenly hear your phone buzz (an interrupt), you now know that you received a text (set the interrupt flag) and can then choose to check your phone right then or later when it is more convenient for you.

 

Which method do you use most frequently?

Author

  • James Colvin

    A local Digilent employee who is sometimes tricked into making other content besides documentation and supporting customers on the Digilent Forum, but then I get to write a little more informally so that's a plus. A sassy engineer, lover of puns and dad jokes, father and husband. I know both way too much and simultaneously almost nothing about a number of nerdy topics. If you want to hear me rant, ask me what data rate USB C operates at.

Be the 1st to vote.

About James Colvin

A local Digilent employee who is sometimes tricked into making other content besides documentation and supporting customers on the Digilent Forum, but then I get to write a little more informally so that's a plus. A sassy engineer, lover of puns and dad jokes, father and husband. I know both way too much and simultaneously almost nothing about a number of nerdy topics. If you want to hear me rant, ask me what data rate USB C operates at.

View all posts by James Colvin →

2 Comments on “Interrupts vs. Polling: What’s the Dif-(Interrupt)-ference?”

Leave a Reply to Erisan Cancel reply

Your email address will not be published. Required fields are marked *