On 04/23/2012 02:57 PM, Andrey Nechypurenko wrote:
retval = rtdm_task_init(&pwm_task[i], // there is currently only one
element in this array
                       20000000); // 20ms period

Do not use a thread, use a timer.

So you mean instead of starting periodic task with rtdm_task_init() it
is better use timer functions to trigger pin toggling piece of code?
Could you please elaborate on it a little? I thought that
rtdm_task_sleep() and rtdm_task_wait_period() are using timers
internally to wake up the thread at the right moment. Is not they?

Yes, but once the timer is woken up, a context switch is needed to wake
up the thread, this adds time.

I see... Nevertheless, I am surprised that context switch is so expensive.

Keep in mind that in a dual kernel system, the RTOS part is competing with the linux kernel on core resources such as CPU caches. So each time your code sleeps for the next period, it leaves a 20 ms time window to linux to run and happily trash all I/D caches, which is a lot.

Now, if you have to schedule a thread, you have to traverse the Xenomai scheduling core to do the switch, in addition to the timer interrupt handling, which translates into significantly more code and data being accessed.

You can check this effect using the latency test: the faster the sampling period, the shorter the latencies, and conversely.

The other alternative I describe in my last mail, that is, using a
dedicated hardware timer with its own irq handler, is a bit more of a
workaround, but still not uncommon in the RTOS world.

Well, if nothing else would help, I'll try this way :-) .

Thank you!

Xenomai-help mailing list


Xenomai-help mailing list

Reply via email to