[Xenomai-help] Re: RTDM and udelay

[Rodrigo Rosenfeld Rosas <lbocseg@domain.hid>]

>>>>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