I guess I should fix that before looking at A2 extensions. EDIT: Not that I can test it. I think even my oldest full sized SD card was HC from the start. It'll be theoretical support until someone else can test it.
EDIT2: Ah, no, I have one 2GB miniSD card in an adaptor, that was pushed on me at the time. It would have been my second flash card purchased after the rather expensive 2GB Compact Flash in the DSO.
Here's the untested support for SDSC (up to 2 GB capacity) cards.
Install instructions - https://forums.parallax.com/discussion/comment/1562218/#Comment_1562218
PS: Make sure you put this in the sdfatfs directory. Not the fatfs directory.
EDIT: I can see this as an accident waiting to happen. Maybe a new file name is in order ...
EDIT2: Okay, renamed and a couple of comment clean ups. Also improved the tester program to perform mounting steps before first fopen().
EDIT3: Added a 500 ms timeout to power-down step of power cycling.
EDIT4: Separated init debug messages from performance debug messages
EDIT5: for()-loop compiler bug workaround
EDIT6: Fixed a bug in speedtester's file verify routine
Huh, there's quite a generational style difference in the extensions in the SDv6 spec. All the documentation up to SDv3 is big-endian oriented, but that flips to little-endian thinking with the extensions. Clearly, new blood arrived in between.
EDIT: The cache setting bits aren't very well documented. It doesn't mention what command or register names are being worked with. It's just these etherial bit and byte numbers.
EDIT2: Looks like everything is via commands 48 and 49:
@evanh said:
Huh, there's quite a generational style difference in the extensions in the SDv6 spec. All the documentation up to SDv3 is big-endian oriented, but that flips to little-endian thinking with the extensions. Clearly, new blood arrived in between.
EDIT: The cache setting bits aren't very well documented. It doesn't mention what command or register names are being worked with. It's just these etherial bit and byte numbers.
EDIT2: Looks like everything is via commands 48 and 49:
Yes, all CMD49. Kind of funny that you need to send 511 dummy bytes to set one bit.
Also, fun fact about the SD spec: You can get rid of the watermark by disabling it in the "Layers" menu (at least in Okular)
Yeah, Okular doesn't remember the setting though. It doesn't bug me anyway.
And it doesn't work for secured PDFs either, so useless on the whole. EDIT: Or maybe its lacking layers or something. Whatever it is it doesn't always work.
Yeah, some watermarks are just not broken like that. Also note the "Obey DRM limitations" checkbox in settings, gets around any "security" without futzing.
Seems my setup is failing to read the first block in 4 bit mode, no matter clock speed. Only thing I can think of is the series resistor, but that seems like a stretch…
Also, guess I have all pull-ups in fet side were you have one on the rail. Could that matter?
@Rayman said:
Seems my setup is failing to read the first block in 4 bit mode, no matter clock speed. Only thing I can think of is the series resistor, but that seems like a stretch…
It's a lock-up too isn't it? That's not supposed to be possible there. The SE2 wait has a timeout so it can't be that one. That means it's somehow getting stuck on a WAITSE1. Which is the smartpin complete event of clocking.
Also, guess I have all pull-ups in fet side were you have one on the rail. Could that matter?
The red activity LED doesn't matter at all. It's purely for visuals.
@Rayman said:
Seems my setup is failing to read the first block in 4 bit mode, no matter clock speed. Only thing I can think of is the series resistor, but that seems like a stretch…
Also, guess I have all pull-ups in fet side were you have one on the rail. Could that matter?
When it's all powered up and source+drain are at the same voltage it shouldn't matter as much, but the SD card could be getting parasitically powered prior to FET enable through these pullups on the P2 supply side which isn't ideal. Not a clean way to start up.
At low speeds the missing series resistor is probably not so important but could be when the data is clocked faster. Maybe try lowering the P2 clock speed if you can with evanh's code.
Try setting-D NOREADBLOCKCRC on the compile line. Or commenting out the #define SD_BLOCK_CRC in the driver. That changes the read blocks structure notably.
I haven't updated flexspin in a while: Version 7.0.0-beta-v6.9.7-62-g0917374f Compiled on: Jul 12 2024
I'll park that idea without some more evidence first though.
Grab the driver at the top of this forum page. It has the block performance debugging option that I used for examining the behaviour of the filesystem. Uncomment the #define SD_DEBUG_PERFORMANCE That'll tell us if any blocks are read or written successfully.
PS: The diskio.h file is also updated in the zip file, That's to handle the renamed driver.
@evanh said:
I haven't updated flexspin in a while: Version 7.0.0-beta-v6.9.7-62-g0917374f Compiled on: Jul 12 2024
I'll park that idea without some more evidence first though.
Actually looks pretty quiet on the compiler changes front. Eric has been working on new feature not yet ready and has been busy at his work.
Since July, looks like just the littlefs changes and float_to_int bounding change.
I've now updated to very latest master branch: Version 7.0.0-beta-v6.9.7-67-g479049f9 Compiled on: Oct 14 2024
@evanh said:
I haven't updated flexspin in a while: Version 7.0.0-beta-v6.9.7-62-g0917374f Compiled on: Jul 12 2024
I'll park that idea without some more evidence first though.
Actually looks pretty quiet on the compiler changes front. Eric has been working on new feature not yet ready and has been busy at his work.
Since July, looks like just the littlefs changes and float_to_int bounding change.
I've now updated to very latest master branch: Version 7.0.0-beta-v6.9.7-67-g479049f9 Compiled on: Oct 14 2024
Oh! Actually, there was a fix Eric did for me not that long ago. It's in the v7.0.0 fixes list. It was a misbehaviour of for() loops when using an unsigned control variable. You'll need to update to newest Flexspin compiler on top of the newest Flexprop IDE.
EDIT: On second thoughts. There is only a single for() loop in the entire driver. It can happily be changed to using signed integers. I'll do that ... done.
??? why does it flush the file before writing? That makes no sense and seems like it would destroy performance when doing small-sized writes. It does the same thing in fread. Why?
No idea why blockcrc doesn't work here.
But was poking around the previous code and see that seems to have trouble finding the FAT volume.
It does find the MBR signature, but then gets lost...
@Wuerfel_21 said:
??? why does it flush the file before writing? That makes no sense and seems like it would destroy performance when doing small-sized writes. It does the same thing in fread. Why?
Comments
I guess I should fix that before looking at A2 extensions. EDIT: Not that I can test it. I think even my oldest full sized SD card was HC from the start. It'll be theoretical support until someone else can test it.
EDIT2: Ah, no, I have one 2GB miniSD card in an adaptor, that was pushed on me at the time. It would have been my second flash card purchased after the rather expensive 2GB Compact Flash in the DSO.
Here's the untested support for SDSC (up to 2 GB capacity) cards.
Install instructions - https://forums.parallax.com/discussion/comment/1562218/#Comment_1562218
PS: Make sure you put this in the
sdfatfsdirectory. Not thefatfsdirectory.EDIT: I can see this as an accident waiting to happen. Maybe a new file name is in order ...
EDIT2: Okay, renamed and a couple of comment clean ups. Also improved the tester program to perform mounting steps before first fopen().
EDIT3: Added a 500 ms timeout to power-down step of power cycling.
EDIT4: Separated init debug messages from performance debug messages
EDIT5: for()-loop compiler bug workaround
EDIT6: Fixed a bug in speedtester's file verify routine
Huh, there's quite a generational style difference in the extensions in the SDv6 spec. All the documentation up to SDv3 is big-endian oriented, but that flips to little-endian thinking with the extensions. Clearly, new blood arrived in between.
EDIT: The cache setting bits aren't very well documented. It doesn't mention what command or register names are being worked with. It's just these etherial bit and byte numbers.
EDIT2: Looks like everything is via commands 48 and 49:
@evanh does your code work with dat0 on P40?
Yep. Tested now with bases P16, P32, P40 and P48. All four runs behaved the same.
Eg:
And with debugging:
Yes, all CMD49. Kind of funny that you need to send 511 dummy bytes to set one bit.
Also, fun fact about the SD spec: You can get rid of the watermark by disabling it in the "Layers" menu (at least in Okular)
Yeah, Okular doesn't remember the setting though. It doesn't bug me anyway.
And it doesn't work for secured PDFs either, so useless on the whole. EDIT: Or maybe its lacking layers or something. Whatever it is it doesn't always work.
Yeah, some watermarks are just not broken like that. Also note the "Obey DRM limitations" checkbox in settings, gets around any "security" without futzing.
Seems my setup is failing to read the first block in 4 bit mode, no matter clock speed. Only thing I can think of is the series resistor, but that seems like a stretch…
Also, guess I have all pull-ups in fet side were you have one on the rail. Could that matter?
I've updated the files at top of this page.
It's a lock-up too isn't it? That's not supposed to be possible there. The SE2 wait has a timeout so it can't be that one. That means it's somehow getting stuck on a WAITSE1. Which is the smartpin complete event of clocking.
The red activity LED doesn't matter at all. It's purely for visuals.
When it's all powered up and source+drain are at the same voltage it shouldn't matter as much, but the SD card could be getting parasitically powered prior to FET enable through these pullups on the P2 supply side which isn't ideal. Not a clean way to start up.
At low speeds the missing series resistor is probably not so important but could be when the data is clocked faster. Maybe try lowering the P2 clock speed if you can with evanh's code.
Try setting
-D NOREADBLOCKCRCon the compile line. Or commenting out the#define SD_BLOCK_CRCin the driver. That changes the read blocks structure notably.@evanh Definitely happier with that define commented out...
This is what get now:
Some of this output may be stuff I added...
Probably should revert to original version and try again...
Guess the layout could be wrong as never used all four data pins before... Going to triple check that...
Updated the driver in the zip file at top of page again.
@evanh what version of flexprop are you using?
Something very strange going on with tx_datablock( )...
Seems to go off the rails after the first __asm block...
Tried old Flexprop, no joy.
Added series resistors, still not working.
Is not working at all with block CRC a sign that something is wrong?
I haven't updated flexspin in a while:
Version 7.0.0-beta-v6.9.7-62-g0917374f Compiled on: Jul 12 2024I'll park that idea without some more evidence first though.
Grab the driver at the top of this forum page. It has the block performance debugging option that I used for examining the behaviour of the filesystem. Uncomment the
#define SD_DEBUG_PERFORMANCEThat'll tell us if any blocks are read or written successfully.PS: The
diskio.hfile is also updated in the zip file, That's to handle the renamed driver.Any chance it’s the way the card was formatted?
Are your cards formatted with windows?
Isn’t the files posted here for drives <2 gb?
Actually looks pretty quiet on the compiler changes front. Eric has been working on new feature not yet ready and has been busy at his work.
Since July, looks like just the littlefs changes and float_to_int bounding change.
I've now updated to very latest master branch:
Version 7.0.0-beta-v6.9.7-67-g479049f9 Compiled on: Oct 14 2024That's a good reason to look at the filesystem's block access sequence.
Nope, I don't have any uSD cards that small to test with. I added the ability but it's still to be tested.
Oh! Actually, there was a fix Eric did for me not that long ago. It's in the v7.0.0 fixes list. It was a misbehaviour of for() loops when using an unsigned control variable. You'll need to update to newest Flexspin compiler on top of the newest Flexprop IDE.
Here it is https://forums.parallax.com/discussion/comment/1560438/#Comment_1560438 fixed early July.
EDIT: On second thoughts. There is only a single for() loop in the entire driver. It can happily be changed to using signed integers. I'll do that ... done.
[Note to self]
include/libc/stdio/fwrite.cmodified (removal of fflush() call) to better streamline use of SD cache extension.size_t fwrite(const void *ptr, size_t size, size_t n, FILE *f) { size *= n; fflush(f); return _vfswrite(f, ptr, size); }??? why does it flush the file before writing? That makes no sense and seems like it would destroy performance when doing small-sized writes. It does the same thing in fread. Why?
@evanh It's the same story:
Like before, does better with blockcrc off:
No idea why blockcrc doesn't work here.
But was poking around the previous code and see that seems to have trouble finding the FAT volume.
It does find the MBR signature, but then gets lost...
Rayman,
Turn on
SD_DEBUG_PERFORMANCEso we can see if any blocks are successful. It looks like nothing is working because it can't even read the MBR.Heh, I'm glad you're surprised by that too.
Does seem to get further with a Mac formatted disk: