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,
--
Kévin Roussel
Doctorant, projet LAR
Équipe MADYNES, INRIA Nancy Grand-Est / LORIA
Tél. : +33 3 54 95 86 27
kevin.rous...@inria.fr
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
