Rodrigo Rosenfeld Rosas wrote:
> Em Terça 14 Março 2006 03:44, Jan Kiszka escreveu:
>> Rodrigo Rosenfeld Rosas wrote:
>>> Em Segunda 13 Março 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 kept
>>>>> 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 needs,
>>> 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 
> 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 
> before testing a bit. But the time to wait is not constant, it can vary a few 
> microseconds. So, I busy wait Xus and then do some code like:
> rtdm_task_busy_sleep(X*1000);
> start_time = rtdm_clock_read[_tsc]();
> do {
> condition=testbit();
> } while (! condition && (time_passed(start_time) < TIMEOUT));
> But if the user specifies a periodic timer, with tickval=1ms, then my driver 
> will be too slow. I could busy wait TIMEOUT before testing, and it would be 
> faster then the above code in this case. But I would like to go away as soon 
> as possible, ie, just after the bit has been set...

This is how the eepr100 driver of RTnet handles it, though RTnet would
not work very well in periodic mode. Actually, this has been ported over
from Linux where you do not have a portable API for reading the TSC, I

static inline int rt_wait_for_cmd_done(long cmd_ioaddr, const char *cmd)

    while (inb(cmd_ioaddr) != 0) {
        if (wait-- == 0)
            return 1;
    return 0;
(Hmm, BTW, de-inlining might be worth considering...)

So this works at a polling period of 1 us, but you may also reduce it,
though this would certainly degrade the accuracy further. For sure, the
accuracy is slightly worse than with your pattern. Would this matter to you?

>> 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 
>> new function?
> I think I've already explained myself.
> Best regards,
> Rodrigo.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to