[Xenomai-help] RTDM and udelay

[Xenomai-help] RTDM and udelay

[Rodrigo Rosenfeld Rosas]

Is there any alternative to udelay on RTDM?

Or should I do something like:

void rt_udelay(unsigned int usec) {
  uint64_t timeout = rtdm_clock_read () + usec;
  while (rtdm_clock_read () < timeout);
}

Or maybe my design is wrong.

I have a function, say WriteI2C(...). Should I create it as a task and call 
rtdm_task_sleep?

Thanks,

Rodrigo.

	

	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html 

[Xenomai-help] Re: RTDM and udelay

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

Rodrigo Rosenfeld Rosas wrote:
> Is there any alternative to udelay on RTDM?
> 
> Or should I do something like:
> 
> void rt_udelay(unsigned int usec) {
>   uint64_t timeout = rtdm_clock_read () + usec;
>   while (rtdm_clock_read () < timeout);
> }

You mean something like this: =:)

http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/skins/rtdm/drvlib.c?v=SVN-trunk#L366

> 
> Or maybe my design is wrong.
> 
> I have a function, say WriteI2C(...). Should I create it as a task and call 
> rtdm_task_sleep?

Depending on how long you would like to sleep and if you are not inside
an IRQ handler, a re-scheduling call like rtdm_task_sleep() can be
better. If it's just about a few microseconds, busy sleeping should be
preferred.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[Xenomai-help] Re: RTDM and udelay

[Rodrigo Rosenfeld Rosas]

Rodrigo Rosenfeld Rosas wrote:

>>Is there any alternative to udelay on RTDM?
>>
>>Or should I do something like:
>>
>>void rt_udelay(unsigned int usec) {
>>  uint64_t timeout = rtdm_clock_read () + usec;
>>  while (rtdm_clock_read () < timeout);
>>}
>>    
>>
>
>You mean something like this: =:)
>
>http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/skins/rtdm/drvlib.c?v=SVN-trunk#L366
>  
>
Yes, but it seemed too complex for me, since it disables IRQ and I do 
not need this feature. It will no problem if, instead of waiting 2us, I 
have to wait 100us because some interrupt has occurred. After I write to 
the board i2c registers, I need to wait *at least*, say, 2us before 
writing another i2c cycle.

One more thing: although the name of the function has the word "task", I 
think it is not task specific. Documentation even says it can be called 
from initialization/cleanup code. But it doesn't say if it can be called 
from an ioctl handler or any other context, although I see no problem 
when reviewing the code. Thus, I think a better name would be something 
like rtdm_busy_sleep() or rtdm_ns_delay(). Just a suggestion.

>>Or maybe my design is wrong.
>>
>>I have a function, say WriteI2C(...). Should I create it as a task and call 
>>rtdm_task_sleep?
>>    
>>
>
>Depending on how long you would like to sleep and if you are not inside
>an IRQ handler, a re-scheduling call like rtdm_task_sleep() can be
>better. If it's just about a few microseconds, busy sleeping should be
>preferred.
>  
>
Exactly what I had in mind, thanks.

Best regards,

Rodrigo.


	

	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html 

[Xenomai-help] Re: RTDM and udelay

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]

Rodrigo Rosenfeld Rosas wrote:
> Rodrigo Rosenfeld Rosas wrote:
> 
>>> Is there any alternative to udelay on RTDM?
>>>
>>> Or should I do something like:
>>>
>>> void rt_udelay(unsigned int usec) {
>>>  uint64_t timeout = rtdm_clock_read () + usec;
>>>  while (rtdm_clock_read () < timeout);
>>> }
>>>   
>>
>> You mean something like this: =:)
>>
>> http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/skins/rtdm/drvlib.c?v=SVN-trunk#L366
>>
>>  
>>
> Yes, but it seemed too complex for me, since it disables IRQ and I do
> not need this feature. It will no problem if, instead of waiting 2us, I

Are we talking about the same function??? Don't think so.

> have to wait 100us because some interrupt has occurred. After I write to
> the board i2c registers, I need to wait *at least*, say, 2us before
> writing another i2c cycle.

Then this is the perfect choice for you.

> 
> One more thing: although the name of the function has the word "task", I
> think it is not task specific. Documentation even says it can be called
> from initialization/cleanup code. But it doesn't say if it can be called
> from an ioctl handler or any other context, although I see no problem
> when reviewing the code. Thus, I think a better name would be something
> like rtdm_busy_sleep() or rtdm_ns_delay(). Just a suggestion.

The idea is to put most functions into some related group. As
rtdm_task_busy_sleep() is an alternative to rtdm_task_sleep(), I placed
them close to each other in the doc, i.e. in the same group (rtdm_task_xxx).

Note that an ioctl handler (just like any device operation handler) has
no separate context. Depending on if we are talking about the _rt or the
_nrt handler, it either executes in a RT task or in non-RT context,
invoked by a user space or kernel space caller. All this is covered by
the environments listed for rtdm_task_busy_sleep.

> 
>>> Or maybe my design is wrong.
>>>
>>> I have a function, say WriteI2C(...). Should I create it as a task
>>> and call rtdm_task_sleep?
>>>   
>>
>> Depending on how long you would like to sleep and if you are not inside
>> an IRQ handler, a re-scheduling call like rtdm_task_sleep() can be
>> better. If it's just about a few microseconds, busy sleeping should be
>> preferred.
>>  
>>
> Exactly what I had in mind, thanks.
> 
> Best regards,
> 
> Rodrigo.
> 

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[Xenomai-help] Re: RTDM and udelay

[Rodrigo Rosenfeld Rosas]

