[riot-devel] Timers (caution: long mail, abstract available)
abhinav.somaraju at tridonic.com
Wed Sep 17 09:02:13 CEST 2014
Thank you for bringing this topic up. I would like to add a couple of
comments to your email as a user or RIOT without having contributed to
Firstly, I found the timer implementation in RIOT one of the most
confusing part and it took me a while to figure out how to use the
different timers. So your suggestion of a more straightforward timer
implementation would be much easier to start using.
Secondly, there is still an issue with timers that I am unable to solve.
I see that you do not want to use timers to schedule tasks because of
your tickles scheduler concept. However, there are some low-level
peripherals drivers that still need timers to schedule certain events.
For example I am currently using the HAL library from STM and several
peripherals (e.g I2C) uses timeouts from within interrupt routines to
stop a peripheral if it does not get a response from a peer device.
Therefore, for such peripheral drivers, it is essential to get access to
a timer of some kind that has a higher interrupt priority level then all
other interrupts (e.g. the SYSTICK).
From: devel [mailto:devel-bounces at riot-os.org] On Behalf Of Oleg Hahm
Sent: Dienstag, 16. September 2014 23:04
To: RIOT OS kernel developers
Subject: [riot-devel] Timers (caution: long mail, abstract available)
Dear radical IoTlers,
I know the subject is neither creative nor is this a very popular topic,
but since timers are critical to almost every application, I feel that
there's a need for (at least) one more discussion about this issue.
Since this is gonna be a rather long mail, here's an abstract:
First, I will describe the status quo of the timer implementation. Then,
I will describe some problems we're facing with this implementation and
finally, I will propose a sketch for a new timer interface.
In the current situation we have have four different timer
(1) The low-level timer peripheral driver 
(2) The hwtimer 
(3) The vtimer 
(4) The RTT/RTC low-level peripheral driver 
(1) implements the required functionality of the timer provided by the
hardware. This implementation is hardware dependent and has the least
(2) is an abstraction layer on top of (1) which guarantees almost the
same accuracy, but offers additionally a fixed timer length of 32 bits
for every hardware platform. Still, it is bound to a physical timer.
(3) abstracts further, gives no guarantees concerning the accuracy,
offers a fixed resolution of one microsecond and maximum period of 2^32
seconds. It is bound to one instance of (2).
(4) Implements the RT(T|C) feature of the hardware platform, if
available and has typically a resolution of one second.
One big issue with the current design is based on the fact that many
MCUs (even a lot of the Cortex-M platforms) only provide hardware timers
of 16 bit length. In order to implement the hwtimer this leads either to
a reduced accuracy by reducing the speed of this timer (which is not an
option for many
applications) or using at least one additional hardware timer to count
As we can see if we browse through the history of
https://github.com/RIOT-OS/RIOT/pull/1619, the second variant is a
difficult, on some platforms maybe even impossible task. And even if
someone manages to implement a stable solution, this reduces the amount
of available a timers.
After thinking about this problem a little bit, I came to the conclusion
that there's only a need for one timer interface at the upper layers
(i.e., user space). This interface should offer the possibility to
specify if maximum precision is required or not and set timers of
(almost) arbitrary duration, but with a resolution of at least one
The implementation should use the hardware RTC if available or,
otherwise, something like the current vtimer to set a timer that fires
"shortly" before the actual specified period expires. For the remaining
time, either the hardware timer implementation is used (for highly
timing critical tasks) or a short running version of a software
abstraction (like current hwtimer or
vtimer) is used.
/* XXX: where the fuck is ->f_vfsmnt? */
The contents of this e-mail and any attachments are confidential
to the intended recipient. They may not be disclosed to or used
by or copied in any way by anyone other than the intended recipient.
If this e-mail is received in error, please immediately notify
the sender and delete the e-mail and attached documents.
Please note that neither the sender nor the sender's company
accept any responsibility for viruses and it is your responsibility
to scan or otherwise check this e-mail and any attachments.
More information about the devel