Slow SD Card ?

Rayman

I finally had a chance to try out Rokicki's SD code.· It appears to work (Thanks Rokicki!), but must be slow...· This is what I get from his "fsrw_speed" code:

"Writing 2M took -1598624256"· (I think it took more that 54 seconds, so·CNT rolled over)
"Reading 2M took 477277616"

The filesize of speed.txt was 2M as expected and I sent some actual data to it and it shows up correctly.

Anybody know why my card·is so slow?· Or, is this the expected behavior?

Here's a photo of my setup and the card (only change I made was to substitue 18k for 20k pull-ups, and use VGA_text instead of TV_text):

Rayman

PS: I did already try reformatting the card with suggested a cluster size (16k)

Mike Green

This is expected behavior with large files being written. SD cards are still flash memory and it takes a certain amount of time (roughly 5-10ms) to write a block to the flash array. Different cards have different amounts of buffering which helps somewhat, but, if you write a large enough sequential file, the buffers will fill up and further writes will have to wait for the slow flash memory to write. Some cards write larger blocks to the flash memory and that helps up to a point as well.

rokicki

Okay, the read number looks reasonable (335KBytes/sec) but the write
number doesn't (59KBytes/sec). (I'm assuming it didn't actually roll
over 2^32 but simply rolled over 2^31 and went negative). In my
tests with a wide variety of cards, I see between 114 and 310 KBytes/sec
write, and 271 to 430 KBytes/sec reading.

I would first start by simply trying a different SD card (and format
it to 32K clusters if possible; that's what I recommend.) If that's not
closer to 100K bytes/second, then we'll have to do some more
experimentation.

Your reasonably high read speed means that things appear to be
hooked up correctly and working correctly. Your write speed is
about 2X slower than the worst I've seen, so it's possible it's just
an older card or some other issue I've not seen before.

Note that this is using 1-bit SPI I/O, so it will never be as fast as using
the proprietary 4-bit protocol (which would require a few more prop
pins as well).

Rayman

Thanks Guys!· I picked a good time to post [noparse]:)[/noparse]



PS:· (for anybody else getting started) I made some notes here:

http://www.rayslogic.com/propeller/Programming/SD_Card/SD_Card.htm

Greg P

This Google search:

http://www.google.com/search?hl=en&q=microSD++multiblock+CMD41&btnG=Google+Search

Uncovered this link:

http://www.swiss-case.com/shop3/dokumente/mini SD(1).pdf

This is the only FULL specification (includes SPI protocol) of the SD card that I could find on the Internet. Grab a copy before it disappears! My interest is in the microSD used by the uOLED-96-Prop. This PDF is for a miniSD. The physical pinout is different, of course, for the microSD.

This document has enough information ( I believe ) to expand the WONDERFUL "Radical Eye Software" contribution to include Multiblock write operations. This should afford significant write speedup because "double buffering" could then occur ... while new data to be written to the SD card is being sent to the card by the Propeller, the SD card built-in processor will be simultaneously writing the previously-sent data block to flash memory.

Another issue which might effect write speed: it's my understanding that a WRITE operation issues a SECTOR erase prior to its write. The sector size is larger than the data block size (512 bytes), so that internally the portion of the sector not included in the data block write that is erased must be internally re-written ... and this takes time. I confess to not knowing the details. Apparently a fresh-from-the-factory formatted SD card may be "sector-aligned" ... don't ask ... cause I don't know ... and perform better than one formatted by Windows. If each write is a SECTOR in length, and the data blocks sent are aligned to this sector (defined as the fixed number of data blocks that are erased at once) then the implicit erase operation does not have to re-write erased-over data blocks. This is my best explanation. Perhaps someone in the know could explain it in more detail.



[url=http://][/url]

rokicki

I believe (and I could very well be wrong) that most SD cards actually do a fair bit of "double buffering" internally,
including using extra erase blocks (needed anyway for yield improvements) and behind-the-scenes erase block
clearing. That is, I believe that modern SD cards do a pretty good job out of the box without much need for special
commands.

I encourage you to experiment, however. Note that what works on one card may not work as well on another.

I recommend you start by plotting the behavior of current cards doing simple sequential writes. Then try using a
few multiblock write commands instead and see how much things improve. Then throw in a few preerase
commands and see if that makes things better.

What I see is that most sector writes are quite fast, but the occasional sector write is much, much slower,
probably due to need for a newly cleared erase block.

Unfortunately, the secure digital people appear to be keeping their cards pretty close to their chest on specifics.

Another good source of information is the secure digital drivers available for linux. I suspect some of these
may have been developed after a great deal of experimentation which may lead to some useful insight.

Remember, however, that the fsrw is meant to stay small and simple; the current throughput numbers are
"good enough" for most things one might want to do on the propeller.

Mike Green

The SPI routines in FemtoBasic can do double buffered multiblock transfers. The actual I/O routines run in a cog in assembly. The Spin interface routines wait for the transfer to finish, but could easily be rewritten to do multiple buffering. They will read or write an arbitrary number of bytes already. Have a look (at sdspiFemto.spin). The comments describe how to call them.

The main issue is that of available memory for the buffers.

Fred Hawkins

Greg, nice link, thanks

Greg P

Here is another helpful link regarding SD card interfacing:

elm-chan.org/docs/mmc/mmc_e.html

The author offers his observations regarding write performance.