From hwtimer to xtimer: What Changes for RIOT Features?

Development archive
1

Hello everyone,

As (I suppose) everybody here knows, the 'hwtimer' kernel feature has been replaced by the 'xtimer' module.

Consequently, I'm wondering about some features that were specific to RIOT OS, and how they have evolved. More precisely, I have questions to ask:

1] Is RIOT OS kernel still *tickless*? The now gone 'hwtimer' that was in RIOT kernel only fired when an time-related event was actually happening---meaning there was no 'useless' wake-up (i.e.: simply related to the underlying timer frequency) where MCU was activated only to find that there was nothing to do and get back to low-power mode. That's why RIOT OS kernel could be qualified as tickless (no regular and potentially useless interrupt/wake-up). I see that xtimer, according to its documentation (Doxygen comments) is based on an unique hardware timer supposed to have a fixed 1 MHz frequency. Does it mean that there will be an interrupt every microsecond when 'xtimer' is used, or will we still have only an interrupt when a time-related event actually happens (which means RIOT still qualifies as a tickless OS) ?

2] Unless I'm mistaken, the 'hwtimer' feature that allowed to use as much 'hwtimer' instances (as the underlying hardware timers could offer counters/comparators is now gone, 'xtimer' being based on an unique (high-resolution) hardware timer onto which every 'xtimer' instance is multiplexed. Can someone confirm me that the previous statement---based on what I understand---is correct?

3] 'xtimer' is said to be based on a 1-MHz hardware timer, but does it mean we *really* have a granularity/jitter of the order of the microsecond? Dianel Krebs warned me (during the discussion on PR #4178) that xtimer_usleep() was dependent on the scheduler and the delay for its next context switch, and that consequently, the delay passed as a parameter could suffer for an undetermined and potentially *big* jitter. Is this problem specific to the sleep-related functions and their implementation, or does the whole 'xtimer' mechanism suffer from the same problem (i.e.: the xtimer_set[*,_msg,_wakeup]() functions)? In that case, what kind of jitter can we expect relative to the delays we pass as parameters to the xtimer functions? If this jitter is too high or too hard to predict, the status of RIOT OS as a real-time OS could be put in jeopardy? Since be able to have fine-grained real-time features is necessary to my work, can someone reassure me about the 'xtimer' module and its abilities?

Thanks in advance to enlighten me: my job during this year didn't allow me to follow correctly the evolution of RIOT's timer mechanisms, and I quite need some technical details about the new low-level timers' inner workings.

Best regards,

2

Hi Kevin,

let me try to answer your questions (see inline).

Hello everyone,

As (I suppose) everybody here knows, the 'hwtimer' kernel feature has been replaced by the 'xtimer' module.

Consequently, I'm wondering about some features that were specific to RIOT OS, and how they have evolved. More precisely, I have questions to ask:

1] Is RIOT OS kernel still *tickless*?

YES

The now gone 'hwtimer' that was in RIOT kernel only fired when an time-related event was actually happening---meaning there was no 'useless' wake-up (i.e.: simply related to the underlying timer frequency) where MCU was activated only to find that there was nothing to do and get back to low-power mode. That's why RIOT OS kernel could be qualified as tickless (no regular and potentially useless interrupt/wake-up). I see that xtimer, according to its documentation (Doxygen comments) is based on an unique hardware timer supposed to have a fixed 1 MHz frequency. Does it mean that there will be an interrupt every microsecond when 'xtimer' is used, or will we still have only an interrupt when a time-related event actually happens (which means RIOT still qualifies as a tickless OS) ?

The answer has two aspects: the system does not wake up on a certain type of system tick, so no wakeup every ms or so. But to be able to work for (very) long spans of time, the xtimer is currently programmed in a way, so that it wakes up every time the underlying peripheral timer overflows. For 32-bit periph timers, this is every ~1h 20m, for 16-bit timers this is every ~65ms. But this behavior is only 'temporary', is it is planned for the future to make use of peripheral RTT (real-time timers) or RTC (real time clocks) for the long term ticks, so that this periodic wakeup can be omitted.

