Most users don't need to know about SS, SCK, MOSI, and MISO. I set SS to output and set it high in init(). That makes SdFat work with boards that don't use SS as chip select for the SD. If another SPI device uses SS as chip select this disables it.

The only time you need to worry about another SPI devices is if it uses a pin other than SS for chip select. You must set chip select high on that device before calling SdFat::init().

I don't want users to edit Sd2PinMap.h It is generated by a program that I run.

You are an exception since you are making your own board. You will always need to edit Sd2PinMap.h since the 1284P is defined to be a Sanguino in Sd2PinMap.h.

Early versions of SdFat had SD_CHIP_SELECT_PIN in the same file as SS_PIN, SCK_PIN, MOSI_PIN, and MISO_PIN. Users thought they could change the pin numbers any way they wanted. That caused a lot of problems.

I wish I could remove the definition for SD_CHIP_SELECT_PIN and require users to call

..the easiest way to test yor sdcard-hw "today" is to go with my setup (see my post, sanguino like) and to use pb4 as the chipselect (take it from the jumper J3-pin3 and apply accordingly )...

sw trap - the biggest issue with arduino is the attempt to make everything "automated" so in the near future the wrappers will be 99% of an application volume... fortunately sw-wise is everything doable..

.. I'm currently working with pic32mx so I am observing carefully those guys with chipkit (arduino "clone" based on pic32mx).. they are in much worse situation than you..

@fat16lib: nope, I am not going to edit any file!! One year ago I spent so much time/effort/stress to get my atmega32 and atmega1284p running arduino (bootloader, pinmappings, etc) that I am still under medication (post traumatic stress disorder symptoms..)

I am not going to edit any file!! One year ago I spent so much time to get my atmega32 and atmega1284p running arduino (bootloader, pinmappings, etc) that I am still under medication (post traumatic stress disorder symptoms..)