Update embedded-hal dependency to 1.0

[jessebraham]

Once embedded-hal has pushed a stable 1.0 release (the latest at time of writing is 1.0.0-alpha.4), we should update our HAL to use it.

This will involve updating the dependency, then going through each peripheral and updating the imports/trait implementations/etc. until the project builds cleanly.

The stable release of embedded-hal can be tracked via this issue and this milestone.

[Tremoneck]

One of the last remaining blockers for the embedded-hal 1.0 release are missing implementations of the API to show, that the traits work fine for the drivers and hals.

I would like to help with that here. Creating this implementation directly on master is a bad idea, as that would hinder any other improvements from getting released. Creating everything in my own branch would make a massive pull request, which would be really hard to review. Also there wouldn't be any proper feedback from the experienced devs here. My suggestion is therefor to create a new branch in this repo called something along the lines of ehal-1.0 where anyone interested in could help to implement these changes already and pulling self contained updates into this branch.

Advantages:
The current proposed traits can be checked and help release ehal 1.0
When the release comes the ehal branch can be merged back into master with most/all of the implementation ready.

Disadvantages:
Some or all of the time spent could be for nothing, if the traits change substantially.

[sajattack]

Thanks for the offer of help 😄 I think it would be more beneficial to regenerate the PACs (#648), resolve the HAL breakage that causes, and then update ehal. Maintainer time is also very limited these days, so unfortunately these other issues haven't been addressed yet.

[tgross35]

Since there has been a RC (rather than alphas), it seems like a 1.0 release is close and looking for last minute feedback. See rust-embedded/embedded-hal#177 (comment)

[tgross35]

The esp-hal crate supports 1.0 under a feature flag, maybe that would be workable here? https://github.com/esp-rs/esp-hal/blob/07ed22df17f28f1b1890aa47c3ae599182397712/esp-hal-common/Cargo.toml#L23

[rursprung]

FYI: other HALs (e.g. stm32f4xx-hal or avr-hal) implement both versions at the same time. this gives drives time to migrate. you can then remove the 0.2 implementations at a later point.

this is also the recommendation in the migration guide.

[tgross35]

No need to even do that anymore, it's official :) https://blog.rust-embedded.org/embedded-hal-v1/

[rursprung]

No need to even do that anymore, it's official :) https://blog.rust-embedded.org/embedded-hal-v1/

it's still the recommendation in the migration guide to support e-h 0.2 and 1.0 at the same time for some time to come to give drivers some time to migrate. this avoids breakage in the ecosystem (though i agree that you shouldn't keep e-h 0.2 support for too long to also give driver authors & users an incentive to update 😉)

[jbeaurivage]

I would suggest we do one release with both implementations. After that, remove e-h 0.2 on the subsequent release. Drivers and apps that still rely on e-h 0.2 will then have the option to update or use https://github.com/ryankurte/embedded-hal-compat as a compatibility layer.

I'm not sure if this is the right place to discuss this, but it seems to me like the transition to e-h 1.0 looks like a great opportunity to release a 1.0 version as well. Not sure where the general sentiment stands at this point though (#334).