@rogloh said:
Same driver, different SD cards on different IO cmd/clk/data pins, right? Not actually sharing the same SD data bus (which I believe is theoretically possible in SD transfer mode); as that case seems like too much complexity.
Yes, two separate SD pins sets for two separate cards. That's how it is right now too. I have your Eval add-on uSD board at basepin 16 and a hand wired full sized SD slot I made at basepin 40.
The driver has no support for sharing the SD bus. It never deselects the card. EDIT: Err, it has to deselect to perform a CMD10 (SEND_CID) when it runs a rxlag calibration cycle.
On that note, I'd very much like to come up with a solution for using block reads instead of CMD10 to do the calibration with. The problem is there's no way to be sure the data blocks being read aren't just all zeros or all ones. I think I'd need to write data to the card storage.
@evanh said:
On that note, I'd very much like to come up with a solution for using block reads instead of CMD10 to do the calibration with. The problem is there's no way to be sure the data blocks being read aren't just all zeros or all ones. I think I'd need to write data to the card storage.
Oh, that's right, I did have an idea to attempt engaging 1.8 Volt UHS interface and see how the card handles the Prop2 staying 3.3 Volts ... if that somehow works then I can use UHS's dedicated CMD19 (SEND_TUNING_BLOCK) which uses the DAT pins.
EDIT: Nah, it'll be a bust. The Vdd supply stays at 3.3 V after UHS switchover. Which means, at the very least, the card's signalling will be too low for the Prop2 inputs at speed.
Yeah pity. That tuning block command looked useful otherwise. From my memory of old discussions, the pin comparator is slower than the streamer so it may not work at high speed. Still might be worth a quick look though to help measure latency somehow. There may still be some residual correlation between optimal read delay and the response time of the comparator to a known tuning pattern even if its initial delayed response is large due to its own bandwidth limitations. Perhaps try it anyway?
That'd be dog's breakfast. Can't operate at full speed because of the comparator's speed limit, so just projecting from something slower, and then requires power cycling and reiniting after any calibration cycle is done. UHS mode, like SPI mode, can't be switch out of without a power cycle.
And I doubt reliability of any projected method anyway.
PS: UHS would require bitDAC pin config for outputs as well. Otherwise the Prop2's 3.3 V outputs will likely lift the card's 1.8 V regulator voltage and cause a fault there.
All those differences between calibrating and full speed operation would need a lot of careful behaviour mapping to make a projection from. The death nail being that different boards with different track lengths will redefine the mappings. And possibly differences in SD cards will impact it too.
There is a couple but they're both basically empty structures. CMD10's CID structure was the best I found with a decent mix of 1's and 0's.
PS: The calibrator routine performs 12 x CMD10 for each dot, and 80 dots per rxlag setting, and 24 rxlag settings are tested. So possible 24 x 80 x 12 = 23040 issuings of CMD10. In reality a lot less. Each per dot group of 12 is checked for errors, which, when occurs, aborts that whole rxlag setting, flagging it unsuitable, moving on to next setting.
PPS: CMD10 has 136 bit (17 byte) response, including the CRC and framing.
Comments
Yes, two separate SD pins sets for two separate cards. That's how it is right now too. I have your Eval add-on uSD board at basepin 16 and a hand wired full sized SD slot I made at basepin 40.
The driver has no support for sharing the SD bus. It never deselects the card. EDIT: Err, it has to deselect to perform a CMD10 (SEND_CID) when it runs a rxlag calibration cycle.
On that note, I'd very much like to come up with a solution for using block reads instead of CMD10 to do the calibration with. The problem is there's no way to be sure the data blocks being read aren't just all zeros or all ones. I think I'd need to write data to the card storage.
Oh, that's right, I did have an idea to attempt engaging 1.8 Volt UHS interface and see how the card handles the Prop2 staying 3.3 Volts ... if that somehow works then I can use UHS's dedicated CMD19 (SEND_TUNING_BLOCK) which uses the DAT pins.
EDIT: Nah, it'll be a bust. The Vdd supply stays at 3.3 V after UHS switchover. Which means, at the very least, the card's signalling will be too low for the Prop2 inputs at speed.
Yeah pity. That tuning block command looked useful otherwise. From my memory of old discussions, the pin comparator is slower than the streamer so it may not work at high speed. Still might be worth a quick look though to help measure latency somehow. There may still be some residual correlation between optimal read delay and the response time of the comparator to a known tuning pattern even if its initial delayed response is large due to its own bandwidth limitations. Perhaps try it anyway?
That'd be dog's breakfast. Can't operate at full speed because of the comparator's speed limit, so just projecting from something slower, and then requires power cycling and reiniting after any calibration cycle is done. UHS mode, like SPI mode, can't be switch out of without a power cycle.
And I doubt reliability of any projected method anyway.
PS: UHS would require bitDAC pin config for outputs as well. Otherwise the Prop2's 3.3 V outputs will likely lift the card's 1.8 V regulator voltage and cause a fault there.
All those differences between calibrating and full speed operation would need a lot of careful behaviour mapping to make a projection from. The death nail being that different boards with different track lengths will redefine the mappings. And possibly differences in SD cards will impact it too.
Ok. Sounds dubious then at best. There's no fixed/known JEDEC like structure on the SD somewhere that can be read via block transfers?
There is a couple but they're both basically empty structures. CMD10's CID structure was the best I found with a decent mix of 1's and 0's.
PS: The calibrator routine performs 12 x CMD10 for each dot, and 80 dots per rxlag setting, and 24 rxlag settings are tested. So possible 24 x 80 x 12 = 23040 issuings of CMD10. In reality a lot less. Each per dot group of 12 is checked for errors, which, when occurs, aborts that whole rxlag setting, flagging it unsuitable, moving on to next setting.
PPS: CMD10 has 136 bit (17 byte) response, including the CRC and framing.