I have used SD cards for several embedded applications over the years. However, as cards have gotten larger, the single block read and write speeds have dropped. I suspect this is largely because the page sizes are larger and larger. Most SD stacks do not perform multiple block read/writes and so therefore in embedded applications we can never get megabytes per second like you can using a PC. Part of this is due to the clock rates we can use, but most of it is due to the time it takes to do single block read and writes. Does anybody know of any SD cards which are 'optimized' to do this? If there are any other suggestions for getting around this limit, I'm all ears. However, it would be VERY difficult in my application to implement multiple block requests for various reasons.
-
\$\begingroup\$ Surely the limit's that the column scan charge/IO controller on the card has a streaming mode for contiguous and preplanned slates of blocks, and that somehow you're getting the card to do SD v0.90.1 compatibility stuff or preferring a timing that really nicks its expectations? If only I knew what Atmel series you had exactly 1 pin to read SDHC cards with! Do we have to tell your application about how the SD card I/O is done? \$\endgroup\$– ThrangalucchianSep 23, 2011 at 22:03
1 Answer
Smaller capacity SD cards will often perform better for single-block writes, because their erase page size is smaller. When you write to the card, even if you only write a single byte, the card's internal controller may have to read an entire page (often 4K) into a buffer, modify your one byte, erase the Flash page, then write the whole thing back to the Flash memory. So cards with a smaller erase page size will have less of a penalty for small writes at random addresses.
What microcontroller are you using? SdFatLab works on AVRs and does support multiple block read/write operations. Your files must be in contiguous blocks on the SD card to take advantage of it.
Check out some of the discussion and benchmarks at http://elm-chan.org/docs/mmc/mmc_e.html
-
\$\begingroup\$ A flash controller will typically have to deal with erase blocks that are much larger than a logical page; when a page is written, the old data will not be erased immediately but marked for reclamation. When enough pages in an erase block are marked for reclamation, the block's contents will be moved to a blank block, whereupon the old block can be erased. The larger the erase-block size, the longer that process will take but the less often it will need to occur. I would expect the firmware design within the flash controller to make a much bigger performance difference than... \$\endgroup\$– supercatSep 25, 2014 at 16:14