Time-related units crate for microcontrollers?

I'm working on an embedded-hal implementation for the STM32F2 series of microcontrollers. I'm working on a fork of GitHub - mike7b4/stm32f2xx-hal: stm32f2xx Hardware abstraction layer since the author let me know that he doesn't have time at the moment to maintain or develop the crate. My fork is located at GitHub - L0uisc/stm32f2xx-hal: stm32f2xx Hardware abstraction layer

I'm noticing the time.rs module. It's copied from the stm32f4xx-hal crate. I think it is a really good module to make typesafe wrapper newtypes around integers to use for all kinds of timing-related values in microcontrollers.

Now my question is, does such a crate already exist? If so, where? If not, what would be the procedure to publish that file as a crate. Obviously, it would need to be published under the same license as the original.

I don't see that the time crate does exactly that. It is more of a date-time crate, not about frequency and small time intervals. @jhpratt if you plan on including this use-case, please get in touch.

One option is of course to implement the generic API in embedded-hal, but then lower-level crates miss out on it.

What do you think is the best way forward?

The embedded-time crate tries to address this



Reading the embedded-time docs, I see that it has a lot of nice tools for time-based things in embedded context. However, it is a lot more bespoke than the HAL needs. Is it considered good practice in embedded Rust to take a whole new dependency if the alternative is <100 loc? Especially since the PAC already has ~40 dependencies and takes quite a bit of time to compile.

I am not sufficiently familiar with embedded to create a widely-usable crate for it. As was mentioned, I know the embedded-time crate exists, which takes inspiration (and a bit of code) from the time crate. Note that the time crate shouldn't include something that is only useful for embedded, as it's meant to be widely applicable. That said, I could likely be convinced to include some more things :slightly_smiling_face:

1 Like

There are two main reasons people will split code out into its own crate:

  • The code is all logically related and other people may want to use it without having to pull in the rest of your library/application as a dependency
  • To define a common interface that the ecosystem can use, allowing better interoperability

Crates like rayon and reqwest fall into the former category, providing a one stop shop for all your concurrency or HTTP client needs.

Crates like embedded-time, http, and embedded-hal fall into the latter category; they don't expose much functionality themselves, but they give the ecosystem common types that you can build web frameworks or embedded drivers/applications on top of.