2] Unless I'm mistaken, the 'hwtimer' feature that allowed to use as much 'hwtimer' instances (as the underlying hardware timers could offer counters/comparators is now gone, 'xtimer' being based on an unique (high-resolution) hardware timer onto which every 'xtimer' instance is multiplexed. Can someone confirm me that the previous statement---based on what I understand---is correct?

yes, this is correct: the xtimer multiplexes all active timers on a single peripheral timer channel, so in practice using exactly one capture-compare channel on a single periph timer instance.

This significantly lowers the complexity of the timer infrastructure (one level less of multiplexing) and leads to more deterministic behavior in terms that you can't run into the situation of 'no hardware timer channel left'.

3] 'xtimer' is said to be based on a 1-MHz hardware timer, but does it mean we *really* have a granularity/jitter of the order of the microsecond? Dianel Krebs warned me (during the discussion on PR #4178) that xtimer_usleep() was dependent on the scheduler and the delay for its next context switch, and that consequently, the delay passed as a parameter could suffer for an undetermined and potentially *big* jitter. Is this problem specific to the sleep-related functions and their implementation, or does the whole 'xtimer' mechanism suffer from the same problem (i.e.: the xtimer_set[*,_msg,_wakeup]() functions)? In that case, what kind of jitter can we expect relative to the delays we pass as parameters to the xtimer functions? If this jitter is too high or too hard to predict, the status of RIOT OS as a real-time OS could be put in jeopardy? Since be able to have fine-grained real-time features is necessary to my work, can someone reassure me about the 'xtimer' module and its abilities?

Again, the answer is two fold: I am actually not sure about the jitters you can expect - @kaspar: can you add some details here? But AFAIK no *big* jitter would be expected, as the timer uses a backoff mechanism, to prevent task switches (scheduler runs) for small wait intervals and falls back to active blocking in these cases.

I don't see the status of RIOT as real-time OS in jeopardy in any case: it is true that you can construct/configure RIOT in a way, that it is not real-time capable (very stupid ISR implementations, badly configured priorities, etc). But you can always build it in a way, that it will comply to any real-time requirements.

If you need very precise and fine grained timing abilities, you have always the possibility to use a second peripheral timer directly (instead of the xtimer). This allows you (i) to run with other timer speed than 1MHz and to trigger your sensible events directly from the timer callback, withtout any xtimer overheads...

Thanks in advance to enlighten me: my job during this year didn't allow me to follow correctly the evolution of RIOT's timer mechanisms, and I quite need some technical details about the new low-level timers' inner workings.

Let us know, where you need more details, and we will be happy to help (and hopefully also try to enhance our documentation...).

Cheers, Hauke

3

Hey,

1] Is RIOT OS kernel still *tickless*? Does it mean that there will be an interrupt every microsecond when 'xtimer' is used, or will we still have only an interrupt when a time-related event actually happens (which means RIOT still qualifies as a tickless OS) ?

("tickless" refers to the scheduler. That said:)

Well, in order to keep the notion of "time" for periods larger than a timer register, xtimer has to wakeup whenever the timer register overflows in order to count exactly those overflows. At 1MHz accuracy on 32bit timers, that's one tick every ~71minutes. On 16bit platforms, it's more often.

I would still call that 'tickless' in the former case.

Also, there are plans to remove those wakeups if an RTC/RTT/slow low power timer is present.

2] Unless I'm mistaken, the 'hwtimer' feature that allowed to use as much 'hwtimer' instances (as the underlying hardware timers could offer counters/comparators is now gone, 'xtimer' being based on an unique (high-resolution) hardware timer onto which every 'xtimer' instance is multiplexed. Can someone confirm me that the previous statement---based on what I understand---is correct?

Remember that xtimer provides multiplexing and wider-than-hardware-timer periods on top of 'periph/timer'. 'periph/timer' can be used as replacement for hwtimer.

We replaced hwtimer (which abstracted timer hardware) and vtimer (which provided multiplexing and long-term timers) with periph/timer and xtimer. hwtimer had a "lifo queue", which we dropped in periph/timer to keep that interface slim.

Together, they have a much more sane design: periph/timer is the slimmest possible abstraction of the different hardware timers that we could come up with. xtimer adds the timer functionality needed in most systems, like multiplexing, long term timers, LPM abstraction, convenience like sending message, unlocking mutex, ...

