Update to embedded-hal v1.0.0

[richardeoin]

It looks like embedded-hal v1.0.0 is approaching a release 🎉 . Within a reasonable time frame after release (3 months? 12 months?) this crate should be updated to use v1.0.0.

There is a PR here, but it is likely very out-of-date at this point. However it should provide some hints about what needs doing.

[olback]

I think it would make more sense to migrate to e-h 1.0.0 as soon as possible to encourage/allow driver/lib authors to also update their crates to 1.0.0. You can always use an older version of this HAL if you need compatibility with pre-1.0.0 e-h.

e-h is scheduled for release 28th of December, same day as Rust 1.75.0.

[adamgreig]

It's also possible to support both simultaneously, which stm32f4xx-hal does for example. That way the support for e-h 0.2 can remain in place even as most users migrate to 1.0, and there's no hard switchover.

[pdgilbert]

I think the stm32f4xx-hal approach of supporting both is useful for a short transition period that is soon ending. The tree for code using both is pretty ugly and suggests long term support issues. My guess is that device crate maintainers will switch pretty quickly. (At least if the maintainers are active, and do you really want to support legacy crates with inactive maintainers?) The problem at the moment is the lack of 'hal' crates using e-h 1.0.0 release candidates. AFAIK stm32f4xx-hal is the only one, and it solves the problem so well that device crate maintainers may think there is nothing they need to do.

My suggestion is to put out an e-h 1.0.0 branch as soon as possible and reconsider the dual support possibility in a month or two when the dust settles after the change-over.

[richardeoin]

There's now a non-backwards compatible eh v1.0 branch here, and a corresponding PR in #476. Contributions / PRs / Reviews are welcome!

[pdgilbert]

I have been testing embedded-hal-1.0.0-rc3 using stm32h7xx-hal branch eh-v1.0. Results are good except, of course, when I try to use device crates that do not have embedded-hal-1.0.0-rc3. A summary is at https://github.com/pdgilbert/rust-integration-testing/actions in the eh-1-rc3 workflow runs.

One problem occurs with examples serial_char and oled_gps. These have a serial interface reading and writing a character 'byte' value. With embedded-hal "^0.2.4" I used read() and write(byte) methods but now I need read_byte() and write_byte(byte) methods. Hal stm324fxx-hal does not compile with read_byte() and write_byte(byte) but still does compile with read() and write(byte). However, because of the dual eh support in stm324fxx-hal it seems difficult to know if this is using embedded-hal' '1.0.0-rc3 or ^0.2.4.

I think read() and write(byte) should work using traits in embedded-hal-1.0.0 but the migration document is a bit hard for me to understand regarding the serial interface. Guidance would be much appreciated.

(Also, I am looking for more device crates using embedded-hal-1.0.0-rc3.)

[richardeoin]

Hi @pdgilbert . Great that you are trying out the eh-v1.0 branch and thanks for the feedback!

embedded-hal 1.0 doesn't include traits for serial interfaces. Instead the documentation recommends using embedded-io. This does have traits for serial interfaces, but there are no methods specifically for single byte operations. In the eh-v1.0 branch I retained the convenient methods read_byte() and write_byte(byte), but these are not implementing any trait. They are just methods on the Serial types that another HAL may or may not implement.

I guess the read() and write(byte) methods you're using in stm32f4xx-hal are implementation of traits from embedded-hal 0.2. embedded-hal 1.0 doesn't have these and stm32f4xx-hal doesn't seem to be using embedded-io yet.

[pdgilbert]

I have switched to embedded-hal-1.0.0 and updated using stm32h7xx-hal branch eh-v1.0 and an eh-1 fork of stm32f4xx-hal by @rursprung. There are no changes in my tests relative to rc3. Results are available in the eh-1 workflows runs at https://github.com/pdgilbert/rust-integration-testing/actions.

Thank you for the explanation @richardeoin . To deal with read/write bytes I am using code like

    #[cfg(feature = "stm32f4xx")]
    block!(tx1.write(received)).ok();
    #[cfg(not(feature = "stm32f4xx"))]
    block!(tx1.write_byte(received)).ok();

This is not ideal but I will let the dust settle after the release before looking for something better.

The summary of my example tests is:

• Many device crates are not yet eh1 so those examples all fail with stm32h7xx-hal.
• Many of the same examples also fail with stm32h7xx-hal because shared_bus is not eh1.
• The dual eh support in stm32f4xx lets most crates work, but shared_bus does not work when it is sharing the bus with an eh1 version of ssd1306. (See sandwiched eh versions failure stm32f4xx-hal#722.) Thus, most of the examples failing on stm32h7xx-hal also fail on stm32f4xx.
• If I use an older version of the ssd1306 crate then almost all the examples work with stm32f4xx but more fail with stm32h7xx-hal.