uSD drivers FSRW + Fat32 (2026 update)
Been a bit remiss in FSRW (and Fat32) maintenance duty, so thought time for some updates...
First, think should only use "sdspi_bashed3.spin2" for the low level sdspi driver object under FSRW.
Maybe some of the other options work, but trusting this most as was updated by @evanh
This was included in the last update, some time ago:
https://obex.parallax.com/obex/frsw-and-fat32-for-p2/
Second, switching from actual serial output to debug serial terminal output as default.
Be sure to enable Debug to see output.
But, easy to switch to real serial output with change in ser object.
Also, making this maybe more simple example, ExampleA.spin2
Lots to add (including Fat32 support), but starting with this...
Ok, seems Fat32 was already supported in low level driver, bashed3, in ExampleA for FSRW, and maybe other low level drivers as well.
Just posted Fat32 test here.
Fat32 offers more features (like directory support) that FSRW, but is bigger and perhaps harder to use...


Comments
FSRW will (hopefully) be replaced by this new driver here:
https://forums.parallax.com/discussion/178033
But for now, FSRW has these advantages:
1. Doesn't need a cog (if using one of the "bashed" drivers)
2. Works with most compiler tools. Runs as expected in PropTool, Spin Tools IDE, and PNut. Runs in FlexProp, but debug terminal window doesn't work there.
3. Low level driver can also work with the Fat32 code, also from P1 (need to update this probably)
4. Very small footprint
5. Can work with newish 4-bit hardware for super fast I/O (by @evanh and @rogloh )
Just remembered that needed to tweak FSRW a hair to work with Fat32:
https://forums.parallax.com/discussion/175378/
May need to adjust ExampleA to match this...
Guess should also add something here about 4-bit mode support
Ray,
May I suggest a small update? Until I did this I had problems. Most methods return 0 if everything is fine, and my code generally looks for that. In this method the return variable is used in the SDHC test which will cause the method not to return 0, even on a good mount, if you have an SDHC. I added r := 0 after this test and everything worked as expected.
@JonnyMac Think this is included in that Fat32 version, but I'll double check...
I'm also wanting to change all drivers so that default pins are constants that can be overridden in the OBJ section. But, that will have to wait a bit until get Fat32 working again with FSRW here...
Ok, think seeing now that FSRW doesn't need to change for Fat32, but the low level block driver "bashed", etc.
Seems that first post example already has that modified low level driver...
@JonnyMac Seems that it is now FATEngineStart() that needs that change and did it.
See now that FSRW was already adapted to work with Kye's FAT32 code...
In Mount_explicit(), start_explicit used to do the work, but now it just sets pins... MountCard() is what now does the work...
sdspi.start_explicit(DO, CLK, DI, CS) 'debug("Mount Card.") 'To be compatible with Kye driver, need to complete init with call to mountcard() if (r := sdspi.mountCard()) <0 'this now returns card type return r 'RJA needs to know card type for fast assembly helper... if (r==2) bIsSDHC:=1 'debug("bIsSDHC:=1") else bIsSDHC:=0 'debug("bIsSDHC:=0")