Re: [Xenomai-core] RTDM and Timer functions

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

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

Rodrigo Rosenfeld Rosas wrote:
> Em Terça 14 Março 2006 13:59, Rodrigo Rosenfeld Rosas escreveu:
> 
>> Em Terça 14 Março 2006 13:46, Jan Kiszka escreveu:
>>>>>> ... 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
>>> think.
>>>
>>> static inline int rt_wait_for_cmd_done(long cmd_ioaddr, const char *cmd)
>>> {
>>>    int wait = CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT;
>>>
>>>    while (inb(cmd_ioaddr) != 0) {
>>>        if (wait-- == 0)
>>>            return 1;
>>>        rtdm_task_busy_sleep(1000);
>>>    }
>>>    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?
>> No, in my case it doesn't matter. I'll adopt this way of doing it.
> 
> Thinking better, I would need such a function for registering the timestamp of 
> the captured frame on the irq handler...
> 

What will this timestamp be used for, relative time calculations? I just
would like to remind that the output of rtdm_clock_read_tsc() will not
be in sync with the system clock in periodic mode (one of my major
concern: that driver writers forget this fact).

Jan


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