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

ROUSSEL Kévin Kevin.Roussel at inria.fr
Thu Sep 25 17:56:02 CEST 2014


Hello everyone,

First, please excuse me for reacting quit lately to this important 
message, I have been quite busy with publication-related work these last 
weeks.

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 
robustness).
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.

Best regards,


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
> 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
>
>
>
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
>

-- 


      Kévin Roussel
      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 mailing list