pico:
I'm completely OK with this, particularly if it ties into a scheme like Paul is already using -- why have fragmented approaches if they can be avoided? Before you do too much work, please double check that the recasting is still going to work for the SD and SdFat libs.
What I saw wasn't any sort of recasting but rather some use of macros that use concatenation
to derive other macro names similar to what is done in the Teensy core.
Changing the pin & bit macros and naming, obviously breaks any code that uses them since I'm proposing eliminating
the old/existing 1284 variant BIT* and PIN* macros for Teensy style "CORE" macros.
The DPM() macro used in those libraries when using the mighty 1284 would break.
However, the DPM macro could easily be changed to use the CORE macros instead since the
functionality is the same.
By changing the macro the actual tables in utility/Sd2PinMap.h and utility/DigitalPin.h wouldn't change,
but the DPM() macro is inside the header too, so the headers would have to be modified.
The macro would change from this:
#define DPM(x) { PORT_TO_MODE(PORT_D##x), PORT_TO_INPUT(PORT_D##x), PORT_TO_OUTPUT(PORT_D##x), BIT_D##x }
to this:
#define DPM(x) { CORE_DDRREG(x), CORE_PINREG(x), CORE_PORTREG(x), CORE_BIT(x) }
I'm not sure what other code out there is already using these BIT* and PORT* macros,
but I think Paul's way is a bit more useful with additional capabilities.
All this said it is a pretty large change and a good bit of work.
I'm not sure if folks are on board with the changes.
However, if this change is to be made, it is better to make it sooner rather than later.
BTW,
In looking at the low level code, it looks like there might be a small performance bump and
code size reduction if the tables stored the bitmask rather than the bit number.
i.e. let the compiler do the bit shift vs doing it at runtime in the data path.
--- bill