EtchedPixels / FUZIX

FuzixOS: Because Small Is Beautiful
Other
2.18k stars 272 forks source link

devsd - sdcc post-decrement weirdness #758

Closed feilipu closed 4 years ago

feilipu commented 4 years ago

In this section, an optimisation for sdcc weirdness is provided.

I recently copied this method of accessing the argument bytes, but found that the sdcc code generated was still wrong. I see the post-decrement happening before collecting the byte for the sd_spi_transmit_byte() call, which means there is an off-by-one error.

I ended up with this uglier, but working outcome.

Not sure if it is just me.

EtchedPixels commented 4 years ago

Not something I have seen and that code has been in use for years. Could be that sdcc at some point recently broke it or z88dk did ?

BTW your code is also going to break if you are using typical SD adapters. The first byte response from a command is open collector so you will see random junk ditto the status before you issue your initial CMD0.

There's another corner case too (which I need to fix in Fuzix), if you crash in the middle of a write and reboot then CMD0 is not enough to recover. Some of the other stacks do it better.

feilipu commented 4 years ago

Probably just my bad reading of the assembly code. Now that my stuff is working, I'll put back your original method, and read the assembly more closely. Then check back if I'm still seeing it.

For the initialisation, I'm expecting junk for period of time. Once I get my head around the timer options from ROMWBW or SCM, I'll add the timeouts back in to the code, which are needed in many places.

The initial lowering of the CS line is done by sd_cs_lower during the initialisation code and not done by select(), because select() would be susceptible to open collector generated junk or a low MISO, as you point out.

There is a deselect() select() cycle before every normal command, which covers off open collector for other situations.

Do you have a reference for the other stacks, please? I would like to learn how to try to make the code more robust, too.

EtchedPixels commented 4 years ago

https://github.com/greiman/SdFat

(It's not my original method btw - Will Sowerbutts came up with that particular hack and wrote the core of the SD driver)

feilipu commented 4 years ago

Thanks for the reference. :+1: Checked post decrement again, and found that it was done totally correctly.

Also, added in a few things from the grieman repo too. Looks much better now without unnecessary embellishments, and uses registers rather than stack where possible.