SD card cluster size

Graham Stabler

I'm helping a friend with a little coding on the propeller, he is now reading encoders at high speed with some of my code and has come to the point where he wants to write some data to an SD card. I've done some searching and it is suggested that the card is formatted to a 32kb cluster size, it is a 2Gb card and this makes it FAT16 automatically, in Rokicki's code however if the cluster size is set to 32000 then it will try to declare two arrays each of 32kb which is obviously not possible.

Are we missing something here? Obviously we are [noparse]:)[/noparse]

Thanks

Graham

lonesock

The data gets passed back and forth to the card over the SPI bus using a fixed block size of 512 bytes. The cluster size has to do with how much data is linked to each FAT entry stored on the card itself, not in the propeller RAM. Using a 32kB cluster size basically means we get to read or write 32kB worth of data (in 512 byte blocks) before we have to jump to the FAT table. All that reading or writing is sequential, thus faster, hence the recommendation for the largest cluster size available to increase performance. The actual RAM used by FSRW is fixed, although you can have multiple copies of FSRW if you want to have multiple files open simultaneously (or the same file open for reading in multiple locations).

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

Graham Stabler

I see thanks, so would it be correct to say that the code waits for the 512 byte buffer to be filled before sending? We did a little test writing longs to the card (well 4 byte chunks) and noticed that the time taken for pwrite was much longer every 512bytes so that would make sense if it was the case. Ideally I think we would want to double buffer so we can keep saving encoder pulse readings while the card is writing. Such good fun.

Cheers,

Graham

lonesock

Correct, we can only write 512 bytes at a time. If you do your own buffering into a 512 byte block (long aligned) and send that all at once using pwrite, you should see much better performance. Using pputc is quite slow as there is a bunch of SPIN overhead. Internally the SD card driver will buffer each 512 byte block inside cog RAM (assuming you're using the latest 2.x series on the forum), so you should not see much of a slow-down at all using this method.

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

Graham Stabler

We were actually using pwrite but only for four bytes at a time but that is still a waste of spin.· You mention V2.x, do you happen to have a link?

Cheers,

Graham

lonesock

Sure. Here's the latest version on the forum:

http://forums.parallax.com/showthread.php?p=844245

You can also check on the latest status via the SourceForge page:

fsrw.hg.sourceforge.net/hgweb/fsrw/fsrw/

(There haven't been too many updates recently, so the 2.4 zip is most likely sufficient, unless you want to set the date for your log files.)

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

Graham Stabler

Much appreciated thanks!

Graham