embedded-time vs fugit

[ahdinosaur]

Hi,

I notice in the stm32-rs hal crates, there seems to be a move towards fugit (and fugit_timer) to replace embedded-time.

In my case, using stm32f7xx-hal, I was able to sort out a newtype wrapper to make stepper happy.

But am wondering, would a pull request to change stepper to replace embedded-time with fugit be welcome?

I'm not sure how this would affect non-embedded users using std::time.

[hannobraun]

I'm not following the ecosystem closely these days, so I don't have a clear opinion here. But if you're observing such a trend, I'm happy to trust your judgement. Any trend towards fugit certainly isn't a surprise, given it's newer than embedded-time, and its author is a former(?) user/contributor of embedded-time, as well as a central figure in the Embedded Rust world.

So yes, such a pull request would be welcome.

I'm not sure how this would affect non-embedded users using std::time.

I don't think it will? I'm not aware of any compatibility between embedded-time and std::time, and Stepper itself only supports embedded-time so far.

---

A note about how this could potentially develop in the future: Given #137, and the probable need to define our own traits to stay up-to-date with the latest versions of everything, this could be an opportunity to support both embedded-time and fugit, by defining appropriate traits and providing implementations.

But I'm fine with only supporting the more popular/promising one. I'm just noting the possibility, if the need should arise.