next topic »

[on:]

I know that if I put one of the two interrupts on my uno set to LOW it will fire over and over again as long as that pin stays LOW.  When it returns from the ISR, does it execute an instruction from the main code before it goes back into the ISR again?  Or will it freeze the main program and run the ISR like a loop?

[Reply #1 on:]

I know that if I put one of the two interrupts on my uno set to LOW it will fire over and over again as long as that pin stays LOW.  When it returns from the ISR, does it execute an instruction from the main code before it goes back into the ISR again?  Or will it freeze the main program and run the ISR like a loop?

I believe it guarantees that one instruction in the main code will be allowed to execute before reissuing the interrupt. The datasheet for the specific AVR chip is of course the official reference for such information.

Lefty

[Reply #2 on:]

I know that if I put one of the two interrupts on my uno set to LOW it will fire over and over again as long as that pin stays LOW.  When it returns from the ISR, does it execute an instruction from the main code before it goes back into the ISR again?  Or will it freeze the main program and run the ISR like a loop?

Yes, in case of AVR processors, when an Interrupt Service Routine(ISR) finishes at least one opcode of the code execute before any other ISR is serviced.

RETI
ONE OPCODE AFTER RETI

LOW it will fire over and over again as long as that pin stays LOW

Yes, but most probably 1/3 of them will be lost.

[Reply #3 on:]

It's a bit more specific than that. If interrupts are enabled by an instruction, and they were previously not enabled, the processor will execute one more instruction before handling any interrupts.

So for example:

Code:

  cli ();
...
  sei ();
  sleep_cpu ();

The sleep_cpu() call is guaranteed to be executed, even if interrupts are pending.

Executing a RETI instruction usually is one of the cases of enabling interrupts.

Yes, but most probably 1/3 of them will be lost.

A LOW interrupt is not queued, and thus nothing is lost. Either the interrupt condition is present (ie. the pin is low) when the interrupt is being tested for, or not.

[Reply #4 on:]

A LOW interrupt is not queued, and thus nothing is lost.

Correct, i got it.