When do I really need interrupts?

Hello. I’m working on a code which uses some multiplexers, shifters, lcd display, lots of potentiometers, and etc. The code is long, around 15k. I’ve never experienced timing issues, but now with the latest feature I added I’m experiencing problems. Basically it’s a sequencer.
The problem is that when I receive a 5v pulse from another gear, the sequence must start, with the littlest latency possible, < 5ms at worst. Measuring it in the oscilloscope I saw mixed results. Sometimes it started Ok, other times it ignored it, and in the worst case had like 10ms latency.
So I thought it would be time to put an interrupt routine. I read it should be as fastest as possible. I just need to change a variable from LOW to HIGH, just that. If I understood well this should help my problem right? An interrupt is executed as soon as possible when it receives the pulse? Before that I suppose the arduino finishes doing the last task.
After the interrupt routine the code starts again? Or where it was left before the interrupt?
Can I change later in the code(with a switch) the interrupt mode? For example, if button 1 is high, the interrupt mode is FALL, if button 1 is low, the interrupt mode is RISING?
Will try it now, just wanted to have your opinion :slight_smile:
thanks

If the rate at which your loop() function repeats is long enough such that it takes more than 5ms to poll an input then it must be doing a lot, possibly in the wrong way. Using an interrupt to set a flag variable and responding to it in the loop() function is not going to help if you think about it.

When the interrupt occurs it does not wait for the Arduino to finish anything, even if it is the middle of updating a multi byte variable. After the interrupt the program returns to exactly the place where it was interrupted. If this is just after where the value of the flag variable was checked then the program will go through the whole of the loop() function again before the variable is checked again so it can take as long as polling an input on every pass through loop().

What is it in your program that takes the time ? Have you got any blocking code that won't move on unless something happens ? The delay() function is the classic cause of this but some other functions such as pulseIn() can cause code blocking.

You could use a switch to change the mode of an interrupt if you needed to.

I believe interrupts are only necessary if you need very precise timing (in the microsecond range).

If you know how to use them they could be used for a wider range of possibilities. However they can cause problems that are very difficult to debug and my general rule is don't use them unless you know how to do so without needing to ask questions here.

If you do use interrupts make sure that the interrupt service routine (ISR) is as short as possible - 2 or 3 lines of code.

As it's name implies when an interrupt is triggered the Arduino jumps to the ISR as soon as the current instruction is completed and it returns to the following instruction when the ISR completes.

You can change all features of interrupts in code. Just disable the interrupts before you make changes so that it doesn't trigger while you are making the changes.

You say you need accuracy in the 5msec range and I strongly suspect that can be achieved without using interrupts if your code is organized suitably. In particular there should be no usage of the delay() function. Since you haven't posted your code it's impossible to give specific advice.

Are you familiar with the technique in the Blink Without Delay example sketch and with the concept of State machines?

...R

Yeah, thinking it better, it's just like you said, the interrupt wouldn't help. The code isn't blocking anything, there are no delays, just a short micro delay for analogreads. Actually, the code doesn't do A LOT of things, the lcd display refreshes only when I moved a potentiometer, the rest of the code is scanning the switches and do something if the switches changed. That's why I was surprised, the performace it's good, for example, I have a counter with micros which sends midi clock pulses, and they're pretty tight, even at fast speeds like, a pulse every 2ms. I even have a similar part of the code which works fine, when a pulse is received, it outputs the same pulse on an output, there's no important latency at all. I suppose I didn't think correctly the new part, i'll try it other way. Later I post the relevant code thanks