On 04/23/2012 02:51 PM, Gilles Chanteperdrix wrote:
> On 04/23/2012 02:35 PM, Andrey Nechypurenko wrote:
>>>> retval = rtdm_task_init(&pwm_task[i], // there is currently only one
>>>> element in this array
>>>> "pwm-task",
>>>> pwm_task_proc,
>>>> 0,
>>>> RTDM_TASK_HIGHEST_PRIORITY,
>>>> 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.
>
>>
>> Is not it a kind of work-around you suggesting? If there are some
>> problems which led to the imprecise timing of the sleep/wait functions
>> mentioned above, then, if technically possible, it would be better to
>> fix them instead of working around this behavior.
>
> No, the time it takes to switch context between threads is unavoidable.
> So, if you want to avoid it, you have to use a timer (rtdm_timer_init),
> note that it is really common in RTOS interfaces to offer a timer API,
> this is not a workaround at all.
>
> 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.
>
Another trick, which this time really is a workaround is to program the
timers to wake up a little bit early, and spin to wait for the exact
time wanted.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
