@"Stephen Moraco" said:
@evanh, what is the current state with v1.3.0 vs. your older card? Is the logic working?
I've done more reading of the spec and found the answer. Turns out there is a minimum of 1 byte gap and these cards are following the spec correctly. The timing diagram I posted above should have but doesn't specify the timing of relevance, Nrc. It is listed in the table but has it's own separate diagram:
Sorry for not just uploading the PDF itself. It's one I found in a Web search that is not the free edition.
I suppose, to be fair, it's not clear, from the diagram at least, if Nrc holds true after CS rises. CS high could be considered a reset so then my previous interpretation would hold. It's a little fuzzy so not surprising different manufacturers might have interpreted different ways.
Either way, it's clear the driver has to make the allowance for Nrc holding true irrespective of CS. And the best solution is to, like Flexspin's sdmm.c driver, combine it with the busy check.
@"Stephen Moraco" said:
@evanh, what is the current state with v1.3.0 vs. your older card? Is the logic working?
Every time you post an update at the moment I have to redo a huge number of debug deletes so that the important parts can report anything. Otherwise I just get compile errors of too big debug.
@evanh said:
Every time you post an update at the moment I have to redo a huge number of debug deletes so that the important parts can report anything. Otherwise I just get compile errors of too big debug.
It kind of begs the question of how have you been getting any reporting yourself, Stephen?
I am very supportive of this effort and appears off to great start.
Keep it up @"Stephen Moraco"
8.3 filenames is a serious limitation. But directory support helps a lot with that. Should be fine. FatFs can do long filenames but like triples the memory usage
I’m crazy backed up in projects but will prioritize testing this…
One minor thing to examine is support for RTC for file dating.
@evanh said:
Every time you post an update at the moment I have to redo a huge number of debug deletes so that the important parts can report anything. Otherwise I just get compile errors of too big debug.
It kind of begs the question of how have you been getting any reporting yourself, Stephen?
Augh! That is painful. The latest release, v1.3.2, now has DEBUG_MASK and "CHANNEL"s for debug output. Set the mask to a new value, recompile, and only the new selected debug channels are compiled into your code. Should be much easier. This is all documented.
I started with driver debug only, then eventually it became stable enough that I moved to disabling debug in the driver and pushing some critical state through the caller <-> backend COG interface and just reporting it via debug in the calling program. All the regression tests do this.
@Rayman said:
One minor thing to examine is support for RTC for file dating.
Useful idea. We need to brainstorm a bit about how to support this. Pretty complicated trying to support RTC devices. Pass a creation time through the file create/write method; maybe have a set date/time call for the driver to keep it updated, and use this for file creation/modification? Maybe let the app maintain the current date/time and pass a reference to the driver for use in file creation/modification? Any other ideas?
FYI- (if my understanding is correct) our FAT32 directory entries can contain (all local date time, not utc):
Stephen,
I just noticed you've made an incorrect note in the source comments about ManAtWork's clock polarity reference material. Clock mode 0 is not a necessity at all. SPI slave devices that accept clock mode 0 (CPOL=0 and CPHA=0) are also happy to accept clock mode 3 (CPOL=1 and CPHA=1). In fact bit-bashed master implementations on microcontrollers are rarely precisely mode 0 or mode 3 but somewhere in between. I regularly write routines that explicitly take advantage of this flexibility to allow higher clock rates to be used.
Now, when it comes to the Prop2 boot pins, P58/P59/P60/P61, there is a good reason to always use CPOL=1, and therefore cmode 3. The same four pins are used for both the SD card slot and the soldered Flash EEPROM chip. The difference being SCLK and CS are swapped. But that means that a clock low on one is a chip-select on the other. Things are much less likely to get into a confused state between them if the clock idles high instead of low. Hence why ManAtWork did it the way he did.
@evanh said:
Every time you post an update at the moment I have to redo a huge number of debug deletes so that the important parts can report anything. Otherwise I just get compile errors of too big debug.
Augh! That is painful. The latest release, v1.3.2, now has DEBUG_MASK and "CHANNEL"s for debug output. Set the mask to a new value, recompile, and only the new selected debug channels are compiled into your code. Should be much easier. This is all documented.
Comments
I've done more reading of the spec and found the answer. Turns out there is a minimum of 1 byte gap and these cards are following the spec correctly. The timing diagram I posted above should have but doesn't specify the timing of relevance, Nrc. It is listed in the table but has it's own separate diagram:
Sorry for not just uploading the PDF itself. It's one I found in a Web search that is not the free edition.
So adding a padding $FF byte at the end of the prior sequence, before rasing CS instead of after lowering CS, should also do the job.
I suppose, to be fair, it's not clear, from the diagram at least, if Nrc holds true after CS rises. CS high could be considered a reset so then my previous interpretation would hold. It's a little fuzzy so not surprising different manufacturers might have interpreted different ways.
Either way, it's clear the driver has to make the allowance for Nrc holding true irrespective of CS. And the best solution is to, like Flexspin's sdmm.c driver, combine it with the busy check.
Every time you post an update at the moment I have to redo a huge number of debug deletes so that the important parts can report anything. Otherwise I just get compile errors of too big debug.
Here's the relevant Adata 16GB card:
So the probeCmd13() is succeeding now. However, such a check is also defunct now that we know the why.
It kind of begs the question of how have you been getting any reporting yourself, Stephen?
I am very supportive of this effort and appears off to great start.
Keep it up @"Stephen Moraco"
8.3 filenames is a serious limitation. But directory support helps a lot with that. Should be fine. FatFs can do long filenames but like triples the memory usage
I’m crazy backed up in projects but will prioritize testing this…
One minor thing to examine is support for RTC for file dating.
Augh! That is painful. The latest release, v1.3.2, now has DEBUG_MASK and "CHANNEL"s for debug output. Set the mask to a new value, recompile, and only the new selected debug channels are compiled into your code. Should be much easier. This is all documented.
I started with driver debug only, then eventually it became stable enough that I moved to disabling debug in the driver and pushing some critical state through the caller <-> backend COG interface and just reporting it via debug in the calling program. All the regression tests do this.
Useful idea. We need to brainstorm a bit about how to support this. Pretty complicated trying to support RTC devices. Pass a creation time through the file create/write method; maybe have a set date/time call for the driver to keep it updated, and use this for file creation/modification? Maybe let the app maintain the current date/time and pass a reference to the driver for use in file creation/modification? Any other ideas?
FYI- (if my understanding is correct) our FAT32 directory entries can contain (all local date time, not utc):
Stephen,
I just noticed you've made an incorrect note in the source comments about ManAtWork's clock polarity reference material. Clock mode 0 is not a necessity at all. SPI slave devices that accept clock mode 0 (CPOL=0 and CPHA=0) are also happy to accept clock mode 3 (CPOL=1 and CPHA=1). In fact bit-bashed master implementations on microcontrollers are rarely precisely mode 0 or mode 3 but somewhere in between. I regularly write routines that explicitly take advantage of this flexibility to allow higher clock rates to be used.
Now, when it comes to the Prop2 boot pins, P58/P59/P60/P61, there is a good reason to always use CPOL=1, and therefore cmode 3. The same four pins are used for both the SD card slot and the soldered Flash EEPROM chip. The difference being SCLK and CS are swapped. But that means that a clock low on one is a chip-select on the other. Things are much less likely to get into a confused state between them if the clock idles high instead of low. Hence why ManAtWork did it the way he did.
DEBUG_MASK is working. Thank you!