>>>>Is there any alternative to udelay on RTDM?
>>>>
>>>>Or should I do something like:
>>>>
>>>>void rt_udelay(unsigned int usec) {
>>>> uint64_t timeout = rtdm_clock_read () + usec;
>>>> while (rtdm_clock_read () < timeout);
>>>>}
>>>>  
>>>>        
>>>>
>>>You mean something like this: =:)
>>>
>>>http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/skins/rtdm/drvlib.c?v=SVN-trunk#L366
>>>      
>>>
>>Yes, but it seemed too complex for me, since it disables IRQ and I do
>>not need this feature. It will no problem if, instead of waiting 2us, I
>>    
>>
>Are we talking about the same function??? Don't think so.
>  
>
Is there any related function that do not disable IRQ? I know it is not 
a big deal and I'll use the suggested function if there is no 
alternative, but I would prefer using some delay function that will not 
disable interrupts when delaying.

>>have to wait 100us because some interrupt has occurred. After I write to
>>the board i2c registers, I need to wait *at least*, say, 2us before
>>writing another i2c cycle.
>>    
>>
>
>Then this is the perfect choice for you.
>
>  
>
>>One more thing: although the name of the function has the word "task", I
>>think it is not task specific. Documentation even says it can be called
>>from initialization/cleanup code. But it doesn't say if it can be called
>>from an ioctl handler or any other context, although I see no problem
>>when reviewing the code. Thus, I think a better name would be something
>>like rtdm_busy_sleep() or rtdm_ns_delay(). Just a suggestion.
>>    
>>
>
>The idea is to put most functions into some related group. As
>rtdm_task_busy_sleep() is an alternative to rtdm_task_sleep(), I placed
>them close to each other in the doc, i.e. in the same group (rtdm_task_xxx).
>
>Note that an ioctl handler (just like any device operation handler) has
>no separate context. Depending on if we are talking about the _rt or the
>_nrt handler, it either executes in a RT task or in non-RT context,
>invoked by a user space or kernel space caller. All this is covered by
>the environments listed for rtdm_task_busy_sleep.
>  
>
Thanks for clarifying. One more doubt. Suppose my driver has only the 
non-RT close handler. If the user close the file descriptor from a 
RT-context, it will call the non-RT close handler? If yes, will that 
handler be called in a RT-context? If not, could I use the same handler 
(function) for both RT and non-RT handlers?

Thank you again,

Rodrigo.


	

	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html 

Re: [Xenomai-help] Re: RTDM and udelay

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3162 bytes --]

Rodrigo Rosenfeld Rosas wrote:
> 
>>>>> Is there any alternative to udelay on RTDM?
>>>>>
>>>>> Or should I do something like:
>>>>>
>>>>> void rt_udelay(unsigned int usec) {
>>>>> uint64_t timeout = rtdm_clock_read () + usec;
>>>>> while (rtdm_clock_read () < timeout);
>>>>> }
>>>>>  
>>>>>       
>>>> You mean something like this: =:)
>>>>
>>>> http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/skins/rtdm/drvlib.c?v=SVN-trunk#L366
>>>>
>>>>     
>>> Yes, but it seemed too complex for me, since it disables IRQ and I do
>>> not need this feature. It will no problem if, instead of waiting 2us, I
>>>   
>> Are we talking about the same function??? Don't think so.
>>  
>>
> Is there any related function that do not disable IRQ? I know it is not

rtdm_task_busy_sleep() as it is now *does not* touch the IRQ flag,
please have a look at the provided link. But this reminds me of a
potential issue when using it on SMP: a task being migrated while
running rtdm_task_busy_sleep may suffer from inconsistent TSCs on old
and new CPU. We have to address this somehow...

> a big deal and I'll use the suggested function if there is no
> alternative, but I would prefer using some delay function that will not
> disable interrupts when delaying.
> 
>>> have to wait 100us because some interrupt has occurred. After I write to
>>> the board i2c registers, I need to wait *at least*, say, 2us before
>>> writing another i2c cycle.
>>>   
>>
>> Then this is the perfect choice for you.
>>
>>  
>>
>>> One more thing: although the name of the function has the word "task", I
>>> think it is not task specific. Documentation even says it can be called
>>> from initialization/cleanup code. But it doesn't say if it can be called
>>> from an ioctl handler or any other context, although I see no problem
>>> when reviewing the code. Thus, I think a better name would be something
>>> like rtdm_busy_sleep() or rtdm_ns_delay(). Just a suggestion.
>>>   
>>
>> The idea is to put most functions into some related group. As
>> rtdm_task_busy_sleep() is an alternative to rtdm_task_sleep(), I placed
>> them close to each other in the doc, i.e. in the same group
>> (rtdm_task_xxx).
>>
>> Note that an ioctl handler (just like any device operation handler) has
>> no separate context. Depending on if we are talking about the _rt or the
>> _nrt handler, it either executes in a RT task or in non-RT context,
>> invoked by a user space or kernel space caller. All this is covered by
>> the environments listed for rtdm_task_busy_sleep.
>>  
>>
> Thanks for clarifying. One more doubt. Suppose my driver has only the
> non-RT close handler. If the user close the file descriptor from a
> RT-context, it will call the non-RT close handler? If yes, will that
> handler be called in a RT-context? If not, could I use the same handler
> (function) for both RT and non-RT handlers?

If a RT handler is missing, the caller is migrated to secondary mode
before the non-RT handler is invoked. And yes, if your close handler is
both RT and non-RT safe, you can registered it for both entry points.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Re: RTDM and udelay

[Rodrigo Rosenfeld Rosas]

Thank you Jan! No more questions for now. ;)

Rodrigo.


	

	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html