Interfacing SD Card with mcu

[ee_hob]

Hi all,

I'm not so capable of programming mcu's but I've been trying to figure out for a while. I want to log a couple of sensors' value to SD card. I've read posts about SD card but I couldn't make it.

As a result of reading those posts, I guess I need to send data to SD Card in blocks of 512 bytes by using SPI. I know that byte-by-byte transfer is done in SPI. How can I send 512 bytes using SPI? Do I need to keep 512 bytes data in mcu then send it or how?

This may be very easy to you but I guess I'm missing the basic idea.

P.S: I learned that I need to use 3.3 V logic level.

[Ttelmah]

Yes. You just send 512 bytes.
Yes, you really need to have a 512byte buffer in your PIC, and only write when this is 'full'.
SD is 'page based'. You write a whole page at a time.
If you wanted to write a byte, you'd have to read the whole page, change the byte, and write the whole page back. Every time you write a page, it uses a 'life' of the memory.
It really does depend massively what you want to do. Though more expensive, if this is for data logging, consider using FRAM, instead of SD. Advantage is you can write a single byte (like EEPROM), and write speeds are massively fast (nSec). SD takes mSec to write a page. Write life of FRAM is also basically infinite.

Best Wishes

[ee_hob]

Hi Ttelmah,

Thanks for your quick reply.

If you don't mind, can I ask what you mean by "page based"? As I said, I'm a newbie, I couldn't understand.

Let's say I can send a byte using SPI in a nsec. (I don't know the exact timing) Do I need to wait 512 nsecs to send another sensors' output values?

Thanks in advance,

[Ttelmah]

SD only ever writes a page at a time. You can't write a byte.
This is a physical limitation of the memory. Saves transistors (which is why they can be made so small and cheap), but is something you can't get round.
To write a single byte, you have to read an entire page of 512bytes, change the byte you want, and then write the whole 512bytes back.
You can read single bytes, but not write them.

Think of it a bit like a text editor.
You type away on your screen but until you hit 'save', if the power goes off, the data is lost. It hasn't been written to the disk.

The typing is akin to sending the data to the SD, but until you get to the end of the page and say 'write', the data is not stored. The actual write takes a few uSec (on old cards up to perhaps 250uSec, though modern fast cards are more like 10uSec). Talking to SD, you will be lucky to transfer even 500KB/second, when sending continuously (though you can clock the SPI faster than this, unless you are on a DsPIC or something equivalent with DMA, it takes time to read the byte from the PIC's memory as well...), while to write a byte, will involve reading 512 bytes, then sending 512bytes back, and waiting for the write to complete. Could easily be 1/100th second in total.....

Best Wishes

[ee_hob]

I guess I understood with your text editor example, thanks a lot..

Please correct me if I'm wrong but I want to give an example. (Probably I'm wrong.)

Let's say we have 2 GB SD card. Data is sent over SPI to SD Card in 512 bytes. (I guess it is called sector in SD Card, right?) Does this mean that we have like 3900 sectors in SD Card? For example, we want to use all capactiy of SD card. Due to above calculation, how many secs do I need to use SD Card's all capacity?

[temtronic]

I don't use SD cards but 'generally speaking, using 'binary math'..

...2GB should be 512 bytes * 4096 pages = 2,097,152
Some will be used for 'housekeeping'.That's areas used FAT,HIT,etc.

As for how fast it will 'fill up' ,depends upon you program.You'll have to time how long it takes to recieve a page(512 bytes) of data and then store it.For example;let's say it takes 1ms for the PIC to get the raw sensor data,do some math,save to a buffer,then send to SD card as a 'page'(512 bytes).It'll then take about 4,000 ms to fill the card. That's about 4 seconds.

However it might takes weeks to record the data. We don't know what you're measuring(temperature,pressure,distance),how often(time based or event), how accurate(8,10,12,16,24 bits),every reading or difference ?

Too many factors to give you any real numbers.

I suggest you 'hard code' some known data and write/read to the SD card.that way you KNOW your 'storage' functions work properly. Do not use raw sensor data as there is no way to confirm what's in the card is correct.

You'll have to run some tests and time them.Real world testing is the only way to know.

hth
jay

[ee_hob]

Hi Jay,

Thanks for your answer.

