Re: [Xenomai-core] RTDM and Timer functions

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

Em Ter=E7a 14 Mar=E7o 2006 03:44, Jan Kiszka escreveu:

>Rodrigo Rosenfeld Rosas wrote:
>> Em Segunda 13 Mar=E7o 2006 20:05, Jan Kiszka escreveu:
>>> ...
>>>
>>>>> We would definitely need a good name for it,
>>>>> rtdm_clock_read_ex(<clock-id>), rtdm_clock_read_tsc(),
>>>>> rtdm_clock_read_monotonic()? I'm not going to break rtdm_clock_read()
>>>>> by adding an argument (otherwise, I would have to fix too many drivers
>>>>> on my own... :-/).
>>>>
>>>> That is the idea, I think. I agree that rtdm_clock_read() should be ke=
pt
>>>> as it is (the API/definition). No body is asking you to change it.
>>>> Adding rtdm_clock_read_tsc() would be sufficient in my opinion whilst =
it
>>>> maintain coherency with other skins.
>>>
>>> Thinking about this more thoroughly, a few questions popped up for me:
>>>
>>> o When we call it rtdm_clock_read_tsc(), we should actually return the
>>>  raw TSC values, shouln't we? But then we also need conversion
>>>  functions (rtdm_clock_tsc2ns, rtdm_clock_ns2tsc). Or should we always
>>>  convert to nanoseconds on return? POSIX and Native are different in
>>>  this regard.
>>
>> I would prefer returning always ns, but both solutions would fit my need=
s,
>> so I'm not really worried about this topic.
>>
>>> o What would be the core rationale behind it, having a high-resolution
>>>  time stamp? What are the primary use cases? I'm asking for this so
>>>  that I can clearly differentiate between this new service and the
>>>  existing one in the docs. Also, giving an abstract description would
>>>  leave more options to the actual implementation on other archs or
>>>  platforms.
>>
>> As I've said, I think that it is good to give some independency to the
>> driver, at least to the time related functions, for not depending on the
>> user chosen timer behaviour for some delay routines. Eg, I would like to
>> wait a specified amount of us before testing some register. That is a
>> quite normal task when
>
>This is what rtdm_task_busy_sleep() already provides - independent of
>the system timer.

I didn't know it was independent from the timer. Good to know. I think it=20
would worth enforce this statement on its documentation.

>> developing drivers. Another one is for timeouts on short delays. In those
>> cases, we want a good resolution, but this should be independent of the
>> user's timer choice IMO.
>
>And this is something rtdm_clock_read_tsc() will obviously not be for.

Please, take a look in my case. The specification recommends wait at least =
Xus=20
before testing a bit. But the time to wait is not constant, it can vary a f=
ew=20
microseconds. So, I busy wait Xus and then do some code like:

rtdm_task_busy_sleep(X*1000);
start_time =3D rtdm_clock_read[_tsc]();
do {
condition=3Dtestbit();
} while (! condition && (time_passed(start_time) < TIMEOUT));

But if the user specifies a periodic timer, with tickval=3D1ms, then my dri=
ver=20
will be too slow. I could busy wait TIMEOUT before testing, and it would be=
=20
faster then the above code in this case. But I would like to go away as soo=
n=20
as possible, ie, just after the bit has been set...

>
>Again, when the user / system administrator decided to lower the timer
>resolution in favour of performance, it is not possible (and doesn't
>make sense) to circumvent this decision at driver level (except for busy
>waiting).

But my situation is still a busy wait but written in another form.

>So, I wonder what you plan to do with the return value of the=20
>new function?

I think I've already explained myself.

Best regards,

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com