Minimal SD card reader code, if possible

Harley

I'm not sure what all the various SD card reader's code size is. Looking for a minimal one.

I have a touchscreen 'input' but no keyboard to name files. Is there a way to automatically have new files automatically 'named', say with incrementing number at end? Like it reads the DIRectory and then 'knows' the last file, adds one for a new file name to save. Or is that a dumb idea?

Maybe I could put up a virtual keyboard and 'type' file names in that way. That might add a lot of code space. Suggestions???

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

Mike Green

Harley,
I don't think anyone has documented the size of the SD card reader code. I believe the smallest one is Rokicki's FSRW 2.4. His newer version 2.6 is a little bigger. Remember that there are two layers, a low-level SD card driver that reads and writes sectors given a sector address and a high level FAT file system driver that knows about directories and files.

There's no ready-to-go routines to automatically number files, but it shouldn't be hard to make your own. There are calls to FSRW for listing the directory which return successive file names in the directory. You can have code to look at the returned strings, check for the format of the names and, if numeric with some prefix that you define, look for the highest number that exists and increment it, then use that to create a new file. It's easy to compare numeric strings and increment them, particularly if they're fixed length (like "000123")

Harley

Thanks Mike,

I will search for Rokicki's file you mentioned. That should keep me busy for a while.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

heater

I've been using fsrwFemto with sdispiFemto which comes in at 1197 longs.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Harley

I found Rokicki's ver 2.6. Will check how that 'fits'; maybe will need something else smaller, if available. Totally new area for me to deal with.

Rayman's PTP board provides a SD card socket. So figured I should make use of that with my program. Hopefully all will fit in EEPROM and run OK.

Thanks also to heater for your size on fsrw/sdispi Femto.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

localroger

If performance is not an issue you can use one of the earlier fsrw's with one of the slower drivers; the counter/timer based spi drivers are zippy fast but also larger because of unrolled loops and such. Most of the newer efforts are focused on features (like subdirectories and SDHC) and performance and so are larger.

Harley

@heater, For comparison, FSRW ver 2.6 uses 1327 longs. I may have to go smaller; so need to keep this in mind.

@localroger. Thanks for your input. Again, I have to get more done on this project to see if SD card use can be done. Originally wasn't a requirement, but would be a great advantage for keeping reference files.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

Hugh

I use a simple text file on the same SD card to store the name of the last file written.·It reads a three digit number from NUM.TXT·on the SD card, increments the number (which it then uses as the filename for the log data, e.g., "027.csv") and writes the new number to NUM.TXT for the next time.

I'm lazy and the files increment slowly (once a day), so I haven't worried about what happens when it gets to 999...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.

heater

Harley, we must be able to do better than those figures for fsrwFemto with sdispiFemto because that sdspiFemto is chock full of code to handle EEPROM on I2C as well.

RossH has some mean and lean low level SD card driver in his Catalina package. Sadly I have yet to make it work here.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Mike Green

Most of sdspiFemto is the PASM code. Once that's launched in its cog, you can reuse the space for buffers or other table space.

lonesock

Just a quick note: I've been working on smaller versions of the MMC/SD/SDHC block drivers. Here are some results, where the size is FSRW 2.6 and the block driver together, and the speed results are KBytes/sec when writing 512 bytes at a time via the 'pwrite'/'pread' function calls. These versions all still use the read-ahead/write-behind logic.

safe_spi: the current default block driver (uses multi-block mode)
size = 1330 longs
write = 975 KB/s
read = 878 KB/s

smaller multi-block mode
size = 1283 longs
write = 847 KB/s
read = 843 KB/s

smaller single-block mode
size = 1185 longs
write = 170 KB/s
read = 606 KB/s

Note the super-slow writing speed on the single-block driver...this is typical of SDHC cards. The older SD or MMC cards are typically on the same order of magnitude as the read speeds, but all SDHC cards I've tried do not like single-block mode writing. I do get to chop out a bunch of code from the single-block driver because I don't have to be careful of timeouts and auto-exiting multiblock read/write mode.

I can also make versions of the drivers that do not use the read-ahead and write-behind, but that's taking us back to the same basic mechanism as the old FSRW 1.6 code, where the only addition is the support of MMC and SDHC cards. I'm not too keen on investing time (and then support) on those versions unless someone really really needs them.

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
(geek humor escalation => "There are 100 types of people: those who understand binary, and those who understand bit masks")

Ariba

Jonathan

I like to use the old sdspiQ block driver. This driver is relatively fast and very small. The initialization of the SD is all done inside the assembly code.
Would it be possible to add some commands to this initialization code to support also SDHC cards? Yes it will be single block access and the write speed is not high, but for many applications the read speed is what counts. I think if we not support MMC we need no slow SPI and it's just a matter of adding the right initialization sequence of commands at initialization.
This is on my Todo list, but you have much more experience with SD and it is maybe only a work of some minutes for you (?)

Andy

Duane Degn

Hugh said...

I use a simple text file on the same SD card to store the name of the last file written.·. .

And...

I'm lazy and the files increment slowly (once a day), so I haven't worried about what happens when it gets to 999...

Harley,
I store the last·character of the file name in EEPROM.· I'm even lazer than Hugh; I use a letter for the last character of the file name so I never let more than 26 files exist on the card at a time.· I do have the program check the card to make sure the new file name isn't already used.
I've been rewiting my code to use Kye's method's.· My new plan is to have a new folder made each month and have the files' names based on the date (someone else on the forum suggested something similar).· I should have some useable code within a week (hopefully later today).· It depends on how many other things scream for attention louder(than a new file system).· I'd be surprised if my code would be usefully to anyone else, but I'm very willing to shared my hacked together methods.
Duane

sssidney

lonesock - how small do you think it would be if it only supported reading?

Kye

I believe the smallest SD card code was made by Andrew Lamonthe. He wrote everything in spin and did not use and extra cog for the block driver code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

lonesock

@Ariba: I did modify the slightly slower version sdspifasm, as that one had the init code in SPIN. Doing SDHC initialization in PASM would be a bit harder and probably larger as well (though as you point out, it would be easier without MMC support). My old version is attached.

@sssidney: Great question! I will look into a read-only version soon.

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
(geek humor escalation => "There are 100 types of people: those who understand binary, and those who understand bit masks")

sssidney

I was just goofing with fsrw2.6 to see how small it would be it if I removed the write capability. It reduced from 1341 longs of code to 927. I also changed the mb_rawb_spi.spin a bit. This is just by ifdef'ing out (and compiling with BST) obvious write functionality and not by changing any of the design/logic.

Is it OK to attach the modified files here?

I also tried doing simultaneous access from 2 cogs while protecting the fs code with spin locks. It works great.

Post Edited (sssidney) : 7/23/2010 3:33:21 PM GMT

lonesock

Definitely feel free to modify and post, that's great work! Please do put some notices at the top of the file with what you changed and such.

thanks,
Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
(geek humor escalation => "There are 100 types of people: those who understand binary, and those who understand bit masks")

sssidney

Here's the code and a small demo program that calls it. I idef'ed out the write and seek functionality with

#ifdef SID_INCLUDE_WRITE and #ifdef SID_INCLUDE_SEEK.

Ariba

lonesock

Thank you very much for the sdspiasm code with SDHC and MMC initialization. Should not be hard to merge that with the sdspiq when I have time.

Andy