Time types

[TheZoq2]

I have ben working on 'drivers' for a couple of devices that can time out and while the current system works it is very clunky to work with.

To illustrate my problems, here is a usage example in which I ran into some issues. I'm trying to write a driver for the DHT11 and DHT22 temperature and humidity sensors. These sensors communicate using a timing based protocol. Since these timings are specific to the device they should probably be defined in the driver rather than by the user. However, because this crate makes no guarantees about the type of CountDown::Time it can't be specified for a generic struct.

I would therefore propose adding some time types to the embedded_hal crate which could be used by CountDown and Periodic instead. Perhaps lifting the Hertz, KiloHertz, and MegaHertz from stm32f103xx_hal could work.

Sidenote: Is there a reason that Hertz is treated as the "base" unit in those crates. It places a hard cap on the amount of time you can wait at 1 second which is slighly annoying.

[hannobraun]

I've submitted a proposal for a clock API a while ago that has some overlap with what you're discussing here. Part of my proposal was a struct, Ticks, that measures time as a number of ticks of a given clock.

In embedded-hal, any function argument that represents a time could be a of type T: Into<Ticks>, which would allow a higher-level library or application code to define types like Second, Millisecond, or whatever else is suitable, on top of that. I think this approach would be preferable to adding time types to embedded-hal itself.

So far, I haven't received any feedback on my clock API proposal, so I'd love to hear whether you think it would work for your use case.

[TheZoq2]

Oh, I somehow missed your proposal. I think using frequencies and ticks sounds like a better idea than what I have thought of. I'll close this since it's mostly a duplicate

[therealprof]

Whatever we're going to do, please keep in mind that on MCUs multiplications are borderline okay but divisions often ridiculously heavyweight so they should rather be avoided or at least avoidable e.g. by sticking to multiple-of-2 values.