bperrybap:
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.
As long as the DPM macro can be rewritten to use the CORE macros, there no issue then.
bperrybap:
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) }
Try it out and see if it works as expected. Post what you propose the CORE macros will be that will be included in the pins_aruduino.h files, and I'll test as well.
bperrybap:
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.
Nothing else I can think of off-hand, although I'm sure the compiler will quickly remind me if a macro it was expecting somewhere goes missing.
bperrybap:
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.
I have to disagree. This looks a very minor change, and not much work at all. 
But I will agree that if we are going to do it, let's do it now. Just so we agree on something.
bperrybap:
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
As long as the macros give you the access to the bit shift values as integers as well as masks, I'm happy. Writing a macro or function to convert a pin no. to a mask is trivial, but going the other way is annoyingly messy. One thing I didn't like about the original casting of the pin/port info is that it didn't have the pin no. info explicitly accessible, only indirectly in mask format, and that made things relatively awkward and inflexible.
(BTW, by "casting" I don't mean "cast" as in type casting, rather "cast" as in "represent in a particular way", the more general/non-technical sense. Just to avoid any misunderstanding or confusion.)