drivers/rtt_rtc: add RTT based RTC implementation, enable it for cpu/cc2538, nrf5x_common

[benpicco]

Contribution description

This adds an emulated RTC based on top of the RTT implementation.
It is rather basic in that it only allows alarms to be set one full period of the RTT in the future.
For a 32bit RTT running at 32kHz, this means you can set alarms at most 1½ days in the future.

Testing procedure

Run tests/periph_rtc on e.g. openmote-b:

2020-02-29 16:39:38,199 # This test will display 'Alarm!' every 2 seconds for 4 times
2020-02-29 16:39:38,200 #   Setting clock to   2011-12-13 14:15:57
2020-02-29 16:39:38,211 # Clock value is now   2011-12-13 14:15:57
2020-02-29 16:39:38,212 #   Setting alarm to   2011-12-13 14:15:59
2020-02-29 16:39:38,212 #    Alarm is set to   2011-12-13 14:15:59
2020-02-29 16:39:38,213 # 
2020-02-29 16:39:40,211 # Alarm!
2020-02-29 16:39:42,211 # Alarm!
2020-02-29 16:39:44,210 # Alarm!
2020-02-29 16:39:46,210 # Alarm!

Issues/PRs references

I moved the additions to the RTT driver to #13630
They are not needed anymore.

[fjmolinas]

@benpicco why is this wip now?

[benpicco]

Because the previous version was adding up rounding errors by dropping the sub-seconds and the real solution is much simpler.

[gschorcht]

@benpicco I like this PR because I could use it right away for the ESP8266, now that I have implemented an RTT (PR #13640). So I'm really interested to have it soon.

[gschorcht]

I have added Waiting for other PR since it depends now on PR #13646.

Forget it 😎

[gschorcht]

Please fix the typo and squash.

[gschorcht]

ACK

[gschorcht]

@benpicco Thanks for this contribution.

[gschorcht]

@benpicco One question, should a CPU that use rtt_trc module to provide periph_rtc also define

FEATURES_PROVIDED += periph_rtc

in its Makefile.features? The reason for my question is that some programs such as tests/periph_pm use

FEATURES_OPTIONAL += periph_rtc

which doesn't pull in module rtt_rtc because the feature is only optional and not declared as provided.

[benpicco]

If the RTT doesn't depend on a board feature (low frequency external oscillator), it can be added together with FEATURES_PROVIDED += periph_rtt.

[gschorcht]

it can be added together with FEATURES_PROVIDED += periph_rtt.

OK, then there's another question. If an application would claim

FEATURES_REQUIRED += periph_rtt
FEATURES_REQUIRED += periph_rtc

a problem will occur. For that purpose, we have FEATURES_CONFLICT variable. But adding

FEATURES_CONFLICT += periph_rtc:periph_rtc

would always yield the conflict waring. Any idea?

[benpicco]

I noticed that problem too and was hoping no application would use both RTT and RTC…
I don't know of a way how to resolve this with the means currently provided by our build system.

[gschorcht]

Maybe, we could realize it by defining a peripheral periph_rtt_base that implements the RTT and can be used either by periph_rtt or by periph_rtc (alias rtt_rtc).

FEATURES_PROVIDED += periph_rtt_base
FEATURES_PROVIDED += periph_rtt
FEATURES_PROVIDED += periph_rtc

FEATURES_CONFLICT += periph_rtt:periph_rtc

ifneq (,$(filter rtt_rtc,$(USEMODULE)))
   FEATURES_REQUIRED += periph_rtt_base
endif

[benpicco]

That would be a solution. I like the idea since it could also be used e.g. on ATmega where periph_rtt emulates a 24 bit counter when the hardware only provides 8 bit counters.

rtt_rtc can deal with fast overflowing 8 bit counters just fine, using the 24 bit emulated RTT would be needless overhead. So that could also make use of a simple periph_rtt_base module that just exposes the real hardware features.