For those criticising the idea of using interrupts for button presses

Projects Programming
1

http://www.electronics-base.com/useful-info/software-related/90-polling-vs-interrupt

So here is one guy that disagrees with you!

Interrupts are more efficient at servicing hardware requests......and a button is an piece of external hardware.

One advantage of using interrupts that I particularly like is that you can precisely control button repeat depending on the mode of the interrupt - FALLING, RISING, HIGH, LOW.

It is less convenient to achieve this via polling.

A) The first method is the simple one - Polling:
In the Polling method, the microcontroller must "access by himself" the device and “ask” for the information it needs for processing. In fact we see that in the Polling method the external devices are not independent systems; they depend on the microcontroller, and only the micro is entitled to obtain access to the information it needs.
The main drawback of this method when writing program is waste of time of microcontroller, which needs to wait and check whether the new information has arrived.
The microcontroller continuously monitors the status of a given device. When the condition is met, it performs the device. After that, it moves on to monitor the next device until everyone is serviced. The microcontroller checks all devices in a round robin fashion.

B) The second method is - Interrupt:
Interrupt is the signal sent to the micro to mark the event that requires immediate attention. Interrupt is “requesting" the processor to stop to perform the current program and to “make time” to execute a special code. Whenever any device needs its service, the device notifies the microcontroller by sending it an interrupt signal. Upon receiving an interrupt signal, the microcontroller interrupts whatever it is doing and serves the device. The program which is associated with the interrupt is called the interrupt service routine (ISR) or interrupt handler.
The “request” for the microcontroller to “free itself” to execute the interrupt could come from several sources:

• External hardware devices. Common example is pressing on the key on the keyboard, which causes to the keyboard to send interrupt to the microcontroller to read the information of the pressed key.
• The processor can send interrupts to itself as a result of executing the program, to report an error in the code. For example, division by 0 will causes an interrupt.
• In the multi-processor system, the processors can send to each other interrupts as a way to communicate.

Here are some examples of interrupt sources on one microcontroller

1

There are many advantages of using Interrupts. The microcontroller can serve many devices. Each device can get service based on the priority assigned to it. The microcontroller can ignore (mask) a device request. The use of microcontroller is more efficient.

Definition of ‘Interrupt’
Event that disrupts the normal execution of a program and causes the execution of special instructions

When interrupt occurs microcontroller saves whatever it is currently doing and executes corresponding ISR code. When this part of code finishes saved data gets restored and programs continues where it was paused by interrupt as ISR didn’t even happened. This is shown on next picture.

2
  1. Number of interrupts is limited
  2. Don't forget to take in account bounce
  3. Don't forget to take in account interrupt overhead
  4. Humans are slooooooowwwwwwww

All in all I still don't think it's worth it.

3

And a nice analogy here for newbies:

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.

4

septillion:

  1. Number of interrupts is limited
  2. Don't forget to take in account bounce
  3. Don't forget to take in account interrupt overhead
  4. Humans are slooooooowwwwwwww

All in all I still don't think it's worth it.

Agreed you are severely limited with interrupts on Arduinos other than Due (and possibly some of the newer ones).

But never the less I tend to use them because it is very rare that I need more than 1 or 2.

5

And an analogy for bounce:
Now you're in a Whatsapp group with 200 people posting Meme's all day and your driving. You get crazy from all the buzzing :smiley:

6

septillion:
And an analogy for bounce:
Now you're in a Whatsapp group with 200 people posting Meme's all day and your driving. You get crazy from all the buzzing :smiley:

Perhaps....but noInterrupts() seems to solve that for me. If I ever get bounce on my buttons....I don't seem to notice it.

7

Than you're that one lucky guy...

And yeah, I'm a guy who has all his phone (sound) notifications off. And I poll my phone as I see fit :slight_smile: Not because someone pushes an interrupt while I'm buzzy. I only turn them on for very important and time critical situations. Some on the micro :slight_smile:

8

As I see it, the problem is that many newbies see interrupts as a get-out-of-jail-free card when they use delay() or other blocking constructs..
They're not.

9

The main drawback of this method when writing program is waste of time of microcontroller, which needs to wait and check whether the new information has arrived.

What is this nonsense ?

Polling does not involve "waiting and checking"

10

GrooveFlotilla:
As I see it, the problem is that many newbies see interrupts as a get-out-of-jail-free card when they use delay() or other blocking constructs..
They're not.

I have not used delay(...) for a very long time.

11

boylesg:
I have not used delay(...) for a very long time.

Maybe the word "newbie" means something different in your language.

12

Hi,

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.

