Do not use interrupts in your programming (?)

So I have this project and, even though I'm not an expert on Arduinos yet, I guess I stumbled upon the same problem many people seem to have. I've read a few Forums about complications using Interrupts and most of them are about the same topic and have the same solution. Some in the form of "when I connect this object near my Arduino the interrupt is triggered" or "The interrupt triggers randomly" and every answer goes along the lines of "A not connected pin does not mean LOW" and then goes on to explain why you should disconnect pins that you are not using because of noise.

But this is something I'd never seen, and every forum I could find about a pin signaling, seemingly by itself, was always related to interrupt coding. So I guess I should stick to the KISS rule and just redo my code using digitalRead, even if I have to press a button for a few seconds waiting for the loop to start again and read the signal.

Also, what if I disconnect the pins I'm not using, will the noise caught by the interrupt pin alone still be enough for it to trigger randomly?

If you need to wait a few seconds for loop() to start again then I suggest that your sketch is probably badly written and contains blocking code

1 Like

You should get rid of all those f-ing delays.


There are valid circumstances for using interrupts. Post your code and it will be clear what the best solution is in your specific case.

1 Like

It is a common mistake to think a interrupt will alter the program flow, but it won’t. When an interrupt occurs the ISR ( interrupt service routine ) is run and then returns to exactly the same point in the code as it was when the interrupt took place. So using an interrupt is useless for solving the problem of shorting out delays or the effects of long for loops.

Contrary to your belief we get at least one problem like this every day. And the solution is to use a state machine method when writing your code.


1 Like

a) if one asks for interrupts 9 out of 10 cases interrupts are not really needed
b) if you want to stabilize your digitalRead ... read how to read a pin. Even a INPUT_PULLUP might solve your problem.
c) if you just read your pins in loop and replace your delays() with millis() you will get responsive "buttons" without any interrupt
d) try the "Blink Without Delay" example and learn how to write non blocking code.

1 Like

Thanks you all. I'll get rid of delays. Gosh I love this community.

Do you have a short version, too?

Unresponsive devices make great UX

That is not what interrupts are for!

As a beginner, it is incredibly unlikely that interrupts will be useful to you.

A common "newbie" misunderstanding is that an interrupt is a mechanism for altering the flow of a program - to execute an alternate function. Nothing could be further from the truth! :astonished:

An interrupt is a mechanism for performing an action which can be executed in "no time at all" with an urgency that it must be performed immediately or else data - information - will be lost or some harm will occur. It then returns to the main task without disturbing that task in any way though the main task may well check at the appropriate point for a "flag" set by the interrupt.

Now these criteria are in a microprocessor time scale - microseconds. This must not be confused with a human time scale of tens or hundreds of milliseconds or indeed, a couple of seconds. A switch operation is in this latter category and even a mechanical operation perhaps several milliseconds; the period of a 6000 RPM shaft rotation is ten milliseconds. Sending messages to a video terminal is clearly in no way urgent,

Unless it is a very complex procedure, you would expect the loop() to cycle many times per millisecond. If it does not, there is most likely an error in code planning; while the delay() function is provided for testing purposes, its action goes strictly against effective programming methods. The loop() will be successively testing a number of contingencies as to whether each requires action, only one of which may be whether a particular timing criteria has expired. Unless an action must be executed in the order of mere microseconds, it will be handled in the loop().

So what sort of actions do require such immediate attention? Well, generally those which result from the computer hardware itself, such as high speed transfer of data in UARTs(, USARTs) or disk controllers.

An alternate use of interrupts, for context switching in RTOSs, is rarely relevant to this category of microprocessors as it is more efficient to write cooperative code as described above.

So ...

All that said, the OP apparently refers to spurious triggering of interrupts and supposed problems with floating pins.

There is no reason to believe either that floating pins will cause instability in the microcontroller operation (but they may increase current consumption a little) or that interrupts will trigger at random short of significant impulses being introduced into the system such as by relays, motors or other inductors being switched. In other words, major hardware design errors.

1 Like

Interrupts are necessary when you want low power operation.

I don't think it's good to discourage people from using interrupts. They can be very useful, and may even be necessary to wake up a sleeping processor. But of course interrupt pins should not be left floating. Also, if false triggering occurs, a solution may be to disable the interrupt until it's needed again. For example, in reading a rotary encoder, the ISR for pin A can disable its own interrupt so any bouncing will not produce interrupts, and enable the interrupt for pin B, which should have already stopped bouncing.

I understand that most of the time polling is simpler and works just fine. But I think everybody should know how to use interrupts. It's a very powerful function of every processor, and a coder should know how to use it.

1 Like

No rotary encoders are self debouncing if you make them follow a state machine, there is no need to mess about with disabling anything.

Again no, polling has to take place very quickly at about at least 1K poles per second in order not to miss any transitions.

That, but more often, it's when you need to service time sensitive peripheral devices.

Yes, that method works fine, but it will respond to every bounce transition. It will handle them correctly, but there may be a lot of interrupts to service getting from one detent to the next. If that is a problem, alternating which interrupt is enabled will eliminate almost all of that.

Anyway, my point is that I think beginners should learn how to use interrupts just like they learn to use millis changes instead of delays, and should not be discouraged from using them.

1 Like

I agree; but I think that it's more important that they should also learn when they are appropriate and when not.


:+1:t3: :+1:t3: Yes, I too think that's most important.

I'm with the school of thought that interrupts are appropriate for anything (except bouncy physical buttons) if you have the hardware resource to use.

Another school of thought describes an interrupt as a fire alarm: You pull that as you flee the burning building because there is nothing else you can do except stop everything and immediately call the fire fighters.

Why can’t you cope with bouncing physical buttons?
You simply look at the millis timer to see if enough time has passed before flagging the button press.

However, they aren’t suitable for what the OP wanted to do here. Remember we are supposed to be answering the OP’s question not trying to find fault with other people’s answers. I know it is a temptation but just stick to the question.

1 Like