Hey,
On 12/09/15 12:57, ROUSSEL Kévin wrote:
> 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
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
