Paul,
I'm curious as to how you intend to handle the IDE 1.6.10 AVR PIN_A0 to PIN_A7 names that collide with existing Teensy++ defines.
There is no way to fully resolve this to support both the new 1.6.10 IDE analog pin defines and and be fully backward compatible with Teensy PORTA pin defines.
One or the other "wins".
While you won't have actual collisions from #define redeclarations since the names come from the variant files which you control for teensy++, there will be the issue that if someone uses something like PIN_A0 and expects it to be the same as using A0, their code will break.
And it has the potential to create some confusion since An and PORT_An are not the same pin like all the other arduino boards.
i.e. A0 will be PORTF0 and PIN_A0 will PORTA0 whereas on all other Arduinos PIN_A0 and A0 are the same physical pin.
In my avrio code I also have this same issue and have decided to take the unfortunate 1 time hit to change the raw port pin define names
from PIN_Pb notation to AVRPIN_Pb notation. It REALLY sucks as it breaks all the existing code that happened to use PIN_Pb but I never want to deal wit this again
and it will also allow users to use the new PIN_An names to indicate the analog ports - well except on Teensy++, unless you also make some kind of change.
It also has a nice benefit in that the name tends to reflect that it is AVR specific.
I came to the conclusion that it becomes a documentation and support issue or you get shafted with a backward compatibility hit.
It sucks either way.
I went round and round before I finally decided to just take the backward compatibility hit,
and unlike some of the arduino.cc core developers, I take backward compatibility very seriously.
--- bill
I'm curious as to how you intend to handle the IDE 1.6.10 AVR PIN_A0 to PIN_A7 names that collide with existing Teensy++ defines.
There is no way to fully resolve this to support both the new 1.6.10 IDE analog pin defines and and be fully backward compatible with Teensy PORTA pin defines.
One or the other "wins".
While you won't have actual collisions from #define redeclarations since the names come from the variant files which you control for teensy++, there will be the issue that if someone uses something like PIN_A0 and expects it to be the same as using A0, their code will break.
And it has the potential to create some confusion since An and PORT_An are not the same pin like all the other arduino boards.
i.e. A0 will be PORTF0 and PIN_A0 will PORTA0 whereas on all other Arduinos PIN_A0 and A0 are the same physical pin.
In my avrio code I also have this same issue and have decided to take the unfortunate 1 time hit to change the raw port pin define names
from PIN_Pb notation to AVRPIN_Pb notation. It REALLY sucks as it breaks all the existing code that happened to use PIN_Pb but I never want to deal wit this again
and it will also allow users to use the new PIN_An names to indicate the analog ports - well except on Teensy++, unless you also make some kind of change.
It also has a nice benefit in that the name tends to reflect that it is AVR specific.
I came to the conclusion that it becomes a documentation and support issue or you get shafted with a backward compatibility hit.
It sucks either way.
I went round and round before I finally decided to just take the backward compatibility hit,
and unlike some of the arduino.cc core developers, I take backward compatibility very seriously.
--- bill