Ada,
You could try my speed tester and see if that behaves any better with that one SD card. You'll need to configure the mount function of the tester to use the sdmm_bashed.cc driver.
EDIT: Oops, I've left our diagnostics in sdmm_bashed.cc. It shouldn't cause any problems though.
I thought you already had it. It's in the Obex, as per that link above. Unzip it and have a read. There is both a Spin2 and C example of its use.
Drivers that use the filesystem plug-in system don't have to be built-in to Flexspin. They provide a bunch of hooks, a set of function pointers, that the filesystem layer patches into itself at run-time. I've simply copied that interface from Eric's newest sources.
The 4-bit driver worked fine with both FAT32FS and FSRW, but wasn't of much value since neither of those filesystem handlers were very efficient. I discovered that, historically, FSRW's performance gains over FAT32FS were made at the driver level by prefetching the next block before it was requested. My 4-bit driver hasn't been written to run in its own cog, therefore it doesn't attempt prefetching.
In other words, if not using Flexspin's filesystem handler then using the fixed up sdspi_bashed3.spin2 is more compact and universally usable than bothering with trying to use the 4-bit sdsd.cc.
PS: I also discovered that FSRW's bugginess came from its driver, not the handler. It wasn't doing any card busy checks, amongst others.
A better way than doing prefetching, for Flexspin's drivers at least, is to limit the use of CMD12, STOP_TRANSMISSION, for CMD18, READ_MULTIPLE_BLOCK, to only when there is a disjoint in the block order. Rather than for each cluster. I do fear such will have potential for nasty corner case bugs though.
However, it would be interesting to know what impact it could have on performance. If it goes well, then there is even potential to do the same for CMD25, WRITE_MULTIPLE_BLOCK.
Oh, it would be even better for FSRW even. Instead of adding a multi-block read function, replace the existing single-block CMD17 with a CMD18 and then implement the lazy CMD12 as well.
I found a bug with my latest, v1.2, bug fix ... With the activity LED now being turned off by lowering DIR instead of driving the pin high, this impacts the clock enable control inside the driver code in the situation where there is no LED present. The LED control gets blindly assigned to the clock pin in that situation. This is done so as to not need repeated runtime feature checks. It had no impact while DIR was left high. But now that DIRs are being lowered I needed to add one extra instruction to ensure the clock smartpin is enabled when each new SD command is issued.
@evanh said:
A better way than doing prefetching, for Flexspin's drivers at least, is to limit the use of CMD12, STOP_TRANSMISSION, for CMD18, READ_MULTIPLE_BLOCK, to only when there is a disjoint in the block order. Rather than for each cluster. I do fear such will have potential for nasty corner case bugs though.
Well, I got it working it seems. And the results are an improvement:
Normal CMD12, Sysclock 200 MHz, SD clock 50 MHz
rxlag=10 selected Lowest=6 Highest=13
CID decode: ManID=03 OEMID=SD Name=SE32G
Ver=8.0 Serial=6018369B Date=2017-12
SD Card Init Successful
cluster size = 16384 bytes
Buffer = 2 kB, Written 512 kB at 1643 kB/s, Verified, Read 512 kB at 4730 kB/s
Buffer = 2 kB, Written 512 kB at 1669 kB/s, Verified, Read 512 kB at 4863 kB/s
Buffer = 2 kB, Written 512 kB at 1648 kB/s, Verified, Read 512 kB at 4725 kB/s
Buffer = 4 kB, Written 1024 kB at 3699 kB/s, Verified, Read 1024 kB at 8335 kB/s
Buffer = 4 kB, Written 1024 kB at 3504 kB/s, Verified, Read 1024 kB at 8144 kB/s
Buffer = 4 kB, Written 1024 kB at 3682 kB/s, Verified, Read 1024 kB at 8126 kB/s
Buffer = 8 kB, Written 2048 kB at 5558 kB/s, Verified, Read 2048 kB at 12138 kB/s
Buffer = 8 kB, Written 2048 kB at 5834 kB/s, Verified, Read 2048 kB at 12070 kB/s
Buffer = 8 kB, Written 2048 kB at 5744 kB/s, Verified, Read 2048 kB at 12225 kB/s
Lazy CMD12, Sysclock 200 MHz, SD clock 50 MHz
rxlag=10 selected Lowest=6 Highest=13
CID decode: ManID=03 OEMID=SD Name=SE32G
Ver=8.0 Serial=6018369B Date=2017-12
SD Card Init Successful
cluster size = 16384 bytes
Buffer = 2 kB, Written 512 kB at 1656 kB/s, Verified, Read 512 kB at 6908 kB/s
Buffer = 2 kB, Written 512 kB at 1644 kB/s, Verified, Read 512 kB at 6957 kB/s
Buffer = 2 kB, Written 512 kB at 1669 kB/s, Verified, Read 512 kB at 6945 kB/s
Buffer = 4 kB, Written 1024 kB at 3642 kB/s, Verified, Read 1024 kB at 11034 kB/s
Buffer = 4 kB, Written 1024 kB at 3668 kB/s, Verified, Read 1024 kB at 11284 kB/s
Buffer = 4 kB, Written 1024 kB at 3501 kB/s, Verified, Read 1024 kB at 11286 kB/s
Buffer = 8 kB, Written 2048 kB at 5723 kB/s, Verified, Read 2048 kB at 15133 kB/s
Buffer = 8 kB, Written 2048 kB at 5699 kB/s, Verified, Read 2048 kB at 15131 kB/s
Buffer = 8 kB, Written 2048 kB at 5774 kB/s, Verified, Read 2048 kB at 15129 kB/s
This actually still is a prefetching mechanism, it's just allowing the card do it on the driver's behalf. The purpose of CMD18 over CMD17 is telling the card to go ahead and prep up the next incremental block.
So I've now made more effective use of this mechanism. It needed a notable restructure of the block read function, and another clock smartpin enable instruction strategically inserted.
Next up, see if block writes can be done with lazy CMD12 as well ...
Whoa! I found a bug (Every second join became disjointed) that was slowing it down still. And I've got writes working with lazy CMD12 too! Don't need no big buffers any longer. Fast recording here we come.
Lazy CMD12, Sysclock 350 MHz
SD clock-divider set to sysclock/3 (116.6 MHz)
CID decode: ManID=03 OEMID=SD Name=SE32G
Ver=8.0 Serial=6018369B Date=2017-12
cluster size = 16384 bytes
Buffer = 2 kB, Written 512 kB at 20060 kB/s, Verified, Read 512 kB at 32833 kB/s
Buffer = 2 kB, Written 512 kB at 24490 kB/s, Verified, Read 512 kB at 32822 kB/s
Buffer = 2 kB, Written 512 kB at 24284 kB/s, Verified, Read 512 kB at 32835 kB/s
Buffer = 4 kB, Written 1024 kB at 33046 kB/s, Verified, Read 1024 kB at 39708 kB/s
Buffer = 4 kB, Written 1024 kB at 31607 kB/s, Verified, Read 1024 kB at 39714 kB/s
Buffer = 4 kB, Written 1024 kB at 32785 kB/s, Verified, Read 1024 kB at 39711 kB/s
Buffer = 8 kB, Written 2048 kB at 30476 kB/s, Verified, Read 2048 kB at 42825 kB/s
Buffer = 8 kB, Written 2048 kB at 26328 kB/s, Verified, Read 2048 kB at 42954 kB/s
Buffer = 8 kB, Written 2048 kB at 31214 kB/s, Verified, Read 2048 kB at 42966 kB/s
Buffer = 16 kB, Written 4096 kB at 32279 kB/s, Verified, Read 4096 kB at 46004 kB/s
Buffer = 16 kB, Written 4096 kB at 33109 kB/s, Verified, Read 4096 kB at 46017 kB/s
Buffer = 16 kB, Written 4096 kB at 33039 kB/s, Verified, Read 4096 kB at 46031 kB/s
Buffer = 32 kB, Written 4096 kB at 32642 kB/s, Verified, Read 4096 kB at 46509 kB/s
Buffer = 32 kB, Written 4096 kB at 30921 kB/s, Verified, Read 4096 kB at 46165 kB/s
Buffer = 32 kB, Written 4096 kB at 31064 kB/s, Verified, Read 4096 kB at 46498 kB/s
Buffer = 64 kB, Written 4096 kB at 33644 kB/s, Verified, Read 4096 kB at 46645 kB/s
Buffer = 64 kB, Written 4096 kB at 34021 kB/s, Verified, Read 4096 kB at 46648 kB/s
Buffer = 64 kB, Written 4096 kB at 33193 kB/s, Verified, Read 4096 kB at 46466 kB/s
Buffer = 128 kB, Written 4096 kB at 33182 kB/s, Verified, Read 4096 kB at 46699 kB/s
Buffer = 128 kB, Written 4096 kB at 33054 kB/s, Verified, Read 4096 kB at 46364 kB/s
Buffer = 128 kB, Written 4096 kB at 31381 kB/s, Verified, Read 4096 kB at 46694 kB/s
Comments
No, still the same
It repeats 4 or 5 times, right? Are they all the same value?
Like this:
No, no repeating. Wrong file?
Definitely was right file. Okay, I've split up the conditions more. This has to repeat:
EDIT: Better one again ...
Still sad
Bit of a puzzle as to how it is alternating then ... one last try. I've backed up all the way on the retries:
Baffling as it is...
Now that I've got multi-card support functioning I've posted everything in the Obex zip file - https://obex.parallax.com/obex/sdsd-cc/
Ada,
You could try my speed tester and see if that behaves any better with that one SD card. You'll need to configure the mount function of the tester to use the sdmm_bashed.cc driver.
EDIT: Oops, I've left our diagnostics in sdmm_bashed.cc. It shouldn't cause any problems though.
Is there anything new in terms of how to use this with Flexprop?
Just tried with latest and couldn't make it work right away...
I probably just need to write some instructions is all. It uses the newer plug-in mechanism. What code have you written so far?
Not much but hear it makes emulators load faster, which would be nice.
In that case, what went wrong for you? Was there errors of some sort? The terminal debug code can be compiled in with
-DSD_DEBUG@evanh did you add your driver to flexprop? Or, is that still in the works?
I thought you already had it. It's in the Obex, as per that link above. Unzip it and have a read. There is both a Spin2 and C example of its use.
Drivers that use the filesystem plug-in system don't have to be built-in to Flexspin. They provide a bunch of hooks, a set of function pointers, that the filesystem layer patches into itself at run-time. I've simply copied that interface from Eric's newest sources.
@evanh Ok, thanks.
For that use case, you want to grab latest neoyume and set
The driver is vendored ready for use.
The other emulators don't currently support 4-bit and need the regular pins set as
Thanks @Wuerfel_21
@evanh Did you get 4-bit mode working with the Spin2 FSRW/FAT32 codes?
Think you improved the 1-bit mode and we put that in OBEX.
Is there some problem getting this to work with FSRW/FAT32?
The 4-bit driver worked fine with both FAT32FS and FSRW, but wasn't of much value since neither of those filesystem handlers were very efficient. I discovered that, historically, FSRW's performance gains over FAT32FS were made at the driver level by prefetching the next block before it was requested. My 4-bit driver hasn't been written to run in its own cog, therefore it doesn't attempt prefetching.
In other words, if not using Flexspin's filesystem handler then using the fixed up sdspi_bashed3.spin2 is more compact and universally usable than bothering with trying to use the 4-bit sdsd.cc.
PS: I also discovered that FSRW's bugginess came from its driver, not the handler. It wasn't doing any card busy checks, amongst others.
I didn't put sdspi_bashed3.spin2 into Obex, separately. I did post it somewhere on the forums though ...
Here we go - https://forums.parallax.com/discussion/comment/1563810/#Comment_1563810
Regarding a cogged version of FSRW's driver, I never saw one. I'm thinking that only exists for the Prop1.
There is one for sure
Is it not in OBEX ?
That would be an oversight…
Hmm, I might be mistaken, maybe I just ignored it at the time and have since forgotten it was in the collection.
A better way than doing prefetching, for Flexspin's drivers at least, is to limit the use of CMD12, STOP_TRANSMISSION, for CMD18, READ_MULTIPLE_BLOCK, to only when there is a disjoint in the block order. Rather than for each cluster. I do fear such will have potential for nasty corner case bugs though.
However, it would be interesting to know what impact it could have on performance. If it goes well, then there is even potential to do the same for CMD25, WRITE_MULTIPLE_BLOCK.
Oh, it would be even better for FSRW even. Instead of adding a multi-block read function, replace the existing single-block CMD17 with a CMD18 and then implement the lazy CMD12 as well.
Oh, I'd forgotten that too, yes you did update your Obex entry - https://obex.parallax.com/obex/frsw-and-fat32-for-p2/
I found a bug with my latest, v1.2, bug fix ... With the activity LED now being turned off by lowering DIR instead of driving the pin high, this impacts the clock enable control inside the driver code in the situation where there is no LED present. The LED control gets blindly assigned to the clock pin in that situation. This is done so as to not need repeated runtime feature checks. It had no impact while DIR was left high. But now that DIRs are being lowered I needed to add one extra instruction to ensure the clock smartpin is enabled when each new SD command is issued.
I've replaced the prior sdsd_v1.2.zip file, dated 4 Apr 2025 - https://obex.parallax.com/obex/sdsd-cc/
Well, I got it working it seems. And the results are an improvement:
This actually still is a prefetching mechanism, it's just allowing the card do it on the driver's behalf. The purpose of CMD18 over CMD17 is telling the card to go ahead and prep up the next incremental block.
So I've now made more effective use of this mechanism. It needed a notable restructure of the block read function, and another clock smartpin enable instruction strategically inserted.
Next up, see if block writes can be done with lazy CMD12 as well ...
Whoa! I found a bug (Every second join became disjointed) that was slowing it down still. And I've got writes working with lazy CMD12 too! Don't need no big buffers any longer. Fast recording here we come.