All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Wojciech Domski <wojciech.domski@gmail.com>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] Sensoray 626 analogy driver
Date: Tue, 25 Mar 2014 13:33:21 +0100	[thread overview]
Message-ID: <53317791.3030106@xenomai.org> (raw)
In-Reply-To: <53317338.60805@gmail.com>

On 03/25/2014 01:14 PM, Wojciech Domski wrote:
> 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
> 
> rtdm_task_init();
> 
> inside attach function and join it with
> 
> rtdm_task_join_nrt();
> 
> inside detach function?

I do not know the details about analogy drivers, so, again, it is left
to you to read other analogy drivers and see where is the best place to
do what you want to do.


-- 
                                                                Gilles.


  reply	other threads:[~2014-03-25 12:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-28 14:12 [Xenomai] Sensoray 626 analogy driver Wojciech Domski
2014-03-04 20:14 ` Wojciech Domski
2014-03-22 16:36   ` Gilles Chanteperdrix
2014-03-24 12:09     ` Wojciech Domski
2014-03-24 12:19       ` Gilles Chanteperdrix
2014-03-25 10:26         ` Wojciech Domski
2014-03-25 11:16           ` Gilles Chanteperdrix
2014-03-25 11:28             ` Wojciech Domski
2014-03-25 11:36               ` Gilles Chanteperdrix
2014-03-25 11:54                 ` Wojciech Domski
2014-03-25 11:58                   ` Gilles Chanteperdrix
2014-03-25 12:14                     ` Wojciech Domski
2014-03-25 12:33                       ` Gilles Chanteperdrix [this message]
2014-04-10 12:25                         ` Wojciech Domski
2014-04-10 22:01                           ` Gilles Chanteperdrix
2014-07-07 10:38                             ` Wojciech Domski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53317791.3030106@xenomai.org \
    --to=gilles.chanteperdrix@xenomai.org \
    --cc=wojciech.domski@gmail.com \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.