[Xenomai] Sensoray 626 analogy driver

Wojciech Domski wojciech.domski at gmail.com
Tue Mar 25 13:14:48 CET 2014

W dniu 25.03.2014 12:58, Gilles Chanteperdrix pisze:
> On 03/25/2014 12:54 PM, Wojciech Domski wrote:
>> W dniu 25.03.2014 12:36, Gilles Chanteperdrix pisze:
>>> On 03/25/2014 12:28 PM, Wojciech Domski wrote:
>>>> 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.
>>> This solution will not work if the busy loop was in an irq handler. You
>>> can not call rtdm_task_sleep from the context of an irq handler.
>> Ok, now I get your point.
>> However, what do you mean exactly by rescheduling while waiting? Do you
>> mean something like
>> putting all irq services into another thread and only in irq handler
>> notify the separate thread
>> to do the job accordingly?
> Well, I do not know exactly, I have not looked at the details of the
> driver, you are supposed to do that. But you may be able to split the
> interrupt code in two parts: a first part that will run in interrupt
> mode, and a second part that will run as a thread. The irq handler would
> wake the thread up at the end of the first part, and return without
> reenabling the interrupt at interrupt controller level. The thread would
> execute, sleep during the I2C transfers as needed, and reenable the
> interrupt before going back to sleep.
So would it be a good practise to create a new task for irq service with


inside attach function and join it with


inside detach function?

Wojciech Domski



More information about the Xenomai mailing list