Depends on how important an SMS message is.
That analogy has a problem, you are not able to choose what messages you should attend to immediately.

That is is probably the only need for interrupts, when it has to be answered.

There is even a debounce library to take care of that bit of code when polling.
Tom.. :slight_smile:

13

The idea underlying this Thread completely ignores the difference between techniques that work well in the hands of experienced users and techniques that are better suited to newbies.

When something goes wrong with ISR code a newbie will be in very deep doo-doo.

The analogy with pulling a phone out of a pocket is wrong because the human with the phone doesn't have to pull it out so often that it interferes with him/her doing other stuff. And the Arduino is doing 16 million instructions per second and it might as well be using them for polling as running around in circles doing nothing.

...R

14

Robin2:
And the Arduino is doing 16 million instructions per second and it might as well be using them for polling as running around in circles doing nothing.

Well if you have plenty of idle cycles you don't mind interrupt overheat. If you have lot of computing to do interrupts save you waste of time by checking for once-per-eternity event.

I think debouncing interrupt serviced button is as hard as polled button.
With interrupts you are unlikely to miss the button press.
Even Uno has lots of external interrupts when you use pin change interrupts. You may also "misuse" other interrupts as well - TWI, SPI, Input Capture, timers...
Interrupts in general are powerful tool - learning to use them properly is very valuable skill.
IMHO noobs should be encouraged instead of discouraged to learn to use interrupts...

15

Smajdalf:
IMHO noobs should be encouraged instead of discouraged to learn to use interrupts...

I am not at all against encouraging people to learn stuff.

But the successful teacher is the one who paces his/her instruction at a rate that suits the student.

IMHO debugging needs to be taught before interrupts.

...R

16

Robin2:
I am not at all against encouraging people to learn stuff.

But the successful teacher is the one who paces his/her instruction at a rate that suits the student.

IMHO debugging needs to be taught before interrupts.

...R

Perhaps. But how do you think I learned about interrupts for the first time at a very early stage of my Arduino learning.

I just tried it one day and bashed my way through until it I had my head around it in a general sense.

Of course my technique has become a little more refined since then, even if there is still more for me to learn about them.

17

Robin2:
IMHO debugging needs to be taught before interrupts.

I agree with you on that. I got impression OP thinks people there support polling and discourage using interrupts. I think in lot of applications it does not matter which way is used. But in my previous post I missed the most important feature of interrupts: it can wake up the processor from sleep. When power consuption is important (i.e. battery operated something) you cannot live without interrupts.
So I believe "the right way" is if a noob needs help with buttons show them polling - it is definitely easier. But if someone asks for help with interrupt controlled button and it seems there is a chance they will understand it they should be supported.

18

There was a thread a long time ago, about debouncing interrupts... I'll never be able to find it. But the gist of it is, there is a flurry of interrupts generated by switch noise with an actuation. A straightforward ISR to handle a switch closure can debounce by only handling the first event. But it doesn't block the stream of interrupts that is produced by the stream of edge transitions. So for a few milliseconds, the overhead is much higher than it would be for a polled system, which is able to ignore those transitions by simply waiting. The thread I mention was about disabling interrupts for that debounce period, and I forget how it was done. Depending on what is going on in the main program, the extra business might bog something down unless that change is made.

Interrupts from sensor hardware are rarely as noisy so you basically have one edge transition per event.

19

Smajdalf:
I agree with you on that. I got impression OP thinks people there support polling and discourage using interrupts. I think in lot of applications it does not matter which way is used. But in my previous post I missed the most important feature of interrupts: it can wake up the processor from sleep. When power consuption is important (i.e. battery operated something) you cannot live without interrupts.
So I believe "the right way" is if a noob needs help with buttons show them polling - it is definitely easier. But if someone asks for help with interrupt controlled button and it seems there is a chance they will understand it they should be supported.

Waking from sleep is literally the only reason I can think of to ever activate an interrupt on a button pin, and care still needs to be taken to handle bouncing if you want to trigger off the button's edge instead of level.

Someone else mentioned this before, but pretty much every example I've seen on this board of someone wanting to use interrupts with a button is because they're using delay. Rewrite the code to use nonblocking techniques, and the problem goes away. You can easily drop in code to poll a button or any other UI control. Nonblocking code techniques are much more valuable to learn than interrupt hacks.

20

The key element which seems to be missing from this discussion is "what are interrupts for?".
To which the answer is "to convey to the processor short duration events", like characters in a buffer from an external device that are going to get overwritten in a few microseconds if you don't read them NOW.

Nothing about a switch closure, operated by a human, connected to a processor with a cycle time of less than twenty light-metres, fits this description.