This is an overview of timers on Nordic radio SoC.
On the NRF52 family of radio SoC, there are these Timer devices:
- RTC: low power, and low frequency
- Timer: high power, and high frequency
The RTC is misnamed. RTC is Nordic’s acronym for “Real-Time Counter” but more generally RTC means “real time clock” and provides calender like functions: time measured in years and days. The Nordic RTC is only 24-bit, so it typically rolls over frequently, say in minutes. Whereas most people expect a RealTimeClock to never roll over, practically speaking.
On the NRF52, there are three RTC’s, RTC0, RTC1, and RTC2.
- RTC0 is used by the Softdevice
- RTC1 is used by the Nordic app_timer module
- RTC2 is not generally used by the Nordic SDK
So your app should use RTC2 as the first choice, so that if your app also uses Softdevice or app_timer, there is no conflict.
Nordic’s app_timer module implements virtual Timers. That is, many Timers are implemented in software on one real Timer (i.e. one compare register of RTC1.)
Timers might better be called Alarms. A Timer is implemented on a Clock and an Alarm, where a Clock is a counter that rolls over and an Alarm is a compare register that generates an event/interrupt when the compare register matches the clock.
Each of the RTC’s has a counter and multiple compare registers. Thus you can implement many real Timers on each RTC.
A real Timer is implemented on hardware devices like the RTC. It consumes no cpu cycles while it is running, and few cpu instructions to set it up.
Because virtual Timers are implemented partially in software, it takes a few more cpu cycles than a real Timer. But that’s not important. What is important is that the virtual Timers be implemented correctly. There are outstanding bug reports on Nordic’s app_timer implementation. And the test suite is no public.
Other software kits such as freeRTOS implement virtual Timers. These might be more likely to be correct since they are open source and widely used?
Algorithms for setting an Alarm on a Clock are not trivial but are well understood. It requires careful use of modulo arithmetic. Modulo arithmetic is “clock like”: results of operations roll over, loosely speaking. Correctly setting an alarm on a clock also requires use of Lamport’s rule. Finally, a hardware implementation of a clock has limitations that the software (the Timer driver) must account for: a compare register cannot be set too near the current counter value, else the hardware event might not occur in a timely fashion.