[riot-devel] Timers (caution: long mail, abstract available)

Oleg Hahm oliver.hahm at inria.fr
Tue Sep 16 23:04:25 CEST 2014


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.

=============================================================================

Current Concept
---------------
In the current situation we have have four different timer
implementations/interfaces:
(1) The low-level timer peripheral driver [1]
(2) The hwtimer [2]
(3) The vtimer [3]
(4) The RTT/RTC low-level peripheral driver [4]

(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.

Problems
--------
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
overflows.

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.

[1] https://github.com/RIOT-OS/RIOT/blob/master/drivers/include/periph/timer.h
[2] https://github.com/RIOT-OS/RIOT/blob/master/core/include/hwtimer.h
[3] https://github.com/RIOT-OS/RIOT/blob/master/sys/include/vtimer.h 
[4] https://github.com/RIOT-OS/RIOT/blob/master/drivers/include/periph/rtt.h
    https://github.com/RIOT-OS/RIOT/blob/master/drivers/include/periph/rtc.h

Cheers,
Oleg
-- 
/* XXX: where the fuck is ->f_vfsmnt? */
        linux-2.6.6/fs/intermezzo/vfs.c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20140916/2ba5d6ac/attachment.sig>


More information about the devel mailing list