Update embedded hal to 1.0.0

[AnyTimeTraveler]

This is based on thejpster's Pull Request #103.

The changes are suprisingly trivial.
Except for one occasion, only where-clauses needed to be adjusted.

I need to work with an ESP32C6, which has already updated to this version in a feature gate.

[thejpster]

@AnyTimeTraveler would you mind looking at the pipeline failures?

[fu5ha]

According to the docs of SpiDevice, the SpiDevice impl itself is meant to take ownership of the CS pin, and that the implementations must first assert CS pin, then perform transaction, then deassert CS pin for every call to transaction (and all other methods just defer to that implementation). This is incompatible with the current signature of SdCard in that it also expects the CS pin separately, in order to meet the requirement to clock with CS deasserted in order to get the SDMMC device to actually let go of the Spi bus, as mentioned in the SdCard docs and SD/MMC physical layer spi spec.

There's a couple possible ways to solve this. The one that would mean the least required changes to this library and I think should work well would be to encourage the use of DummyCsPin in the creation of the SpiDevice impl that gets passed to creation of SdCard such that the real CS pin is owned by SdCard and can be managed manually separately, as we desire.

[AnyTimeTraveler]

@AnyTimeTraveler would you mind looking at the pipeline failures?

Yes, I will. I'm currently still planning on testing this with my ESP32C6 to make sure that the update didn't break anything.

[AnyTimeTraveler]

@fu5ha I looked at complying with this new way of doing transactions and have found them incompatible with how the crate uses the SPI CS pin at the moment.
I agree with your approach.
I have not looked into the SD Card SPI protocol in enough depth to determine, wether the CS pin actualy needs to be held active for as long as the crate is holding it.
Maybe there is a way to handle this differently?
I will most likely move forward eith the current implementation and just use a Dummy CS Pin.

[fu5ha]

I've opened AnyTimeTraveler#1 which makes a public DummyCsPin and documents its use but you could also just cherry-pick 4d3aa31 into this branch.

[AnyTimeTraveler]

Thank you very much! I will try to find time to work on this tonight.

[thejpster]

Another solution is to require two SpiDevice objects. One which actually selects the SD card, and one which does not. You would just send out dummy bytes to the second one to get the SD card into SPI mode.

[thejpster]

Talking on the matrix channel, I'm told the correct solution is to take exclusive ownership of the SpiBus whilst we want to clock out the init sequence. How that works in practice I'm not sure.

[AnyTimeTraveler]

@thejpster I have a pretty good idea how to implement the proper solution.
It'll probably take a week or so. I don't have much free time right now.

What matrix channel were you talking about? That sounds useful to join.

[thejpster]

https://matrix.to/#/#rust-embedded:matrix.org

[thejpster]

Also it has been suggested that once we've worked out how to do this, the Embedded-HAL v1.0 docs will be updated to point here as an example.

[thejpster]

Have you had a chance to look at this? I think we're expecting Embedded HAL 1.0 to drop on 2023-12-28, with Rust 1.75.

[AnyTimeTraveler]

Sorry, I wish I had more time at the moment, but I had to put this on hold.
I expect to have more time at the start of February.
I do want to finish this, so I might squeeze it in before Christmas, but I can't promise anything.

[luojia65]

Any further works on this pull request? embedded-hal 1.0.0 (no -rc.1!) is released. If you don't feel like having enough time working on this, I can take forward (by sending PRs to your repo, or other methods); our team will test it on RustSBI and RISC-V firmware ecosystem when moving on. @AnyTimeTraveler

[jakezhu9]

@luojia65 and me have followed your work to update embedded-hal dependency to version 1.0.0. We sent a pull request to your repository: AnyTimeTraveler#2. Please have a look, hope this helps :)

[AnyTimeTraveler]

Any further works on this pull request?

Not from me, but I see your PR and will check it out tonight.
If it turns out that more work is required, I would not mind at all @luojia65 taking over :)

[AnyTimeTraveler]

Just tested locally and this should be ready to merge.
All tests are passing :)

[AnyTimeTraveler]

This PR should be good to go now.
Please poke me, if I have missed something :)

[jonathanpallant]

Thank you!