[riot-devel] periph/rtt intent

Hauke Petersen hauke.petersen at fu-berlin.de
Thu Jul 13 22:18:02 CEST 2017


For the motivation of creating the RTT interface it is needed to once 
more recap the main motivation of the peripheral drivers: the idea 
is/was to introduce unified APIs that give direct access to selected MCU 
peripherals with the least possible overhead, mapping each type of 
peripheral to exactly one API. So it was never intended for the periph 
interfaces to care of multiplexing between different hardware units of 
the same/simliar type, but this was always intended to be done by higher 
layer modules (as e.g. the xtimer, stdio, etc).

So the original reason for creating the RTT interface was actually 
historically driven by the stm32's and the sam3, where especially the 
stm32 have three different hardware units (timer, rtt, rtc), all with 
some different characteristics. So we decided back then, to create 
different periph APIs for each of these units.

Now from todays point of view (and we have learned a lot in the last 3 
years...), I think what is nagging is most conceptionally is that the 
periph API and the way its used does not allow us to concurrently map 
different devices into the same API (e.g. timer vs lptimer, uart vs. 
lpuart, rtt vs tim, etc). The only way this is currently possible is to 
use (very) ugly if-else constructs in the periph drivers imlementation, 
that switch between two (or more?) completely different code paths. This 
is not only ugly, hard to maintain, and imposes run-time penalties, but 
this also breaks with the original intention of the periph API to 
provide slim and direct access to a single selected type of peripheral.

So back to the RTT topic: considering what one would expect from the 
API, there is indeed no good reason for having a separation between 
periph/timer and periph/rtt. Both provide the same type of functionality 
and the periph/timer interface could simply also be implemented for rtt 
hardware units. But to do this cleanly, we would need to solve the 
(internal) multiplexing issue for using different typed peripherals 
under the same API. There was some prior work done by some people in the 
community (kaspar, johann, ...) to play around with function pointer 
based approaches which would solve this issue natively, but so far no 
solution yielded satisfying results and could compete in terms of 

So bottom line: functional the RTT interface does only make limited 
sense, but structurally given by the motivation of the periph interfaces 
there is a reason for having it. I guess the problem we need to solve is 
more about internally multiplexing peripheral types to the same API...

Cheers and thanks for bringing this up,

On 13.07.2017 21:32, Joakim Nohlgård wrote:
> Dear developers,
> The intent of the RTT API seem to be rather unclear. My interpretation 
> was that the RTT API is used for long time, low precision timers that 
> can be used to sleep the system for minutes, hours or days. The 
> precision is expected to be 1 second, the same as for the RTC API, but 
> without the calendar struct representation. The reason for using the 
> RTT API is to let it represent the current wall clock time, for 
> tagging collected data etc, while the xtimer (and periph timer) is 
> used for delays and internal precision timing of events. The RTT alarm 
> is used to schedule wake ups or events which should happen at a 
> specific time of day, for example taking a measurement every day at 2:00.
> There seem to be a different interpretation as well: the RTT API is 
> used for any hardware timers which keep running in low power modes.
> This split is seen in the board configurations, where some boards list 
> the RTT as a 32768 Hz timer, others list it as a 1 Hz timer. This has 
> already begun causing problems among the API users, see the lwmac 
> implementation for example, which only works if the RTT is 32768 Hz.
> My interpretation was initially based on a limitation in the RTT 
> (called RTC in NXP documents) on Kinetis hardware which only allow 
> integer seconds for the alarm, while a different hardware module can 
> be used for 1/32768 second precision, but that timer wraps around 
> after 2 seconds (2**16 ticks).
> We need to clarify the documentation and align the implementations to 
> match each other, or the RTT API will be useless as an abstraction 
> layer, since its interpretation will be platform dependent.
> What are your opinions on the RTT API, or the timer APIs in general?
> Best regards,
> Joakim Nohlgård
> RIOT developer
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20170713/a9863a6e/attachment.html>

More information about the devel mailing list