@"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.
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.