Seems the Leo has swapped the correspondence between Int0, Int1, P2 and P3 from previous versions. I've verified this with a test sketch, though the evidence is right in the schematics:
So... a boo-boo that will be backed out, or a change that's here to stay? Either way, what's your best advice for a conditional compilation scheme that will maximize backward and (probable) forward compatibility for my interrupt driven libraries? Some of them must interrupt on CHANGE and poll the interrupting pin to determine state, so it's not just a matter of compensating in HWR, the correspondence matters!
Looks like that is not the only difference, to say the least. It looks like all the port<->pin correspondences are different. So interrupts are the least of your worries.
If you stick to digitalRead rather than reading ports you may reduce the impact. Otherwise all I can suggest is an #if on the processor type.
Well, I'm using the team's lower level abstractions for the virtual pins for everything else, so I don't think the relocations in the ports or whatnot should be a problem... the Arduino team have constructed and maintained those beautifully... for instance my ISRs use this to poll the pins with relatively low latency (compared to digitalRead):
inline int readPin(uint8_t pin)
{
uint8_t bit = digitalPinToBitMask(pin);
uint8_t port = digitalPinToPort(pin);
if (*portInputRegister(port) & bit) return HIGH;
return LOW;
}
The problem is essentially in hardware, really in the PCB layout (and corresponding Core), since Int0 and Int1 now route to different hardware pins than before. This must have been simply an error that has been overlooked until now. I doubt there is any fundamental reason that they couldn't have kept the Int0/P2 etc. correspondence, and probably meant to do so. I am looking for evidence that the Arduino team has noticed this problem, and to get a story about what they intend to do about it.
Of course, I can (and have, overnight) introduced conditional compilation on processor type to prop up the libraries, but the Arduino team's decision will affect the maintainability of that strategy. Right now, the conditional maps 1:1 to the 32U4, but that's not stable long term.
I'm not sure that there's ANY easy way out. The most painful for them (and best for me!) would be to establish a macro def based on this BOARD model (say included in pins_arduino.h), and either return to the old hardware correspondence on the next model, or maintain the switch for future models using the new correspondence. Then at least the conditional compilation on the user end would be stable.
Sorry to be so Engineer-y about this, but I am trying to support hundreds of Arduino based Science Museum exhibits, and give those who come after a decent chance to maintain them for decades, so these things matter in that context.
Just had a better idea: if the Arduino team would add an explicit abstraction for new virtual pins corresponding to Int0 and Int1 in all pins_arduino.h files, just like the Analog pin aliases. Hey presto... for those who care, re-write around those abstractions and conditional compilation goes away. For those who don't, it's transparent. Keep the new correspondence or go back, not an issue.
e.g. for Leo:
// Mapping of hardware interrupt pins as digital I/O
static const uint8_t INT0 = 3;
static const uint8_t INT1 = 2;
Best would be to retrofit all pins_arduino.h files in future IDE releases to avoid conditional compilation on the user end altogether.
