SD card buffer size question

I'm looking at the feasibility of incorporating an SD card into a low-end embedded system. Haven't done it before and could us a push in the right direction.

Reading the SanDisk SD card Product Manual, I'm confused about this paragraph in the App. Note section under "File System Support":

"Reading and Writing to an SD Card ... is generally done in 512 byte blocks, however, erasing often occurs in much larger blocks. The NAND architecture used by SanDisk and others currently has Erase Block sizes of (32) or (64) 512 byte blocks, depending on card capacity. In order to re-write a single 512 byte block, all other blocks belonging to the same erase block will be simultaneously erased and need to be rewritten."

So, does that mean you need to have a 16 or 32 KB buffer in the host to hold all the data you're *not* changing if you want to change smaller chunks (such as would happen, I would think, if you wanted to manipulate a file system on the card)? Or just put up with mapping your little on-chip control structure buffer into a 16 or 32 KB chunk, wasting the rest of it, and hope/plan that most of what needs to be stored/read/rewritten comes in big chunks (like much data does in file systems)? Or am I misinterpreting the above and you really *can* rewrite single blocks?

Why I'm asking: A 16 or 32 KB buffer is beyond the on-chip capacity of (most?) low-end controllers, whereas one or two KB is a piece o' cake. I'd obviously rather avoid the cost of extra hardware or a beefier controller.

--
Silvar Beitel, known to small children and USENET as Silver Beetle.
To respond by email: change "minus" to "plus" in address
Reply to
Silver Beetle
Loading thread data ...

I believe everything just works in 512byte blocks and certainly all the filesystems I've looked at are based around that. I'm using MMC cards but as far as I know then the method is the same.

Judging by all the evidence I've seen then only a 512byte buffer is necessary.

Reply to
Tom Lucas

I'll second that. I implemented Lewin Edwards' DOSFS file system on a NetBurner dev kit, and I needed only one or two 512-byte buffers. The SD card controller handles all the internal timing and buffering for you---as well as taking care of wear-leveling for the internal flash chips.

IMHO, SD cards are now the best option for embedded data storage. They are cheaper per byte than many other options and you can probably get more storage per square inch of board space.

If you don't want to bother with a file system, you can simply treat the SD card as a sequence of 512-byte blocks and roll your own storage scheme. I'm working with DOSFS to preserve the option to unplug the card and put it into the slot on a laptop or PC to transfer the data. Thanks to digital cameras and MP3 players, a lot of new PCs come with SD and other digital media interfaces.

Mark Borgerson

Reply to
Mark Borgerson

Here's a solution if you want a ready-made FAT handling device :

formatting link

Reply to
Mike Harrison

OK, thanks Tom, Mark and Mike.

Poking around the 'net shows a couple of designs. No buffers external to the smallish hosts there either.

512 byte blocks and buffers it is, then.

Whether or not a file system goes in can wait. Right now, I'm just trying to firm up the hardware. But thanks for the input and pointers.

--
Silvar Beitel, known to small children and USENET as Silver Beetle.
To respond by email: change "minus" to "plus" in address
Reply to
Silver Beetle

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.