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

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

at91_enthus wrote:
> On Sat, Feb 5, 2011 at 9:39 AM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>> 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.
>>
> 
> Actually, the rt_timer_spin was included in this function that is run as a
> real time task:
> 
> void spin(){
> 
>     rt_task_set_periodic(&spin_task,TM_NOW, 100000);
> 
>     while(1){
> 
>     *((unsigned int *) (piob_base + (PIO_SODR))) = 1<<0;
> 
>      rt_task_wait_period(NULL);
> 
>      *((unsigned int *) (piob_base + (PIO_CODR))) = 1<<0;
> 
>      rt_timer_spin(50000);
> 
>   }
> 
> I decided to go for simple GPIOs manipulation, so I can have a better
> picture of what's happening on the scope.

So, what you are measuring is simply the length of rt_timer_spin, and
what you see is simply the rt_timer_spin jitter: time for the system
call, potential interruption by interupt handler.

Where you will see the exact 100us frequency +-jitter is measuring the
signal period at the falling edge. Because that is what is constant on
average. The rest is irrelevant.

> 
> R.
> 


-- 
                                                                Gilles.