-
Notifications
You must be signed in to change notification settings - Fork 234
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
Comments
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, In embedded-hal, any function argument that represents a time could be a of type 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. |
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 |
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. |
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
andPeriodic
instead. Perhaps lifting theHertz
,KiloHertz
, andMegaHertz
fromstm32f103xx_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.The text was updated successfully, but these errors were encountered: