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