The SDClass class makes a reference to "SD.card" instead of just "card". SD is a global instance of SDClass.
This prevents any other instance of SDClass from functioning correctly.
The fix also allows SDClass to be used with an SD card which is removed and replaced, whereas previously, using the global instance SD did not allow this due to the limitation of begin() which cannot be called more than once.
This allows properties defined in programmers.txt to override generic
configurations in platform.txt where needed, for example in the
following configuration:
programmers.txt:
myprog.name=My New Programmer
[...]
myprog.program.tool=avrdude
myprog.config.path={runtime.platform.path}/myprog_avrdude.conf
[...]
platform.txt:
tools.avrdude.path={runtime.tools.avrdude.path}
tools.avrdude.cmd.path={path}/bin/avrdude
tools.avrdude.config.path={path}/etc/avrdude.conf
[...]
tools.avrdude.upload.pattern="{cmd.path}" "-C{config.path}" {upload.verbose} -p{build.mcu} -c{upload.protocol} -P{serial.port} -b{upload.speed} -D "-Uflash:w:{build.path}/{build.project_name}.hex:i"
the generic tools.avrdude.config.path value
{path}/etc/avrdude.conf
is replaced by the more specific myprog.config.path used in "myprog" programmer
{runtime.plaform.path}/myprog_avrdude.conf
correct SS pin setup is already handled by SPI subsystem.
this should prevent future issues like #2868
current implementation assures that:
* pin10 is OUTPUT HIGH if SPI.begin() is called and the pin was unconfigured
* pin10 state is not modified if pinMode(10, OUTPUT) is called before SPI.begin()
* pin10 is INPUT HI-Z if nor pinMode(10, OUTPUT) nor SPI.begin() are called