Provide more low-level access to the timers (prescaler, read value)

[Windfisch]

Hi,
for my project I need to use a timer as a "periodic stopwatch", with a manually set prescaler and auto-reload-register (actually, uint32_max is fine for me).
I would measure time between two events by just reading out the counter and subtract it from the old counter value; if the u32 subtraction wraps, this would lead to the right result (this works as long as the delay between two events is less than 2^32 timer ticks).

For now, I've hacked in the functions I require here: master...Windfisch:timer_additions
Basically, this allows me to

1. configure a timer with a manual prescaler and arr value (start_raw())
2. read out the timer's current count (cnt())
3. read the timer's peripheral clock's frequency (clk())

Do you think such an API would be a useful addition to the HAL, and do you have any suggestions on how to improve my quickly-hacked-together API?

[TheZoq2]

Have you seen the micros_since function?

It sounds like what you're looking for to me, though it isn't included in the current version on crates.io. Which reminds me, we should probably do another release soon

[Windfisch]

I've seen it while digging through the code. However, I want to precisely measure audio frequencies using as few periods as possible. And when measuring 440Hz (where rising/falling edges come in at 880Hz), plus minus one microsecond is already ±2cents (i.e., 2/100 of a semitone), which is too much.

Also, I am relying on the wrapping behaviour of a time, which makes my measurements very comfortable. I don't think this could be replicated using micros_since.

Restarting the timer on every measurement will likely introduce some skew, because the timer is stopped for a very short moment of time.

Do you see a way to do this using the existing API?

[TheZoq2]

And when measuring 440Hz (where rising/falling edges come in at 880Hz), plus minus one microsecond is already ±2cents (i.e., 2/100 of a semitone), which is too much

Ah, that's a good point. I'd be open to an additional API in that case.

Also, I am relying on the wrapping behaviour of a time, which makes my measurements very comfortable. I don't think this could be replicated using micros_since.
I believe micros_since wraps around like that.

[TheZoq2]

Closed by #322