Skip to content
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

Tracking issue for timer traits #359

Open
eldruin opened this issue Feb 13, 2022 · 5 comments
Open

Tracking issue for timer traits #359

eldruin opened this issue Feb 13, 2022 · 5 comments

Comments

@eldruin
Copy link
Member

eldruin commented Feb 13, 2022

The timer traits available on the 0.2.x versions have been removed ahead of the 1.0.0 release. See: #357
This issue servers as a tracking issue until we add them back. The open (breaking) problems should be reasonably-well solved and all associated types should have appropriate bounds that enable generic code use.

Timer traits as of the 0.2.7 release:

Relevant issues/PRs:

Please feel free to participate, highlight your current use cases, problems and provide solutions.

@niclashoyer
Copy link

niclashoyer commented Feb 13, 2022

Unbounded time constraints are really cumbersome to work with. I'm currently using the timer traits (mainly CountDown) for signal detection (detect pin changes and check time between changes) and generation of such signals using bit banging.

To work around the several different types implemented by peripheral crates I currently use drogue-embedded-timer as a wrapper. My driver crates use embedded-time, which works quite well, but may be a bit overkill to integrate this completely in embedded-hal.

I don't really need all the features in embedded-time. I mainly use timers in us or ms range. It would be really nice if we could get back timer traits with a constrained minimal Duration like type, to express delays (us, ms) or periodic (hz) in a platform independent way.

@burrbull
Copy link
Member

burrbull commented Feb 14, 2022

To work around the several different types implemented by peripheral crates I currently use drogue-embedded-timer as a wrapper. My driver cartes use embedded-time, which works quite well, but may be a bit overkill to integrate this completely in embedded-hal.

As I can see drogue-embedded-timer forces you to specify precision.
Have you thought about using fugit::TimerDuration (specifies precision as const generic frequency) for this instead of embedded-time which is more suitable for dynamic-presicion timers?
Disadvantage: you need to add const-generic parameter in your drivers:
https://github.com/BlackbirdHQ/atat/blob/73a9830fe9f8084bce118289a460a90c73a8c598/atat/src/client.rs#L59
Advantage: all possible conversions are guarantied to work in compile time:
https://github.com/BlackbirdHQ/atat/blob/73a9830fe9f8084bce118289a460a90c73a8c598/atat/src/client.rs#L73
Timer implementation example:
https://github.com/stm32-rs/stm32f4xx-hal/blob/master/src/fugit/counter.rs
CountDown usage example:
https://github.com/stm32-rs/stm32f4xx-hal/blob/master/examples/timer-periph.rs

@niclashoyer
Copy link

Using const generics to handle the conversions at compile time seems very compelling. I'll give that a shot.

@Ben-Lichtman
Copy link

Ben-Lichtman commented Mar 19, 2022

IMO time is non-trivial enough that I think something like embedded-time should be integrated into embedded-hal - It's complex, but for a good reason.

@dlkj
Copy link

dlkj commented Jun 15, 2022

Highlighting a use case.

I'm the owner of usbd-human-interface-device the crate aims to provide a high level library for building USB HID on any embedded-hal/usb-device supported platform.

Implementing the full HID spec functionality requires keeping track of time-outs that are set by the host machine and ensuring that idle responses are sent if the time-out occurs. I'm currently assuming the use of embedded-time as I predominantly use the rp-hal platform for development but I've recently become aware of fugit and that there isn't a consensus among hal implementations. An additional layer of complexity is users using RTIC and wanting ergonomic integration at that level of abstraction.

I'd love a mechanism in hal that either provides a real time clock that can be polled or a mechanism to set timers. Hardware timers aren't really appropriate, I'm interested in knowing if no data has been sent for x ms rather than having a regular interrupt/clock tick.

Currently I'm using embedded_time::clock::Clock - this gives me both a way of getting the current time and setting arbitrary timers. Not requiring ownership of the clock is particularly useful.

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

No branches or pull requests

5 participants