Clocks, timers, RTC, why?

[Ladasky]

I am developing software for the nRF52. As recommended by many recent posts here in the Developer Zone, I have upgraded to SDK 11. I am working on an application for a battery-powered device which will repeat the following cycle:

1. Sleep, for one to 10 minutes.

2. On waking, conduct six well-timed operations, about 0.1 seconds apart. These operations will include sampling the SAADC and acting as an I2C master to communicate with a peripheral.

3. Communicate the results of the operations in step 2. At first I will send this information to the UART, but eventually I want to transmit over BLE.

Obviously, I don't want to use a busy-wait when the CPU will be idle for 10 minutes. But there seem to be three different ways to implement hardware timers. If I look at an nrf_config_drv.h file, I see flags for CLOCK_ENABLED, TIMER0_ENABLED through TIMER4_ENABLED, and finally, RTC0_ENABLED through RTC3_ENABLED.

The tutorials (which only cover SDK 10) and example code are not helping me to understand the different types of timers, or how to choose between them. Can someone please summarize the reasons for the existence of these various approaches to timing? Thanks.

[tesc]

The main difference between TIMER and RTC (Real-time counter) is that:

• TIMER uses the high-frequency clock source (HFCLK, 16 MHz), which means better resolution (62.5 ns) and higher power consumption (typ. 5 or 70 uA depending on HFCLK source).
• RTC uses the low-frequency clock source (LFCLK, 32 KHz), which means less resolution (~30 us) and lower power consumption (typ. 0.1 uA).

For the details, see chapters 24 (TIMER -- Timer/counter) and 25 (RTC -- Real-time counter) of the nRF52832 Product Specification.

For RTC there is also a library in the SDK: Timer library

Based on what you write about your application I would suggest using RTC.

CLOCK_ENABLED is for enabling the clock driver in the SDK. This is not a timer. Rather it is a driver for handling the low and high frequency clock sources.

[Jarmo]

There's also typically 32-bit second counters without calendar, and they are also called "Real Time Clocks". Actually, I prefer this type of counter to days/months etc. calendar because it is pretty easy to convert seconds counter (e.g. Epoch Time) into days/months etc, but more complicated to do it vice versa. And in a program code you will eventually need second counter, mostly.

But the reason I ended up here into an old discussion is that nRF5 RTC seems to be only 24 bit and thus wraps over after 512 seconds (@32768 Hz). Thats way too little. Now I am trying to find out a solution for the system to deep sleep e.g. an hour without losing the "real time".