PinChangeInt
---- RELEASE NOTES ---
Version 2.13 (beta) Mon Nov 12 09:33:06 CST 2012
SIGNIFICANT BUGFIX release! Significant changes:
- PCintPort::curr bug. Interrupts that occur rapidly will likely not get serviced properly by PCint().
- PCint() interrupt handler optimization.
- PCIFR port bit set bug fix.
- Many static variables added for debugging; used only when #define PINMODE is on.
- detachInterrupt() no longer does a delete(), since that wasn't working anyway. When you detachInterrupt(), the PORT just disables interrupts for that pin; the PCintPin object remains in memory and in the linked list of pins (possibly slowing down your interrupts a couple of micros). You can reenable a detached interrupt- but you must do it within the PinChangeInt library (would anyone ever enable an interrupt on a pin, then disable it, then have need to reenable it but not using the library?).
- attachInterrupt() now returns a uint8_t value: 1 on successful attach, 0 on successful attach but using an already-enabled pin, and -1 if the new() operator failed to create a PCintPin object.
Also, modified these release notes.
Details:
Uncovered a nasty bug, thanks to robtillaart on the Arduino Forums and Andre' Franken who posted to the PinChangeInt groups. This bug was introduced by me when I assigned PCintPort::curr early in the interrupt handler:
ISR(PCINT0_vect) {
PCintPort::curr = portB.portInputReg;
portB.PCint();
}
Later, in the interrupt handler PCint(), we loop as long as PCIFR indicates a new interrupt wants to be triggered, provided DISABLE_PCINT_MULTI_SERVICE is not defined (it is not by default):
#ifndef DISABLE_PCINT_MULTI_SERVICE
pcifr = PCIFR & PCICRbit;
PCIFR = pcifr; // clear the interrupt if we will process it (no effect if bit is zero)
} while(pcifr);
#endif
...Well. Problem is, if a pin pops up and causes the PCIFR to change, we have to reread the port and look at how it is now! I wasn't doing that before, so if a new interrupt appeared while I was still servicing the old one, odd behavior would take place. For example, an interrupt would register but then the userFunc would not be called upon to service it. The code needs to be:
pcifr = PCIFR & PCICRbit;
PCIFR = pcifr; // clear the interrupt if we will process it (no effect if bit is zero)
PCintPort::curr=portInputReg; // ...Fixed in 2.11beta.
} while(pcifr);
Also, made the interrupt handler even faster with an optimization from robtillaart to take out the checks for changed pins from the while() loop that steps through the pins:
uint8_t changedPins = (PCintPort::curr ^ lastPinView) &
((portRisingPins & PCintPort::curr ) | ( portFallingPins & ~PCintPort::curr ));
...This speedup is offset by more changes in the PCint() handler, which now looks like the following; there are two bug fixes:
FIX 1: sbi(PCIFR, PCICRbit);
FIX 2: ...the aforementioned PCintPort::curr=portInputReg;
Here's the new code:
#ifndef DISABLE_PCINT_MULTI_SERVICE
pcifr = PCIFR & PCICRbit;
if (pcifr) {
//if (PCIFR & PCICRbit) { // believe it or not, this adds .6 micros
sbi(PCIFR, PCICRbit); // This was a BUG: PCIFR = pcifr ...And here is the fix.
#ifdef PINMODE
PCintPort::pcint_multi++;
if (PCIFR & PCICRbit) PCintPort::PCIFRbug=1; // PCIFR & PCICRbit should ALWAYS be 0 here!
#endif
PCintPort::curr=portInputReg; // ...Fixed in 2.11beta.
goto loop; // A goto!!! Don't want to look at the portInputReg gratuitously, so the while() will not do.
}
#endif
Also I added a lot of variables for debugging when PINMODE is defined, for routing out nasty bugs. I may need them in the future... 
Finally, I am not putting newlines in this commentary so I can make it easier to paste online.