rtic migration strategy for eh-1.0

[pdgilbert]

I am trying to compile some examples with embeddeded-hal 1.0.0-rc.2 using stm32f4xx-hal from github which now uses it. One problem is that types for delay_ms and delay_us are now in embedded_hal::delay::DelayNs. This causes cortex-m-rtic = ">=1.0" to fail compiling.

Looking for a new github version I discovered that I should be migrating to rtic v2. I really want to understand the changes, async functions, etc, before I jump into that, but the bigger problem is needing to use nightly.

Since release of eh-1.0 is planned before the end of the month, is it intended that everyone using rtic will be forced to use nightly in order to switch to the release of embeddeded-hal 1.0.0? Or will there be a cortex-m-rtic with delay types from DelayNs? Or is there some other migration strategy I should try?

[pdgilbert]

After some work with rtic v2 and some further reflection I will try to answer my own question. I would appreciate pointers to anything wrong:

Switching from rtic v1 to v2 is not too difficult. There is a change in logic that takes some adjustment. It is not a disproportionately large part of the change to embedded-hal v1.0.0. Assuming rtic v1 will not be maintained as a permanent alternate to v2, then:

• No one should start a new project using v1.
• Don't expect a release of cortex-m-rtic with delay traits in DelayNs, so cortex-m-rtic will not compile for code using embedded-hal v1.0.0. There will be a forced conversion to rtic v2 for anyone wanting to use embedded-hal v1.0.0. (Developers have no interest in supporting legacy code just so I can be lazy and not make the switch.)
• The requirement to use nightly will probably be removed soon, with a new release of rust. This may even happen before the release of embedded-hal v1.0.0 at the end of December.

[andresv]

Update to embedded-hal 1.0 #879.
However in V2 nightly is still needed because of TAIT.

[pdgilbert]

This has been resolved by just moving to embedded-hal 1.0.