0
\$\begingroup\$

Suppose, AVR microcontroller is handling an interrupt. Interrupts disabled. At this time the same interrupt occurs. Will microcontroller handle the interrupt again after return from the first handler?

If "yes", then how can I avoid this? (I want to use INT0 interrupt (on low-level) with a button. But because of bouncing the interrupt can occurs again when microcontroller handle it.)

\$\endgroup\$
0
\$\begingroup\$

In general, interrupts are disabled when the processor enters an interrupt handler, and automatically re-enabled when the interrupt handler returns. (See CLI, SEI, and RETI instructions in the manual for more info).

When the external interrupt is fired, the interrupt flag INTF0 in the EIFR is set to 1. When interrupts are enabled and this bit is 1, the processor enters the interrupt handler. Inside the interrupt handler, this bit could again be set to 1, but the interrupt won't re-occur until after interrupts get re-enabled. You can also explicitly clear this bit to 0 by writing a 1 to the register. If you were inside the interrupt handler, an external event sets the bit, and you clear the bit before returning from the interrupt handler, than the interrupt will not be triggered again.

However, note that you can't actually set or clear INTF0 if you're using level-triggered interrupts -- it just matches the state of the pin at all times. If the pin is low, and interrupts are enabled, it will trigger the interrupt again. The only way to stop that is to disable interrupts (either globally, or by masking off the particular INT0 bit in EIMSK).

\$\endgroup\$
1
\$\begingroup\$

As Jim Paris already pointed out you can explicitly clear the interrupt flag if the interrupt condition was triggered again during the ISR. However, that probably won't help you to properly de-bounce your button. If the execution time of your interrupt handler is shorter than the time you button bounces (what is probably the case), it would just re-trigger anyway.

Another issue you should consider is, that even very short spikes on your input could trigger the "button-event". Since you usually have several centimeters of cable to the button, don't underestimate noise issues (neighboring button for example). Using an interrupt triggered pin for button detection is kind of overkill anyway, but many roads lead to Rome...

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy