SD Card and PIC integration

Hello Everyone,

I am trying to find the right PIC to read and write to SD Card. I've been researching, and I am getting mixed results that are confusing me, and I was hoping somebody could clear this up for me.

I am trying to read, write, and rewrite to SD Card, and the biggest issue seems to be the RAM size. My project was originally being completed with PIC16f877a and I've read that it has insufficient RAM size(368) to accomodate the 512byte blocks that need to be written to SD Card, so I've been looking at PIC18f4520. But, I've also seen projects that have been able to accomplish this with PIC16f877a.

Is it possible to create .txt file with PIC16(368RAM) on an SD Card? Thanks

The 18F series would be better suited as you've noted.

Thanks for the reply.
I read something on the SD Card Product Manual pp A-5 under File System Support that I found a bit difficult to understand.

I need to find the right PIC MCU to be able to handle the 512byte blocks to be written into the SD Card, but under File System Support, it says that in order to erase one 512 byte block, multiple blocks that share the erase block will all be deleted. Does that mean that 1546RAM on a PIC18 MCU is not enough? I am not sure if I am understanding this portion correctly.

Also, in order to overwrite a single block of 512bytes, does it have to first be erased completely before rewriting? Thanks!

I've not yet used SD/MMC cards with a PIC, but I remember seeing library files to work with them in my compiler (CCS PICC).

The actual card driver does not give any requirements.

The example SD access program (which uses the driver library) is set up to work with a PIC18F67J60.

That has chip has 3808 bytes of RAM, so presumably any pic with that or more RAM should be capable of working with an SD or MMC card.

I've no more info, I hope that is some help.
(The files are copyright, so I can't post them).

Note: Remember SD cards are formatted to work in a PC. You cannot just write a small amount of data and expect it to be visible on another machine when you put the card in.

You have to read the FAT and directory, find unallocated space, create the actual file then update the FAT to show that the space is now in use and create a suitable directory entry after finding the first directory slot that is not in use (after reading the whole directory to make sure the filename is not already in use - if it is, you need to delete that file and de-allocate it's space first...)

In other words, you have to re-create all the functions that an operating system does when it accesses a disk drive to read and create files.

There are no doubt lots of examples of code about (like people who've made MP3 players using PICs & SD cards etc.,) but you need to start with a processor that has enough RAM & program space to do some fairly complex buffering and data handling.

I've made a few projects that use SD cards.

I think that practically any microcontroller would be capable of controlling an SD
card; they're not that demanding of a device.

But so much of the design depends on what you plan to do with it that I can't really give much recommendation without knowing more of your project. But I can give you some general pointers.

SD cards use 3.3 volts. It will be easier to use a 3.3 volt microcontroller.

There is not necessarily a need to store a full sector in RAM. If you are making a logger, you can feed data from a sensor relatively slowly into the SD card, only performing a write when a full sector has been filled. When reading out, you can similarly read data relatively slowly, feeding the data directly to an LCD or headphones via a DAC or something.

SD cards typically use a FAT filesystem but it is not required. Using a FAT is really handy if you want to share the card between a PC and your device, whether for having the PC write music files to the SD card, or to have the SD card transfer logging files to the PC. But if your project will never transfer files directly to a PC then the FAT may be more trouble than its worth. In particular, the FAT filesystem is easily corrupted by powering down before a file is completely written. The SD card itself will be quite robust across unplanned power-downs but both individual FAT files and the entire FAT filesystem can be corrupted fairly easily.

If you do use a FAT then it is handy to be able to cache the file allocation table in RAM, otherwise your code will regularly be pausing to reread it whenever it has to allocate another cluster of sectors. You have to allow for the extra time to do that if your code is doing high-speed reads or writes to FAT files.

If you don't use a FAT then it is up to you to organise your sector usage. It could be as simple as writing sequential sectors of data; this doesn't necessarily have to be a general purpose filesystem. But you'd have to figure out how to store current write position and how to read back the data.

I believe it's true that the 512 byte sectors must be erased before writing, but the card will take care of that for you if necessary; you do not have to explicitely erase it, but the downside is that a write may take an unusually long time to finish, during which you may need to buffer incoming data. A way to avoid erase delays is to pre-erase the card, which will allow writes to go much faster. But you still will need to adjust your project for the card's speed, which is fast but still finite.

The SD card SPI read/write protocol is moderately complex. Many people have created microcontroller libraries, so it isn't all that difficult, but unless this is your particular interest, you may want to use existing libraries of card access code. So if you don't plan to write your own SD access code, you may want to select a microcontroller based on available libraries of SD access code that suits your needs.

This should get you started:
http://www.captain.at/electronics/pic-mmc/ -piece of code to make read/write possible
http://elm-chan.org/fsw/ff/00index_e.html -file system library to make use of FAT32
I used it on ATmega128, but you should be able to use it on some PIC as well. But I suggest at least 1K RAM, 2K is even better, but this also depends on the complexity of the other routines you need.