Hi Kevin,
let me try to answer your questions (see inline).
On 09.12.2015 12:57, ROUSSEL Kévin wrote:
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
Best regards,
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
