You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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
Timers are currently implemented with
type Time = Hertz
. Besides the obvious oddity of using frequency as the unit for timeout times, theHertz
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.
The text was updated successfully, but these errors were encountered: