[riot-devel] Timers (caution: long mail, abstract available)
hauke.petersen at fu-berlin.de
Thu Sep 18 12:23:17 CEST 2014
Hi Oleg, hi everyone,
first of all +1 for rethinking the current timer implementation. I was
also having some thoughts over the last weeks on how we could improve
the current situation (without a good solution yet, though).
This mail got also rather long, so here is a short abstract:
I tried to analyze the use cases for timers in RIOT and put the needed
functions into groups. I further put in some ideas about possible
Before thinking of the concrete structure of a remodeled timer, I think
we should elaborate on the list of use cases for timers that Pakka
I see 4 different classes of timer-related functional groups:
1. Hardware peripherals:
This groups contains all functions that are covered directly by hardware
peripherals. These should in my opinion be covered by low-level drivers.
In this group I see
- PWM (already in RIOT)
- PFM (I don't know this, can it done by HW directly?)
- Input pulse lenth measurement (I have an interface started, but no
PR for it yet)
- Watchdog (interface needed)
The accuracy of these modules depends heavily on the underlying hardware
and should be controlled by the low-level driver interface (at it is
done for the PWM so far).
This group covers the typical situation that something has to simply
wait a certain amount of time until execution is continued. It can be
further split into two sub-groups:
- High resolution: waiting for for a (precise) short amount of time.
Typically in the order of micro or even nano seconds. This is used i.e.
for device drivers and often used in interrupt context. Due to the
constraints and depending on the uC speed this might be only possible
with active waiting loops, as running the scheduler in between might
take too much time, callbacks on top of the low-level timer driver might
work in other cases.
- Low resolution: waiting for for a mid-to-long term of time (speaking
from a millisecond to many seconds) and used in thread-context. This I
would imagine can be implemented by putting the calling thread to sleep.
For a wider time span this behavior could be based on the low-level
timer and rtt/rtc peripherals (basically what the vtimer is doing at the
Some threads (e.g. protocol implementations) need to react to timeouts,
while doing other tasks when waiting. The resolution is typically rather
low(?), in the order of mili to more seconds. For implementing this
behavior I would imagine this can be done using RIOTs messaging system.
Maybe a central timeout thread that is responsible to send timeout
messages to certain tasks is a solution here?
4. Periodic triggers
I think we can all agree, that RIOT to its tickless scheduling paradigm
is not very friendly to periodic tasks at the moment. In this group I
would see again two sub-groups:
- high resolution: these need to be very exact and are in the range of
milli to 10s of micro seconds. Typical applications are control loops,
as e.g. in PID controllers for motor control or similar. I could imagine
implementation could be done by either a) sending regular messages to a
high priority thread or b) having a means of periodically scheduling a
task. I would vote for option a) which could be added to the timeout
thread discussed above.
- low resolution: I would imagine this type for periodic tasks that do
not have to be exactly precise and have periods in the range of 10s of
milliseconds to seconds. Applications could be e.g. measure some
temperature every 3 seconds and send value via network or blink an LED
every 250ms or so. Implementations wise this could also be solved by
periodic messages from a central timeout thread?
To conclude: I think we should be able to create a generic timer
infrastructure with 3 submoules:
- directly used low-level timer drivers for high-res, short periods
- something like our vtimer for mit to long-term waiting
- a central timer thread based on the above for sending messages on
timeouts and for periodic triggers
Sorry for this rather long mail, but looking forward on this discussion!
On 18.09.2014 07:08, Pekka Nikander wrote:
>> There are a number different use cases where I've seen timers/counters being used:
>> 1. PWM and PFM generation
>> 2. Device driver helpers
>> 3. Protocol timeout helpers
>> 4. Input pulse length measurement
>> 5. Real time clock, including RTC-based events such as calendar alarms
>> 6. Periodic or delayed tasks
>> 7. Watchdog
>> The API for PWM and PFM generation is likely to be quite different from a "timer" API, and therefore they probably do not apply to this discussion. Ditto for watchdog.
>> The device driver helper case can be divided further into the timeout case, which is pretty similar to the protocol timeouts (see below), and other needs. Some of the other needs have hard real time requirements, sometimes to a nanosecond-level accuracy, therefore usually requiring interrupts and sometimes counting the clock cycles for the interrupt delay, too.
>> Protocol timeouts have varying real-time requirements, but most of the time the accuracy is in the millisecond-scale or coarser. (Of course, if you need to implement a (slow) serial interface completely in software, that is a different case.) Hence, most probably most of them can be folded to the "delayed task" category, and should be implemented with the help of the scheduler (see below).
>> Input pulse measurement usually requires accuracy, but when exactly the value is then read from the counter may be delayed, depending on the reaction time requirements. Furthermore, the API is likely to be different from a timer API.
>> RTC is a chapter of its own, and usually requires its own API.
>> Periodic or delayed tasks usually need to be implemented in the scheduler API, the scheduler using an underlying timer.
>> So, at least to me emerges the question of whether RIoT needs a "timer API" or a "timeout API" for those device drivers, protocols, and other modules that need timeouts.
>> Furthermore, I am not really understanding what the "user space" is in the RIoT case. I could imagine an "application" needing periodic tasks, real time clock, and real-time events, at least. But "timers" as such, hmm.
>> So, to me, the question seems to boil down in a different way, whether there is any real need for a "generic timer" API to the user space at all. Maybe there is, but I wasn't able to come up with any good examples that wouldn't fall into a slightly different category when thinking more closely.
>> (A hardware-abstraction level API is a completely different story, of course.)
>> --Pekka Nikander
> devel mailing list
> devel at riot-os.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel