bperrybap:
In looking back at the commits, I see a pretty big change to the pins_arduino.h header file that
was put in as part of a commit related to adding patched versions of Ethernet, Servo, & SD.
It added defines for the bit and port for each pin.
I'm assuming that these changes weren't needed for those libraries, but were tossed in for clarity?
Actually, no, the port/pin info needed to be recast so as to be able to support Bill G.'s fast pin mapping code in Sd2PinMap.h SD lib (also used in his SdFat lib, in DigitalPin.h).
bperrybap:
If adding all these new port and bit defines for each pin is desired,
I'd suggest moving down a path of what what Paul did in the Teensy core in his core_pins.h header file.
(It was rejected by the Arduino team but I believe it is quite useful and makes a lot of sense)
In his implementation, there are defines per pin for port, bit, and bitmask but I think it is better than
what is currently in the 1284 variant pins_arduino.h header files.
You never use the port, bit, and bitmask defines directly but rather through macros and as and added bonus
you have the added ability to specify AVR port/bit pins directly. i.e.
digitalWrite(PIN_B0, HIGH);
to set PB0 high.To make this happen, you create a define for each pin, whose name is PIN_Pb where P is the port and b is the bit
and the value is the Arduino pin number.
Then you have the port bit, and bitmask defines that are never used directly but
rather through some concatenation macros.This allows you to access things like bit, bitmask or port: (examples for B7)
CORE_BIT(PIN_B7)
CORE_BITMASK(PIN_B7)
CORE_PORTREG(PIN_B7)It is very clear and easy to visualize for things like the progmem tables.
If there is interest in moving twards Paul's "core" defines (which goes a bit further than just these bits/masks/port defines),
I'll be happy to do the mods, but I before doing it,
I want to make sure people are ok with this.To see the defines and macros, look down in the teensy core at the file core_pins.h
--- bill
One other note:
Making these changes and adding these defines, should have no impact on existing code.
It merely adds defines that new code could take advantage of.
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.