Em Terça 14 Março 2006 16:00, Jan Kiszka escreveu:
>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).
But that is exactly what I need. Suppose that a robot control system uses two
images to estimate the robot speed. The application may need a control loop
of, say, 100ms, putting the periodic timer set to 1, 10 or 100ms. But,
suppose that in each loop it takes two images in a short time interval (less
then 100ms or even less then 1ms) and the real time interval is very
important. So the driver must pass the timestamp of each captured frame to
application loop. But those times shouldn't be multiple of the timer tick,
but the real time with all precision it can get.
I'm not talking especifically about this application, but giving you a general
idea of what is not possible to do currently with RTDM if the application set
the timer to periodic.
Regards,
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
