Skip to content

Time types #46

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
TheZoq2 opened this issue Feb 27, 2018 · 3 comments
Closed

Time types #46

TheZoq2 opened this issue Feb 27, 2018 · 3 comments

Comments

@TheZoq2
Copy link

TheZoq2 commented Feb 27, 2018

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
Copy link
Member

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
Copy link
Author

TheZoq2 commented Feb 28, 2018

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

@TheZoq2 TheZoq2 closed this as completed Feb 28, 2018
@TheZoq2 TheZoq2 mentioned this issue Feb 28, 2018
@therealprof
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants