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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
