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.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
