[Xenomai-help] Re: RTDM and udelay

[Jan Kiszka <jan.kiszka@domain.hid>]

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