Closed ahdinosaur closed 2 years ago
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.
Hi,
I notice in the
stm32-rs
hal crates, there seems to be a move towardsfugit
(andfugit_timer
) to replaceembedded-time
.In my case, using
stm32f7xx-hal
, I was able to sort out a newtype wrapper to makestepper
happy.But am wondering, would a pull request to change
stepper
to replaceembedded-time
withfugit
be welcome?I'm not sure how this would affect non-embedded users using
std::time
.