Understanding clocks on Nordic nrf5x embedded radio, towards a long clock


This is a quick summary of other posts.  I disambiguate terms in an object oriented way.   I explain elementary things.

I capitalize words to emphasize they are well-known objects, with well-known data and behaviour. You should verify, I could be wrong and I wrote this in haste.  Errors here might illustrate the confusion surrounding the subject.

See Also

A post on Nordic DevZone.

A blog about the nrf5x Application Timer library.


Time (I don’t discuss, I assume an intuitive notion suffices.)  Subclasses are:

  • UnsynchronizedShortTime
  • RealTime

UnsynchronizedShortTime is a basic Counter.  It is not expected to be synchronized with other instances.  It rolls over every few days.

RealTime is the notion of time used in the real world.   It takes many bits to keep RealTime that is precise to seconds and won’t roll over within centuries.   It takes even more bits (say 64 bits) to keep RealTime that is precise to micro seconds (uSec.)   RealTime is expected to be synchronized with other RealTimes.

A Clock keeps time.  Methods are:

  • set the time
  • ask for the time (now, or current time)
  • set alarms to go off at a certain time.

Subclasses of Clock:

  • RealTimeClock
  • LongClock

A RealTimeClock  is a hardware Device or Peripheral.  It comprises a Counter and a CompareRegister.  The Counter is free-running.  You can configure the RTC so that when the Counter equals the CompareRegister, an Event and/or Interrupt is generated.  A RTC Counter is typically 24-bits.  There is some ambiguity here:  a RealTimeClock does not always keep RealTime and need not be synchronized or accurate.

There is much ambiguity here:  some use RTC to mean real time counter, some use it to mean real time clock.  Some use Real Time Counter to describe a Clock (having alarm functions.)

A LongClock is a longer running clock (before it rolls over.)  A LongClock is typically implemented in software using a RealTimeClock. A LongClock may keep RealTime, or not.

This is where you typically find ambiguity: some “RTC IC’s (chips)” implement RealTime in hardware (they keep time very accurately, and have many bits of time available in a format you typically use in the real world e.g.  YYYY:MM:DD:SS. )   RealTimeClock’s embedded as a Peripheral of a SystemOnAChip (SoC) typically do not implement RealTime (although they can be accurate.)

Precision and Accuracy  and Drift (see wiki.)  Accuracy and Drift are the same notion describing the relation between two Clock instances.

RealTimeClock subclasses:

  • RTCByRCOscillator
  • RTCByCrystal.

They differ in accuracy.

A RTCByRCOscillator uses a resistor and capacitor oscillator embedded in the hardware.   Its accuracy is typically worse than 200 ppm.  That gives a drift of a second every few days.

A RTCByCrystal uses a resonant, ceramic crystal (and sometimes capacitors) external to the hardware.   (There is some ambiguity here:  the circuit the crystal is part of can also be called an oscillator.)  Its accuracy is typically better than 20 ppm.  That gives a drift of a second every month.

A Timer just sets off an alarm.  You can’t tell Time from a Timer (unless you record when you started the Timer.)  You can ask a Timer for time remaining, which is a TiA LongClock meDelta (not a Time.)  Timers are implemented in software using a Clock.

Use Cases

A TimeStamp is a read-only copy of a Time instance.  Many applications don’t need TimeStamps, but only need differences between Times. Often you need to compute a Time difference to set an alarm.

You must be careful when computing differences between Time instances if the Clock has rolled over between the two Time instances.  It is useful to keep a LongClock because pragmatically you don’t need to worry about roll over when computing differences.

Generally Times are kept as unsigned ints.  It is safe to difference two Times if the Clock from which they were taken has only rolled over once between, and if the subtracted Time was actually earlier than the second, later, subtrahend time.  (Since difference of unsigned ints is modulo, like a circular clock.)  If the first time was actually later than the second time, it is not safe to use the difference operator to get a delta.  And it is not safe if the Clock has rolled over twice between.

Design considerations

A RTCByRCOscillator embedded in a SoC is free, using no extra components or board space.

A RTCByCrystal requires an extra component and board space.  A crystal is typically $1.

An external RTC IC requires more board space for itself, and also for a crystal.

A LongClock implemented in software using an embedded RealTimeClock:  the software is free (except for the hassle of finding/writing it) but might still require a crystal.

In general, low-frequency (low precision or resolution) clocks take less power.  Because in general, in CMOS semiconductors, it is the switching of flip-flops that takes power.

How LongClock is implemented

Keep upper (most significant) bits in a memory word.  Keep the lower bits in a RealTimeClock.  Configure the RealTimeClock to trigger an event when it rolls over.  The handler for the roll over event increments the upper bits memory word.

How Timers are implemented

Usually a library provides multiple, concurrent Timers.  The library uses one Clock.  Keep an ordered queue of alarm times of the timer instances.  When the clock alarm goes off, reset the clock alarm for the next timer in the queue (set the counter to the DeltaTime from now to the next alarm time.)

Specifics for the nrf5x embedded radio chip

Since Nordic>InfoCenter>NRF52 Series>Product Specification> :

  • RTC

The CLOCK section actually describes Counters.  The nrf5x has:

  • low-frequency Counters that can be ByRCOscillator or ByCrystal (if you add an external crystal.)  The frequency is 32kHz.  Called LFRC and LFXO.
  • high-frequency 16Mhz  Counters.   The crystal is not optional.   Its accuracy is needed by the radio.  These use much more power than the low-frequency counters.  Called HFRC and HRXO.  To use the radio, you must start the HFCLK.  Then the radio automatically switches between HFRC and HRXO as needed (switching it to RC source to save power when not transceiving.)

Not all modules (boards with an nrf5x on them) have a 32-kHz crystal.  E.g. the RedBear BLE Nano does, the Rigado BMD-300 doesn’t.  They MUST have a 16MHz crystal (or else they have low-performance radios, or will they even work at all?)

The RTC section describes an instance of RealTimeClock (having a compare register.)  Its source can be either of the low-frequency Counters.   It is 24-bits.  Its roll-over depends on the prescaler.

The Timer section describes another instance of RealTimeClock.  Its source is the HFCLK, whose source is either of the high-frequency Counters.

The app_timer library provided by Nordic uses the RTC.  It provides Timers (alarms in the future.)  It allows many concurrent Timers.

Implementing a LongClock using Nordic app_timer.  This is really my goal, and where I leave off until I figure it out.  I want a LongClock (with usec resolution) so I don’t need to worry about roll over, but I want to use app_timer API so I don’t have to worry about low-level interface to the RTC.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s