Go Down

Topic: SD card read/write with Arduino (Read 116860 times) previous topic - next topic

Nachtwind

minimally different ones - i have used 3.3k and 1.6k, it still worked.
Believe me, Mike, I calculated the odds of this succeeding against the odds I was doing something incredibly stupid[ch8230] and I went ahead

sirmorris

#91
Feb 19, 2009, 11:45 am Last Edit: Feb 19, 2009, 11:49 am by sirmorris Reason: 1
The voltage requirements at the MMC card inputs (MOSI, CLK, /SS) are defined in the MMC card product manual:

VDD in this case must be between 2.7 and 3.6v.

Input HIGH voltage:
min:  0.625 * VDD
max:  VDD + 0.3

Input LOW voltage:
min:  VSS - 0.3
max:  0.25 * VDD

As long as the voltage tapped off the divider falls within this range, all should be well.

The document to read is here:
http://www.sandisk.com/Assets/File/OEM/Manuals/ProdManRS-MMCv1.3.pdf


sirmorris

I've summarised all of this good stuff in a new thread:

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1235125412

I'm sure I've missed something :P

ratdad

All,

I had struggled with the DOSonCHIP module for a week or so. I stumbled upon this thread and uFAT2 solved all of my problems. Thanks to everyone who posted.

DMerriman

Just tried to download the library file on a Linux box using Firefox, and MediaFire promptly threw up by telling me to either sign in or use a supported browser (Internet Exploder?).

sirmorris

Read to the end or hop over here: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1235125412/
:)

smelios

Hello everyone
Does anyone know to make the raw program write in blocks smaller than 512?

sirmorris

512 bytes is the sector size of the device.

Why do you want to write smaller blocks?

smelios

I'm trying to sample a guitar signal and store it to the SD card. It looks like when the Arduino writes the recorded signal to the SD card it takes up some time. Which means that the input signal gets ignored for awhile. I was hoping that if i could shorten the number of bytes being sent to the card it wouldn't ignore the sinput signal to a point that it wouldn't be noticed by the user. If this is to vauge I will gladly go into more detail later. Thanks for taking interest  ::)

sirmorris

I did find that I'm not setting high speed mode  :-[

This might improve matters.

Another thing you might consider is setting up a 'double buffer' system, where you're reading values into one buffer under interrupt control whilst writing the other. You can tune the sampling rate so that you get a consistent period.

Another thing to do might be to break the 'write sector' function so that you can write bytes at a time... You'd have to re-send a command every 512 bytes or so, but that shouldn't take long - there's a latency of about 12 bytes as the write is finished up, then the next sector is primed.

Sorry if that all sounds quite complicated - but it has to be. You don't get something for nothing on a microcontroller  :P


smelios

Well to be honest i'm using the sd-raw program at the beginning of this thread so its notihng to do with your code. I have been following your code and will probably try to use it if I can't figure out my current idea. Thanks again you have been a big help to everyone here who is implementing sd to thier projects ;D

sirmorris

#101
Mar 25, 2009, 12:10 pm Last Edit: Mar 25, 2009, 12:11 pm by sirmorris Reason: 1
Thanks :)

This procedure would likely be the same with whichever library you use. The SPI protocol for writing to the card goes like this:

1. Send 'write sector command' - 0x58 a b c d 0x00
2. Await command acceptance - ie you receive 0x00
3. Send data token - 0xFE
4. Send 512 bytes
5. Send dummy checksum - 0x00 0x00
6. Await 'done' status code - ie you receive 0x00

Mostly these 6 steps are all wrapped up in a function. What I suggest is that 1-3 are split out into one function, 4 in another, and 5-6 in yet another.

StartWrite() - does 1-3
WriteByte - actually would be the existing 'xfer byte' routine
EndWrite() - does 5 & 6


Start the write with steps 1,2,3.

Then write bytes at a time (step 4) until you've sent 512 of the blighters.

Do 5 & 6. If you want to continue, start again at the next sector with steps 1-3.

Let me know how you get on!

breenmachine

A little late and not extremely relevant with all this new UFat stuff but...

For those still curious about just using the SD card in good old raw mode (hey, I found it useful...) and having your writes persist, read on.

A few people have noticed that your writes to the card "dissappear" after restarting the Arduino. The block size is set up to be 512 bytes, and in the code on the first page, a 512 byte buffer is kept, once it is full, it is written out to the card.

This can be trivially disabled so that all writes are written to the card immediately (no buffering). Just open up "sd_raw_config.h" and look for the line:
#define SD_RAW_WRITE_BUFFERING 1
change it to
#define SD_RAW_WRITE_BUFFERING 0

and you should be all set...dunno if someone else already posted this but I saw the question asked and couldn't find the answer myself so I decided to take a look at the code.

pakrat

Quote
Posted by: breenmachine
For those still curious about just using the SD card in good old raw mode


What is meant by using the SD card in "raw mode"?  Is it similar to saving data in an external EEPROM chip?

How is the saved data read from the card?

Thank you

breenmachine

Using it in raw mode is reading and writing directly from/to the bytes on the card. It is like if you're SD card was a very large array of bytes.

The original code on page 1 of this thread only worked in raw mode.

One of the drawbacks is, it is not as easy to access the data that you write to the card on a computer (with UFat you can open it up in a text file).

The upside is, you can get away with running the SD card at 5v in raw if you dont have the correct resistors to get it down to 3.3 (for a while anyways!). Also it probably takes slightly less code memory on the arduino.

Go Up