search

stm32-rs / stm32h7xx-hal

Peripheral access API for STM32H7 series microcontrollers
BSD Zero Clause License
209 stars 99 forks source link

Update to embedded-hal v1.0.0 #474

Open richardeoin opened 7 months ago

richardeoin commented 7 months ago

It looks like embedded-hal v1.0.0 is approaching a release :tada: . 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 commented 7 months ago

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 commented 7 months ago

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 commented 6 months ago

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 commented 6 months ago

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

pdgilbert commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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: