did you have time to look at my remark in #28 regarding your optimization proposal of the boolean expression.
there is a diff in the formulas when rising = 0, falling = 1 and curr = 0
Yes- sorry. I have been a busy busy busy little beaver! Geez, what a week!
You're right- my optimization was messed up because I made a mistake in my truth table. I think your expression is about the best that we can do. Second- there are more dragons lying about than I had bargained for! I spent the better part of a week's free time wrestling with a big bug in my posted code; I said:
PCintPort::curr ^ lastPinView & (portRisingPins...
and I should have said:
(PCintPort::curr ^ lastPinView) & (portRisingPins...
...Operator precedence. It's not just a good idea, it's the law! OMG what a debugging session I had.
The extra nice thing is, because of my debugging, I uncovered a significant flaw in my code! This is a big deal if you have fast interrupts, and it is real nasty when you have, for example, switches that bounce (don't they all?). The end of the PCint() function should look like this:
pcifr = PCIFR & PCICRbit;
PCIFR = pcifr; // clear the interrupt if we will process it (no effect if bit is zero)
PCintPort::curr=portInputReg; // BUG! ...Fixed in 2.11beta. Without this, we get really weird interrupt behavior. Sheesh.
// This fix slows down the code, though. Even with only 1 pin interrupting.
...don't worry about the speed slowdown mentioned in the comment. With your fix, robtillaart, my tests speed up by a couple of micros. Sadly, that PCintPort::curr=portInputReg will be run even if pcifr is 0. But it's either that or an if statement, in any event. If you don't need it, best to define DISABLE_PCINT_MULTI_SERVICE.
I hope to post version 2.11beta soon. Right now I think I've uncovered/fixed/optimised/edited/compiled everything necessary, but the code is in a bit of a shambles right now so give me a day or two to clean up. In the meantime, there is that damn bug that you can fix in v. 2.01beta by copying from my snippet above.