<div dir="ltr">Dear Oleg,<div><br></div><div>I really like your new timer interface concept. However, I'd like to add that it would </div><div>be a good idea to take some "inspiration" from the POSIX timer API. </div><div>Especially the concept of distinguishing between different types of clocks for timers </div><div>(e.g. CLOCK_REALTIME / CLOCK_MONOTONIC; see [1]) should be considered. </div><div>This would allow a programmer to select a clock for a timer according to the needs</div><div>of the application. This is especially important if some kind of clock synchronization </div><div>protocol (*wink*) is involved (in this case the RTC may "jump").   </div><div><br></div><div>[1] <a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html" target="_blank">http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html</a><br></div><div><br></div><div>Regards,</div><div>Philipp<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-09-16 23:04 GMT+02:00 Oleg Hahm <span dir="ltr"><<a href="mailto:oliver.hahm@inria.fr" target="_blank">oliver.hahm@inria.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear radical IoTlers,<br>
<br>
I know the subject is neither creative nor is this a very popular topic, but<br>
since timers are critical to almost every application, I feel that there's a<br>
need for (at least) one more discussion about this issue.<br>
<br>
Since this is gonna be a rather long mail, here's an abstract:<br>
<br>
First, I will describe the status quo of the timer implementation. Then, I<br>
will describe some problems we're facing with this implementation and finally,<br>
I will propose a sketch for a new timer interface.<br>
<br>
=============================================================================<br>
<br>
Current Concept<br>
---------------<br>
In the current situation we have have four different timer<br>
implementations/interfaces:<br>
(1) The low-level timer peripheral driver [1]<br>
(2) The hwtimer [2]<br>
(3) The vtimer [3]<br>
(4) The RTT/RTC low-level peripheral driver [4]<br>
<br>
(1) implements the required functionality of the timer provided by the<br>
hardware. This implementation is hardware dependent and has the least<br>
runtime overhead.<br>
(2) is an abstraction layer on top of (1) which guarantees almost the same<br>
accuracy, but offers additionally a fixed timer length of 32 bits for every<br>
hardware platform. Still, it is bound to a physical timer.<br>
(3) abstracts further, gives no guarantees concerning the accuracy, offers a<br>
fixed resolution of one microsecond and maximum period of 2^32 seconds. It is<br>
bound to one instance of (2).<br>
(4) Implements the RT(T|C) feature of the hardware platform, if available and<br>
has typically a resolution of one second.<br>
<br>
Problems<br>
--------<br>
One big issue with the current design is based on the fact that many MCUs<br>
(even a lot of the Cortex-M platforms) only provide hardware timers of 16 bit<br>
length. In order to implement the hwtimer this leads either to a reduced<br>
accuracy by reducing the speed of this timer (which is not an option for many<br>
applications) or using at least one additional hardware timer to count<br>
overflows.<br>
<br>
As we can see if we browse through the history of<br>
<a href="https://github.com/RIOT-OS/RIOT/pull/1619" target="_blank">https://github.com/RIOT-OS/RIOT/pull/1619</a>, the second variant is a difficult,<br>
on some platforms maybe even impossible task. And even if someone manages to<br>
implement a stable solution, this reduces the amount of available a timers.<br>
<br>
New Concept<br>
----------<br>
After thinking about this problem a little bit, I came to the conclusion that<br>
there's only a need for one timer interface at the upper layers (i.e., user<br>
space). This interface should offer the possibility to specify if maximum<br>
precision is required or not and set timers of (almost) arbitrary duration,<br>
but with a resolution of at least one microsecond.<br>
<br>
The implementation should use the hardware RTC if available or, otherwise,<br>
something like the current vtimer to set a timer that fires "shortly" before<br>
the actual specified period expires. For the remaining time, either the<br>
hardware timer implementation is used (for highly timing critical tasks) or a<br>
short running version of a software abstraction (like current hwtimer or<br>
vtimer) is used.<br>
<br>
[1] <a href="https://github.com/RIOT-OS/RIOT/blob/master/drivers/include/periph/timer.h" target="_blank">https://github.com/RIOT-OS/RIOT/blob/master/drivers/include/periph/timer.h</a><br>
[2] <a href="https://github.com/RIOT-OS/RIOT/blob/master/core/include/hwtimer.h" target="_blank">https://github.com/RIOT-OS/RIOT/blob/master/core/include/hwtimer.h</a><br>
[3] <a href="https://github.com/RIOT-OS/RIOT/blob/master/sys/include/vtimer.h" target="_blank">https://github.com/RIOT-OS/RIOT/blob/master/sys/include/vtimer.h</a><br>
[4] <a href="https://github.com/RIOT-OS/RIOT/blob/master/drivers/include/periph/rtt.h" target="_blank">https://github.com/RIOT-OS/RIOT/blob/master/drivers/include/periph/rtt.h</a><br>
    <a href="https://github.com/RIOT-OS/RIOT/blob/master/drivers/include/periph/rtc.h" target="_blank">https://github.com/RIOT-OS/RIOT/blob/master/drivers/include/periph/rtc.h</a><br>
<br>
Cheers,<br>
Oleg<br>
<span class="HOEnZb"><font color="#888888">--<br>
/* XXX: where the fuck is ->f_vfsmnt? */<br>
        linux-2.6.6/fs/intermezzo/vfs.c<br>
</font></span><br>_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@riot-os.org">devel@riot-os.org</a><br>
<a href="http://lists.riot-os.org/mailman/listinfo/devel" target="_blank">http://lists.riot-os.org/mailman/listinfo/devel</a><br>
<br></blockquote></div><br></div>