Are Interrupts in the Arduino world "prioritized"? In other words, if the CPU is executing the ISR of Interrupt_3, will an Interrupt_1 take priority when it comes along?
Thank you both for the reply, especially Nick's link to his Interrupt Page.
It gave me one question I think I know the answer to; interrupts() and nointerrupts() enables/disables ALL interrupts, whereas attachinterrupt() and detachinterrupt() lets you selectively enable/disable only the pin of interest. It occurred to me I should turn off Interrupt_3 while transmitting or receiving IR pulses since it would seem timing is critical.
//x ************* FUNCTION IRxmt *********************************
// Sends the contents of the array below by modulating at 38KHz
// IrPulses [RAM_SZ][2] pair is high and low pulse
// IrPulses [RAM_SZ][Mark]
// IrPulses [RAM_SZ][Space]
void IRxmt(byte reps) {
unsigned int Mark; unsigned int Space;
detachInterrupt(3);
for (int j = 0; j < reps; j++) {
for (int i = 0; i < RAM_SZ; i++) {
Mark = Output[i][0]; // Read from Output Array
Space = Output[i][1];
TCCR4A |= _BV(COM4A1); // Transmit 38K
delayMicroseconds(Mark);
TCCR4A &= ~(_BV(COM4A1)); // Stop 38K
delayMicroseconds(Space);
}//repeat for RAM_SZ pulses!
} // repeat for reps
attachInterrupt(3, WriteDisplay, CHANGE); // Restore Interrupt
}//--------------------------------------------------------------------------
attachinterrupt() and detachinterrupt() do not enable or disable interrupts they define what should happen, if anything, when the associated interrupt is triggered.
attachinterrupt() and detachinterrupt() do not enable or disable interrupts they define what should happen, if anything, when the associated interrupt is triggered.
Does it not accomplish what I intended? If I detachinterrupt(3) will the processor not ignore a pin change on that particular pin?
If I detachinterrupt(3) will the processor not ignore a pin change on that particular pin?
Yes, but the interrupt will not technically be disabled and will still occur. It's just that it won't have anything to do when it is fired.
Yes, it has been known that once you attachInterrupt an external interrupt will immediately fire. You can avoid that if desired by writing 1 to the appropriate mask, as described on my page and documented in the datasheet.
For making a protected copy of the data from the ISR of an external interrupt is it better to use the detachInterrupt, and attachInterrupt commands for that specific interrupt, or is it preferred to use the global interrupts() nointerrupts() syntax?
I was thinking that if you only detached and attached the specific interrupt there was less likely to be unintended consequences.
From what Nick says, do I understand that if you are using an external interrupt to increment a counter will it increment 1 on attachInterrupt even if there is no triggering signal on the pin? I can not confirm this in my sketches.
First I would use noInterrupts() / interrupts() to protect critical sections as that is less likely to cause grief later if you switch interrupt sources etc. They only take one clock cycle each, whereas fiddling with flags is likely to take longer.
From what Nick says, do I understand that if you are using an external interrupt to increment a counter will it increment 1 on attachInterrupt even if there is no triggering signal on the pin?
No. I think it goes like this: If you have configured external interrupts (say attachInterrupt (0, isr, FALLING) ) then it registers falling signals. Then if you do a detachInterrupt (0) it "unmasks" that interrupt but doesn't change its type. So the processor still remembers falling signals, it just doesn't generate an interrupt. Now if you attach the interrupt again, that remembered interrupt fires (if there was a falling signal beforehand). It's a rather specific set of circumstances, but it certainly does happen.
Using detachInterrupt nearly always creates a race condition. Follow Nick's advice: use noInterrupts / interrupts.