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
>static inline int rt_wait_for_cmd_done(long cmd_ioaddr, const char *cmd)
>    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.

Thank you,


Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!

Xenomai-core mailing list

Reply via email to