Feature gate [email protected] implementations, rename eh1 feature to embedded-hal

[jessebraham]

Opening this as a draft, as I haven't really discussed this with anybody else yet 😁

Many of our APIs are currently quite tightly coupled to the embedded-hal packages, and I would like to begin working towards rectifying this.

This PR serves as a first step, and will allow us to build the HAL without any embedded-hal traits being implemented, which should rather quickly show us what we need to fix I'd imagine. I've left the embedded-hal-02 feature enabled by default, so this shouldn't really change anything from the user's perspective quite yet. I guess we will need to discuss our plans regarding these packages moving forward.

This leaves the TWAI driver in a bit of a weird spot for now, but see #1123 for more details (this issue should be prioritized sooner than later, I think).

Closes #849

[jessebraham]

cc @MabezDev @bjoernQ

[bjoernQ]

Generally fine. Not sure about the embedded-hal-1 -> embedded-hal renaming. I guess it could be somewhat confusing that the embedded-hal feature changed its meaning from eh0.2 to eh1.0

Maybe having embedded-hal-02 and embedded-hal-1 would be more explicit

[jessebraham]

I don't think that the embedded-hal feature using the latest stable release of the package is especially confusing, personally. I also wanted to outright remove the old trait implementations, but there was push back there.

The old eh1 feature was originally intended to be temporary, as I naively thought that [email protected] would take <4 years to get out, so it was poorly named from the get-go.

I guess we can see what other people think.

[bjoernQ]

I don't think that the embedded-hal feature using the latest stable release of the package is especially confusing, personally.

It's not confusing on its own - I just meant it's confusing that an existing feature changed what it is doing. Just tried to think about it from a user's perspective who wants to update their projects. It's also just a comment - not really an opinion

But I totally agree - let's hear other's voices

[burrbull]

I recommend to move hal implementations to inner modules. See https://github.com/stm32-rs/stm32f4xx-hal/blob/master/src/gpio/hal_02.rs

Also I see you don't use inherent infallible set_high pin methods. Is there any reason?

[MabezDev]

LGTM! I'm indifferent about the impls being in a module or as they are now - I'll let someone else decide that :).

[bjoernQ]

LGTM - I think having the impls in modules looks cleaner but probably something for a follow up PR (if we want that)