YUN external SD card

Is it possible to external SD card on arduino side

i use MicroSD Card Adapter to run the sample script , and set chipSelect to pin10

but it initialization failed

Any help appreciated.

following is the code:
/*
SD card read/write

This example shows how to read and write data to and from an SD card file
The circuit:

  • SD card attached to SPI bus as follows:
    ** MOSI - pin 11
    ** MISO - pin 12
    ** CLK - pin 13
    ** CS - pin 4 (for MKRZero SD: SDCARD_SS_PIN)

created Nov 2010
by David A. Mellis
modified 9 Apr 2012
by Tom Igoe

This example code is in the public domain.

*/

#include <SPI.h>
#include <SD.h>
const int chipSelect = 10;
File myFile;

void setup() {
// Open serial communications and wait for port to open:
Serial.begin(9600);
pinMode(chipSelect , OUTPUT);
while (!Serial) {
; // wait for serial port to connect. Needed for native USB port only
}

Serial.print("Initializing SD card...");

// enable Slave Select
digitalWrite(chipSelect, LOW); // SS is pin 10

if (!SD.begin(chipSelect)) {
Serial.println("initialization failed!");
return;
}
Serial.println("initialization done.");

// open the file. note that only one file can be open at a time,
// so you have to close this one before opening another.
myFile = SD.open("test.txt", FILE_WRITE);

// if the file opened okay, write to it:
if (myFile) {
Serial.print("Writing to test.txt...");
myFile.println("testing 1, 2, 3.");
// close the file:
myFile.close();
Serial.println("done.");
} else {
// if the file didn't open, print an error:
Serial.println("error opening test.txt");
}

// re-open the file for reading:
myFile = SD.open("test.txt");
if (myFile) {
Serial.println("test.txt:");

// read from the file until there's nothing else in it:
while (myFile.available()) {
Serial.write(myFile.read());
}
// close the file:
myFile.close();
} else {
// if the file didn't open, print an error:
Serial.println("error opening test.txt");
}
}

void loop() {
// nothing happens after setup
}

If you're trying to write to a Yun's SD card, try this:

#include <Bridge.h>
#include <FileIO.h>

#define DEBUG true

void setup()
{
  Bridge.begin();
  Console.begin();
  FileSystem.begin();

  if (DEBUG) Console.println("Done setup");
}

void loop() {
  String dataString = "Testing, 1, 2, 3...";

  File dataFile = FileSystem.open("/mnt/sda1/datalog.txt", FILE_APPEND);
  // If the file opens successfully, write the string to it, close the file,
  // and print the information to the Serial monitor.

  if (dataFile) {
    dataFile.println(dataString);
    dataFile.close();
  }
  // If there is a problem opening the file, send an error to the Serial monitor
  else {
    if (DEBUG) Console.println("Error opening datalog.txt");
  }

  delay(10000);
}

If you are trying to hook up a second SD card to the Yun, and use an SPI interface from the sketch, then these are not the correct connections:

nilsonhaha:

  • SD card attached to SPI bus as follows:
    ** MOSI - pin 11
    ** MISO - pin 12
    ** CLK - pin 13
    ** CS - pin 4 (for MKRZero SD: SDCARD_SS_PIN)

The '32U4 processor used on the Yun is not the same as the '328P used on a garden variety Arduino. It is the same processor as the Leonardo, so you need to use the connections you would use with a Leonardo. The SPI pins are on the six pin ICSP connector:

Click for more detail

You may get better performance and smaller sketch size if you follow ebolisa's suggestion and use the Yun's existing SD card. You will get the best performance if you skip using FileIO in your sketch and do the file reading/writing on the Linux side of the Yun.

Thanks your replay

I actually want to use second SD card on the YUN beacause I use FileIO to write in SD card is too slow to achieve my purpose.

I'll try the way you said to skip using FileIO

I've gotten my best performance by doing as much processing as possible on the Linux side. The Yun is a different beast than other Arduinos, and using it to its best potential requires a different way of thinking.

Rather than think of the Yun as another Arduino that happens to have a different kind of SD card and network access interface that can be controlled by the sketch, I like to think of it as a very capable Linux system that happens to have an easy to program microcontroller to handle the physical I/O. I don't try to do everything in the sketch - I use the sketch as a semi-intelligent I/O controller, and do most of the processing (including all file reading/writing) on the Linux side.

In my projects, the sketch uses one or more Process objects to start a Linux process (usually written in Python) which it can communicate with using the Process object. The sketch collects raw data samples, and sends them to the process. The sketch also reads raw output data from the process and outputs it to the I/O pins. All of the heavy processing happens on the Linux side. I do only enough processing on the sketch side that is necessary to minimize the amount of data sent through the Process object: for example, if I'm reading a bunch of analog samples and averaging them before making any decisions, I'll collect and average the data in the sketch and send just the average value to the Linux process, rather than send every sample. Similarly, if I'm writing to an LCD, I'll have Linux send the strings and formatting data to the sketch, and let the sketch worry about how to control the display, rather than send individual pin control requests to the sketch, as would be done with a truly low level interface like Firmata.

Rather than tying up more pins and sketch memory by slapping redundant hardware on the system, I recommend that you try to see if there is another way to organize your system that makes the best use of the Yun's resources. Don't start by looking at the Bridge library as a way to do it all in the sketch: while it's easy to use, I find the Bridge library to generally be a poor way to access most of the resources it provides: it can all be done much more efficiently on the Linux side. The one jewel I see in the Bridge library is the Process object, and that's about the only Bridge feature that I routinely use.