Before I get into specifics, a little background may be useful. You've already read the disclaimer that there is no guarantee that this will work, but let me explain why it will provided the ATmel chip you get is a prime chip (I order in 25 QTY from Newark, so I get the microcontrollers for about $2 each and I am assured of prime chips. I also order the 16MHz crystals from Newark.) Although there is no guarantee, there is a very high chance of success when you use quality components.
There are many SD card shields from forces such as SparkFun and AdaFruit. These boards are designed to fit onto your existing UNO Arduion and provide the electrical interface and physical card holder for the SD Card. However, while convenient, this "may" be a poor design choice from the software point-of-view. Primarily, the <SD.h> Arduino library is a RAM hog, consuming 25% of the memory of the device immediately. And, if the programmer feels a need to further buffer, well there goes more RAM. So, as the user's programming logic becomes more complex that just reading a thermometer, the stress on the uC becomes higher. Unless very careful planning and design are utilized, the resources of the Arduino UNO will be stretched too thin.
I am working with an ATmega2560 (Mega2560) and I'm processing multiple engine sensors on an experimental Europa aircraft fitted with a Rotax engine. The ATmega2560 has the additional RAM to support the SD Card buffer, but I'm using both the SPI and I2C interfaces already for other critical sensors. I could extend the chip-enable logic to support more SPI devices, but I really did not want to do this.
Instead, I started looking for other solutions for logging the 9600 BAUD ASCII stream log generated every second as the 2 OLED 2-line displays were updated. The airplane owner has a separate navigational system that provides critical logging, so the engine logging is considered non-critical; a nice to have log of engine performance and such readings as fuel level, ambient air temperature inside the cabin, external air temperature, and so forth. Therefore, an expensive solution from the purchase of a pre-built recorder was not going to sit well with my friend. I needed to be creative.
Way back in time before the first line of code was written, a long list of possible components was purchased from Hong Kong. Real Time Clock modules (see my writeup: http://www.instructables.com/id/DS1307-Mental-Health-for-Arduino-Users/
) and buffer chips, and pin headers, and somewhere in the box a couple of LC Studio full-size SD Card holders breakout boards. Ah, Ha... something that was already in the workshop.
As I did my dutiful research on the Internet regarding the LC Studio SD Card, I read article and article about failures; there were very few successes. I dug around and found the schematic for the breakout board. Ummm, I said to myself and maybe out loud, too. The little $2 board had a low-dropout 3.3V regulator. Things were getting interesting. My previous experience with SD cards involved specialized IC to do level shifting. In my mind, I was thinking that IF I COULD run a solo-328P at 3.3V then there would be no level shifting needed. My idea was to simply supply the 5V to the SD-Card breakout board and pass the 3.3V back to the 328P. For level shifting the 5V serial output from the ATmega2560, I would use a simple 22K/10K resistor network as is done with the PICAXE RS232 download circuit.
Armed with an idea and enough information to start prototyping, I gathered the required parts and stuck them into my solderless breadboard. I used the Arduino 1.0.1 SD library and the SD example file CardInfo to test the prototype. I used a "real" UNO to string SPI control signals to the LC board and an OLD SACRIFICIAL SD CARD
since I was running the signals at 5V!!! But, the sketch worked, the SD card survived, and I was ready to program a naked chip and remove the UNO from the testing. This move would also allow me to test running the 328P at 3.3V from the LC board 3.3V linear regulator with 5V being supplied by my lab supply.
And it worked.
The next step was to write a sketch specific for the Europa datalogger, move the solderless breadboard to a soldered protobard and throw some serious streaming data at the card. For the data simulation, I used my PICAXE QBF generator: http://www.instructables.com/id/QBF-Quick-Brown-Fox-Serial-Test-Generator/
And if failed... but not miserably. Review of the software determined that I had left "Serial.Print" diagnostic lines in the code. My suspicion was that was causing major issues. I removed the offending commands and recompiled.
And it worked.