[riot-devel] Timers (caution: long mail, abstract available)
Kevin.Roussel at inria.fr
Thu Sep 25 17:56:02 CEST 2014
First, please excuse me for reacting quit lately to this important
message, I have been quite busy with publication-related work these last
I agree with Oleg on the development of a new upper-layer API for timers.
I beg to differ, however, about the inability to work with 16-bit timers
on Cortex-M : the latter architecture comes with an advanced interrupt
mechanism (NVIC), that allows to selectively enable or disable
interrupts by type, and -- even more interesting -- to choose the
priority of these various types of interrupts. I think it may allow us
to extend by software the hardware 16-bit timers quite efficiently and
reliably: to achieve this goal, we basically need the timer-counter
overflow interrupt to have a greater priority than any other
timer-related priority. This is absolutely not possible on MSP430
architecture, which only has a (vary) basic interrupt management design
to offer (this is why I eventually came to propose PR #1619 to uphold
While architectures like MSP430 are effectively unable to provide
hwtimer accuracy for a long period without the addition of an RTC/RTT,
I'm not sure we can't make it using only core Cortex-M architecture.
Anyway, I also want to say that we have, with our 'hwtimer' mechanism, a
very valuable asset: thanks to it, RIOT OS is able to work 'naturally'
in a completely timeless manner (and thus, I'm conviced, in a very
efficient way energy-wise) by design, while offering very advanced
real-time features. On the MSP430 architecture I work with, even
FreeRTOS (a reference in the real-time domain) is not able to provide
the simultaneous use of many hardware timers -- only one hardware timer
is used to provide a master tick, the timers provided by the kernel
being comparable to RIOT's 'vtimers'.
That's why, besides any IoT consideration, I consider RIOT to be a very
promising real-time software platform. I strongly believe we should be
proud of this 'design win', and build on it.
Finally, since I have spend quite some time on the subjects last months,
I hope to be able to provide help in designing and building this new
high-level timer API. I will certainly do as much as I can to this end.
Le 16/09/2014 23:04, Oleg Hahm a écrit :
> 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.
> Current Concept
> 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
> runtime overhead.
> (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.
> New Concept
> 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 microsecond.
> 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.
>  https://github.com/RIOT-OS/RIOT/blob/master/drivers/include/periph/timer.h
>  https://github.com/RIOT-OS/RIOT/blob/master/core/include/hwtimer.h
>  https://github.com/RIOT-OS/RIOT/blob/master/sys/include/vtimer.h
>  https://github.com/RIOT-OS/RIOT/blob/master/drivers/include/periph/rtt.h
> devel mailing list
> devel at riot-os.org
Doctorant, projet LAR
Équipe MADYNES, INRIA Nancy Grand-Est / LORIA
Tél. : +33 3 54 95 86 27
Kevin.Roussel at inria.fr
More information about the devel