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.
Thank you,
Rodrigo.
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