They've been designed from the ground up, with the experience from hwtimer/vtimer.

So while still young compared to hwtimer, I think the combination will be better suited for all applications compared to the old code.

3] 'xtimer' is said to be based on a 1-MHz hardware timer, but does it mean we *really* have a granularity/jitter of the order of the microsecond?

xtimer tries to offer a usable timer API that allows the use of natural time values ("sleep 100 microseconds") on hardware that allows only "sleep n timer ticks". In order to simplify (and thus make more efficient) the implementation, it assumes that the underlying hardware timer runs at 1MHz. (that will change soon in some way). If 1us accuracy is actually possible depends a lot on the hardware.

If you check the "timer_periodic_wakeup" example, you will see that on most hardware (and depending on correct xtimer tuning values) the wakeup is extremely periodic (when waking up every second, the jitter is less than can be measured with the same timer).

native is a notable example, because when run under Linux, the acuracy goes to hell.

A single timer might arrive a little (constant) time late. I've got a patch to mitigate that (trigger timer a couple of microseconds early, then spin before shooting).

xtimer as of now is only as exact as the underlying timer, so if 1*10^6 timer ticks are not 1sec, xtimer is doomed.

Dianel Krebs warned me (during the discussion on PR #4178) that xtimer_usleep() was dependent on the scheduler and the delay for its next context switch, and that consequently, the delay passed as a parameter could suffer for an undetermined and potentially *big* jitter.

Whenever the timer triggers, if it executes a callback function, the time from hardware interrupt until timer execute will be constant (unless user code disables interrupts).

If the callback wakes up a thread, there's jitter of a couple instructions for the time needed by the scheduler to find the thread and set it awake, but that jitter will not nearly approach a microsecond.

There's also a slight delay (timers might trigger a little late), which xtimer tries to compensate within the "convenience functions" like xtimer_set_msg(). But, there's room for improvement.

In that case, what kind of jitter can we expect relative to the delays we pass as parameters to the xtimer functions? If this jitter is too high or too hard to predict, the status of RIOT OS as a real-time OS could be put in jeopardy?

xtimer as is needs some optimization in some corner cases, but if used correctly, is very exact with little jitter.

Concerning "real-time os status", xtimer does not offer strong real-time guarantees, just as vtimer didn't. Use periph/timer if that is needed.

Since be able to have fine-grained real-time features is necessary to my work, can someone reassure me about the 'xtimer' module and its abilities?

I'm pretty sure xtimer will suit your needs. It can probably used as drop-in replacement for hwtimer.

If you need extreme predictability, you should use periph/timer.

What kind of granularity and predictability do you need? Could you tell us more about your application?

Kaspar

4

Hello everyone , I hope you guys can help me out … I’m gonna try to port riot to the smaller variations of atmel processors ( I’m thinking atmega16 ) … I’m more of a software guy , I haven’t worked with embedded stuff a lot … hope you guys help me out … Thanks

5

Hello,

First, thanks to your quick reply, Hauke and Kaspar.

I indeed understood that these changes were made to enhance reliability and code quality.

* For the tickless part, I am now totally reassured : a wake-up every overflow is no big deal (at least for me in the current situation). RIOT indeed still deserves to be defined as tickless---especially since 'xtimer' is a module, and not a kernel part like 'hwtimer'.

* I am looking into the 'xtimer' module code, and it probably should suit my needs, if I use the callback mechanism efficiently.    My work is about having high-performance, adavanced MAC/RDC protocols, that I have to implement into RIOT's netstack (have a look at PRs #4178, #4180, #4184 and #4213). The granularity I need is in the order of the tens of microseconds.    Actually, the 30.5 microsec. granularity 'hwtimer' offered on MSP430 (Telosb/Z1) platforms---as it is the length of their HW timer "ticks"---was perfectly fine for my needs.    I will try to use 'xtimer' wisely, as your explanations make me believe I will have (at least) a similar granularity.    If not, I will take a look into 'periph/timer', and maybe devise a way to use it directly. Thanks a lot to both of you to pointing me to that possible low-level solution.

Best regards, and see you,