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

Philipp Rosenkranz philipp.rosenkranz at fu-berlin.de
Wed Sep 17 18:44:56 CEST 2014

Dear Oleg,

I really like your new timer interface concept. However, I'd like to add
that it would
be a good idea to take some "inspiration" from the POSIX timer API.
Especially the concept of distinguishing between different types of clocks
for timers
(e.g. CLOCK_REALTIME / CLOCK_MONOTONIC; see [1]) should be considered.
This would allow a programmer to select a clock for a timer according to
the needs
of the application. This is especially important if some kind of clock
protocol (*wink*) is involved (in this case the RTC may "jump").

[1] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html


2014-09-16 23:04 GMT+02:00 Oleg Hahm <oliver.hahm at inria.fr>:

> 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
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20140917/85508d8e/attachment.html>

More information about the devel mailing list