[Xenomai] Sensoray 626 analogy driver

Wojciech Domski wojciech.domski at gmail.com
Tue Mar 25 12:28:28 CET 2014


W dniu 25.03.2014 12:16, Gilles Chanteperdrix pisze:
> On 03/25/2014 11:26 AM, Wojciech Domski wrote:
>> W dniu 24.03.2014 13:19, Gilles Chanteperdrix pisze:
>>> The solution which would be acceptable is not to have busy waits, except
>>> for very short durations. But for instance transferring a byte on I2C
>>> takes around 20us at 400 kHz, a 20us masking section is unacceptable.
>>> rtdm_task_busy_sleep, as the name suggests is a busy wait loop, so, no,
>>> it is not acceptable either.
>>>
>>> Use a thread or a timer to reschedule while you wait for the end of the
>>> transfer, instead of busy waiting.
>> Dear Gilles,
>>
>> As you mentioned before the driver has few places like this:
>>
>> while(!FLAG1);
>> while(!FLAG2);
>>
>> Would a solution of creating a separate task for this purpose be ok?
>>
>> task()
>> {
>>       while(!FLAG1);
>>       while(!FLAG2);
>> }
> I was rather thinking about rtdm_task_sleep() instead.
>
>> In the place of those loops a piece of code responsible for creating and
>> joining task would be put instead:
>>
>> rtdm_task_init();
>> rtdm_task_join_nrt();
> This will not work for code currently running in interrupt handlers. An
> interrupt handler can not call rtdm_task_join_nrt(). You will rather
> have to wake up the thread, not reenabling the interrupt at the end of
> the handler, and reenable the interrupt in the thread when the job is
> done. Or alternatively, fire a timer instead of waking up a thread.
>
>
Dear Gilles,

If what I have understood correctly, basically what you mean is changing:

while(!FLAG) ;

into

while(!FLAG)
     rtdm_task_sleep();

Xenomai's documentation that rtdm_task_sleep() can be always 
rescheduled. In my opinion
this solution is sufficient and meets Xenomai requirements.

Best regards,

Wojciech Domski

Domski.pl

Wojciech.Domski.pl





More information about the Xenomai mailing list