Actually I want to learn the fundamental way to send data to SD card. I guess the reason that I can't go any further is my limited experience in SPI.

Let's say I have a 24 bit sigma-delta ADC and I use only one sensor. Its conversion time is 40 ms. I have a temp 8 bit variable which comes from spi_read(); function. Here is my first question: How can I store that changing variable's value? I mean I have to create a 512 byte block to send it via SPI but how can I create that block? What type of variable should I use to store 512 byte than send it? (I assume that I use proper mcu (having enough RAM)).

These questions may be silly, so forgive me..

Thanks in advance,
Regards

[temtronic]

You've got to do the basics first !
Get you PIC(which one ??) to actually do the '1Hz Flashing LED' program to run right.
Then the 'Hello World' program to a PC and perhaps an LCD module.
Then try the SD card program.
Do NOT even think about interfacing a 24bit sigdlt ADC before ALL of the above code works.
There are code examples for all of these either in the 'examples' folder that CCS supplies, this forum and the 'code library' forum.
Have a good long look at them, run them, see what happens.
You also have to tell us which PIC you've chosen,compiler,etc.
Until you get a PIC 'up and running' ,don't concern youself about some fancy ADC and SD logging code( though all is on this forum...).
Show us some of your code and we can help.

hth
jay

[ee_hob]

Hi Jay,

I'm not that so new. I've done many examples but not so complex.

I've no problem with using internal ADC's in PIC16F877. I've no problem with driving LCD but I've problem with GLCD.

It is very late but I recognized that I need to understand whole communication idea so badly. So I wanted to start from SPI which is the most popular, I guess. I made simple examples using spi_read() or spi_write(). I learned the SPI modes or what CS means. But a few days ago I saw an example with SD card and I wanted to learn how to do it. Now I can see that I didn't exactly understand SPI. If I'm still having problems sending/receiving data via SPI, I guess this means that I couldn't understand it yet. Here is my problem and I don't know where to start. I thought that asking you would be a good start but I guess my knowledge isn't enough to ask you.

Anyway, it will be better to search more but I can't start.

Thanks in advance,
Regards,

[Ttelmah]

There is a big 'jump' coming here.

Physically the SD card is as you describe. However for normal use, it is not used like this.
It is organised as a 'file-system'. What you have is part reserved which contains text 'filenames', with details of where the data associated is stored, and another part that contains 'flags' to say that a sector is in use.
It's like a filing cabinet, with labels on the front of the drawers. There's a book saying 'This file stored here', and a little flag to say the drawer is 'in use', and a record saying where the next drawer is for the data stored.
When you want to add another 'drawer' to the data, you look at the list saying which are in use, and find an empty one, and add this to the file, flagging it as 'in use'.
This is the 'file allocation table' (FAT), and directory structures. Lot's of work. Full code to do this on a PIC, probably about 12+KB, plus several hundred bytes of RAM, for the necessary buffering.

If you select to 'extend' a file, it'll read the last sector into RAM, append to this in RAM, till you either reach the end of the sector, or give a command to 'flush' the buffer (forcing a write).

Now you _can_ use an SD without all this, but if you do, only you will be able to read it....

You'll find quite a few threads here with people trying to use SD with chips like the PIC16F877, and it being pointed out to them, both about the problems of the 3.3v interfacing, and that the chip does not have enough RAM. The RAM buffer really is essential.

Now, if you are just looking at storing data for a 'logging' application, I'd suggest multiple things:

If it doesn't need to be unpluggable, as said before, use a memory better suited for this.
If you want to use SD and FAT, then consider buying one of the libraries for this. Going over 2GB, means going to SDHC, and reliable drivers for this are a lot of work.
Look at alternatives. For instance, the FTDI Vinculum, offers a module that can talk to the PIC, and does all the FAT work 'for you', allowing a standard USB flash drive to be used with tiny amounts of code.
If you want it to be readable on another system, remember that if the power fails 'while writing' this can destroy the data. Consider if you can prevent this by having enough supply 'hold up' time to ensure a write will always complete.

Temtronic's comment applies here, this is big work. It's like a person starting to talk about doing a Land's End to John O' Groat's drive, when he hasn't yet got a driving licence.
Even worse, a 24bit ADC, runs into needing significant electronic skill, to keep noise to a minimum, and really good design.

Best Wishes