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

HAL: More precise units for timers. #7

Open
agausmann opened this issue Sep 4, 2021 · 2 comments
Open

HAL: More precise units for timers. #7

agausmann opened this issue Sep 4, 2021 · 2 comments

Comments

@agausmann
Copy link

Timers are currently implemented with type Time = Hertz. Besides the obvious oddity of using frequency as the unit for timeout times, the Hertz wrapper type is also limited to integer values, which severely restricts the possible periods/frequencies that can be set for a timer.

This isn't a problem at the kHz or MHz scale, but at low audible frequencies (like the low end of the range of MIDI music notes), it's just not enough precision. At the very lowest values, the differences between frequencies are <1Hz, and above those, the frequencies are still noticeably out of tune until they reach a scale where integers provide enough precision.

@agausmann
Copy link
Author

agausmann commented Sep 4, 2021

As a counterexample, the atsamd-hal crate implements their timer-counters using a Nanoseconds type, which would provide the precision that I'm looking for.

@Sh3Rm4n
Copy link
Member

Sh3Rm4n commented Sep 6, 2021

I've used the type Time = embedded_time::duration::Generic<u32> approach in stm32f3xx-hal, which might not be the most efficent solution (size wise as value and fraction has to be saved separately in a struct) but results into nice to use APIs IMO, where you also have the more freedom about the precision.

But I think, for use cases like yours, where the frequency has to be very accurate so they error margin are unaudible, I don't know if there is a nice API to abstract this or if the timer implementations have to expose their scaler values (PSC and ARR as they are abreviated for stm32) directly to fine tune the values

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

2 participants