uSD on the Arduino DUE

The SPI connector (no longer ICSP but the same format)
is right in the middle of the board.

The SdFat beta for the DUE posted by William Greiman in December 2012, now in general release makes it possible to control the SD card on the hardware SPI bus of the DUE. That should be way faster than emulating the SPI in software on some other digital pins. Unfortunately, that bus comes out on the SPI connector in the very middle of the board, overlapped by the standard shield footprint, and very few shields make provision for connecting to it. The Adafruit protoshield in the picture has been dremelled out to allow access, which cuts some of the traces, so think first. A six pin chunk has been dremelled off the end of a longer length of double wide female header. Some header pins have been pushed into some of the odd numbered digital pins at the bottom in the photo, primarily for structural support.

Half an Adafruit Permaproto Board fits right over the pins,
after dremelling away some unneeded surface and traces on
the bottom that shouldn't connect to each other.

The header slides on and matches to the top surface of
the protoshield, not the bottom. The protoshield is
mostly empty except for an X-Bee connection header.

I made sure to dremel off the traces on the protoboard that would be covered by the headers, then used the DUE as the template to hold all the pieces while soldering the pins. I soldered wires to the six header pins for connection to the Adafruit uSD breakout board, then used the breakout board as a legend to make sure they wound up in the appropriate holes in the protoboard. After the wiring was complete and tested, I soldered the breakout over top of the wiring. The result tips the breakout up, which actually turns out to be convenient for inserting and removing the card -- purely good luck ;-)

VCC (top right red on the header) goes to 5V on the breakout, GND (bottom right black) to GND,
SCK (middle left black) to CLK, MOSI (middle right yellow) to DI, and MISO (top left green) to DO. 

I wound up connecting the CS pin to digital pin 45 (yellow)
because it was handy. That was before I found out that
"the extended API can use pins 4, 10, and 52 for CS".

There's some freedom of choice on picking the CS pin connection, so I picked digital pin 45 because I already had a header pin stuck in that socket, and it had worked when I tested it with jumper wires. I found out after doing that soldering that there is an extended API for SPI on the DUE that can (only?) make use of digital pins 4, 10, and 52 for CS, but that doesn't seem to be interfering with the benchmark programs running sdFat. When I plugged in this configuration and ran the bench sketch it produced:

Free RAM: 62747
Type is FAT32
File size 20MB
Buffer size 32768 bytes
Starting write test.  Please wait up to a minute
Write 2074.35 KB/sec
Maximum latency: 452410 usec, Minimum Latency: 7830 usec, Avg Latency: 15788 usec

Starting read test.  Please wait up to a minute
Read 4381.52 KB/sec
Maximum latency: 12166 usec, Minimum Latency: 7413 usec, Avg Latency: 7476 usec

That was way better than the results I got from my first run with a small file and a small buffer size, although it ate up a third of the available memory.

Free RAM: 95415
Type is FAT32
File size 5MB
Buffer size 100 bytes
Starting write test.  Please wait up to a minute
Write 85.27 KB/sec
Maximum latency: 159470 usec, Minimum Latency: 15 usec, Avg Latency: 1171 usec

Starting read test.  Please wait up to a minute
Read 1208.31 KB/sec
Maximum latency: 865 usec, Minimum Latency: 15 usec, Avg Latency: 81 usec

The card also conveniently clears
the motor driver shield and wiring
that goes next in the stack.

Having the SD onboard the DUE will let me record all the performance parameters while running linear actuators from the motor shield and measuring the forces they generate on the load cells. This has the advantage that I won't need to have the SD running on the UNO with the TFT/TS combo that provides the user interface at the other end of the X-Bee link.