From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4D4D8B70.3050207@domain.hid> Date: Sat, 05 Feb 2011 18:40:00 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4D49CF24.9080700@domain.hid> <4D49D608.5020006@domain.hid> <4D4A80F6.5020600@domain.hid> <4D4A8354.7010209@domain.hid> <4D4C7F10.3020703@domain.hid> <4D4D6F32.4070302@domain.hid> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] I-pipe clock source change and MMC issues (AT91) List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: at91_enthus Cc: xenomai@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.