start adding argument and response module

[robamu]

Nice types for SD mode arguments and responses using bitbybit

[thejpster]

Looks good, but I see these types aren't yet used. Is there a plan to use them?

[robamu]

for now, these can be used for implementing SD drivers in separate crates. Implementing a generic SD driver which use these inside the library could work, but a generic transport trait to send CMDs/ACMDS is required first and I am not fully sure how well that works.

[robamu]

rebased again

[thejpster]

Looks ok, but I think we need some kind of example to show how to use them. How hard would it be to build a fake SD Card with an API to send requests and get responses that an example can drive in a similar way to how you would initialise an actual SD Card?

[robamu]

hmm. probably okay? For most responses, it is relatively clear what the SD card needs to send back, or at the very least what is relevant. I can look into this. If we do something like that, we should write to so it can be re-used for tests.

[robamu]

I added a SdCardMock which is basically a virtualized SD card. currently, I only implemented the internal state machine to allow performing the SD card initialization with it.

[robamu]

In the SD card example, we could still implement the primary SD driver traits.. this makes it a bit clearer how everything fits together I suppose.

[robamu]

The initialization sequence I implemented is really similar to the ones I implemented for the SAM9G20 SD controller and the Z7 SD controller. the only thing i strongly simplified is that I do not handle the case of pre V2 SD cards where there is not CMD8 reply. for that, I would have to add some sort of way to simulate CMD timeouts.

[robamu]

I am onto adding support for alternative mockinng modes (SD1, SD2, SDHC) :)

[thejpster]

Looks comprehensive, thanks!