Re: [Xenomai-help] I-pipe clock source change and MMC issues (AT91)

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

at91_enthus wrote:
>>> Rookie mistake. Indeed, I can have everything in userspace using Xenomai.
>> I

Or in kernel-space... with Xenomai RTDM skin.

>>> wrote a simple program that did a periodic job every 100 us and the
>> jitter
>>> was very small (around 20 us without load and around 35 us with SSH-ing
>> and
>>> Xenomai compilation running on board).

Well, as we often say, benchmarking requires making more than that to
load the board, and for a long time.

>>>
>>> Somewhat unrelated to this thread, I found that when I invoked
>>> rt_task_set_periodic(), I got very precise timings (as expected).
>> However,
>>> when I tried to insert small delays using rt_timer_spin(), the errors
>>> (t_meas - t_spin_func_argument) were not large, but noticeable. For
>> example,
>>> I can precisely measure a 50 us periodic task on the scope. With the same
>>> interval in rt_timer_spin(), I get 55-60 us. As far as I understood, all
>>> timing-related functions use the same time base, so what's the reason for
>>> this behavior?
>>

Well, rt_task_set_periodic gets the hardware timer to tick exactly every
50us. So, whatever time it takes between the return of the call to
rt_task_wait_period() to the entry of the next is irrelevant. And
particularily, the jitter will not matter as long as it is smaller than 50u.

On the other hand, doing:

for(;;) {
	/* Do something */
	rt_timer_spin(50000);
}

The period of the loop will be 50us + rt_timer_spin jitter + time to "do
something". And so, will not even be constant.
You are not creating a periodic task. Besides, the system will not
execute anything else in user-space than your real-time task, and in
particular, the Linux will never run. Except of course if "do something"
contains a call to some secondary domain function, in which case, your
real-time task no longer is real-time.

So, that is not the correct way to get a periodic task.

-- 
                                                                Gilles.