Upgrade to embedded-hal v1.0.0

[richardeoin]

• Use released version of embedded-hal v1.0 (when released)
• Use released version of stm32-fmc (when released) Not required
• Review I2C transaction implementation
• Implement DelayNs for Timers. After DelayFromCountDownTimer was removed DelayNs is only implemented for SysTick
• Improve the implementation of the delay_ns method in the DelayNs implementation on DelayFromCountDownTimer
• Review and update doc comments
• Low prio - add an example that uses DelayFromCountDownTimer

[pdgilbert]

I am stuck trying to create a second (non-SYST) delay. Do you have an example of how to do this now? I'm not having any luck with approaches I've used before. (Also, you might remove the example using DelayFromCountDownTimer in the comments in src/delay.rs and put in the new preferred way to do it.)

[richardeoin]

It's not possible until there's another DelayNs implementation. This trait could just be implemented directly on the Timer types, or recreate a DelayFromCountDownTimer type to avoid the confusion that delay_us/ns will override any other functions that were setup on the timer.
I'll make a note to update the documentation for each module!

[pdgilbert]

@richardeoin could you clarify "not possible until there's another DelayNs implementation". Is that another embedded-hal implementation or an stm32h7xx-hal implementation? I'm confused because I have non-SYST examples working with stm32f4xx_hal, but they may be using that hal's magic for dual support of an older embedded-hal.

[mlamoore]

Someone would have to add the implementations in this crate. I wouldn't expect it to be very complicated once you get used to how macros are used to implement the timers in this crate.

…

On Sun, Dec 24, 2023, 4:02 PM pdgilbert ***@***.***> wrote: @richardeoin <https://github.com/richardeoin> could you clarify "not possible until there's another DelayNs implementation". Is that another embedded-hal implementation or an stm32h7xx-hal implementation? I'm confused because I have non-SYST examples working with stm32f4xx_hal, but they may be using that hal's magic for dual support of an older embedded-hal. — Reply to this email directly, view it on GitHub <#476 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUS5FKINSR3YC7CZBKUKM3YLCQ7TAVCNFSM6AAAAABBAAQFC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRYGYYDANRVGY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[richardeoin]

@pdgilbert Indeed I mean that more code needs to be added to this PR. I added a very minimal implementation of DelayFromCountDownTimer now, but the doc comments do still need to be reviewed and updated.

[pdgilbert]

Ok, thanks @richardeoin. That seems to work to get some of my examples compiling. Now the main problem is device crates using eh-1. For anyone interested, the CI is in the jobs for eh-1-rc3 and eh1-rc3-dev at https://github.com/pdgilbert/rust-integration-testing/actions .

[richardeoin]

I think there is some worth in supporting both e-h v1.0 and e-h v0.2 traits to avoid dependency hell during the transition (including our own dependencies like stm32-fmc). I've implemented this a little, and rebased onto master