Provides an HFCLK timer driver #629
Conversation
huntc
force-pushed
the
timer-driver-impls
branch
from
bbdf823 to
a5f7801
Compare
There was a problem hiding this comment.
- Could you split into several files?
time_driver/{mod.rs, rtc.rs, timer.rs} - The overflow handling is not correct.
- RTC is 24bit, TIMER is 32bit. Many constants need updating, in
calc_nowand the rest of the code. - RTC has OVERFLW event, TIMER doesn't. We still need some way to detect overflow. Alternatives:
- Set one CC at 0, another at 0x8000_0000. This uses 2 CCs so we can support only 1 alarm (4 ccs total, minus 1 dummy for reading the counter, minus 2 for overflow handling)
- Set one CC at 0x8000_0000, when it fires change it to 0, when it fires change it back to 0x8000_0000 etc.
- RTC is 24bit, TIMER is 32bit. Many constants need updating, in
| @@ -34,6 +34,7 @@ nrf9160-ns = ["_nrf9160"] | |||
|
|
|||
| gpiote = [] | |||
| time-driver-rtc1 = ["_time-driver"] | |||
| time-driver-timer1 = ["_time-driver"] | |||
There was a problem hiding this comment.
You need to set embassy/time-tick-32768hz when using RTC, embassy/time-tick-1mhz (or whatever the tick rate of the timer driver is) when using TIMER.
embassy-nrf/src/time_driver.rs
Outdated
| let r = timer(); | ||
| r.mode.write(|w| w.mode().timer()); | ||
| r.prescaler | ||
| .write(|w| unsafe { w.prescaler().bits(Frequency::F62500Hz as u8) }); |
There was a problem hiding this comment.
Why this particular prescaler? I thought you wanted this to have higher precision. Higher tick rate means more preicision. With 1Mhz rate you can measure down to 1us of time. With 16Mhz you can measure down to 62.5ns.
embassy-nrf/src/time_driver.rs
Outdated
| let period = self.period.load(Ordering::Relaxed); | ||
| compiler_fence(Ordering::Acquire); | ||
| let r = timer(); | ||
| r.tasks_capture[3].write(|w| unsafe { w.bits(1) }); |
There was a problem hiding this comment.
This will overwrite whatever's in CC3 which you're currently using for (half of the) overflow handling. It's super unfortunate that you can't read the counter value directly. WTF Nordic? but it is what it is. We have to sacrifice a CC channel to read the counter >_<
This means it can't support 3 alarms unlike RTC. It can max 2 or 1 depending on how you implement overflows
The existing (default) timer driver for nRF implements one using the RTC, which uses the LFCLK. An additional feature has been provided where the HFCLK can be used for the timer driver by using TIMER1. An STM example has also been ported so that either driver implementation can be exercised. To use the HFCLK driver, simply use the `time-driver-timer1` feature in place of the `time-driver-rtc1` one when depending on embassy-nrf.
huntc
force-pushed
the
timer-driver-impls
branch
from
a5f7801 to
d99c748
Compare
Resolved in commit d99c748 |
|
closing due to outdatedness. Feature is still wanted tho! |
The existing (default) timer driver for nRF implements one using the RTC, which uses the LFCLK. An additional feature has been provided where the HFCLK can be used for the timer driver by using TIMER1. An STM example has also been ported so that either driver implementation can be exercised.
To use the HFCLK driver, simply use the
time-driver-timer1feature in place of thetime-driver-rtc1one when depending on embassy-nrf.