Rodrigo Rosenfeld Rosas wrote:
Philippe Gerum wrote:
...
Given the description above, just that some skin might return either
nucleus ticks or corrected timestamps to the applications, which would
in turn do some arithmetics for converting values they got from the skin
between both scales internally, and mistakenly use the result while
assuming that both scales are always in sync. In this situation, and
during a fraction of the time (i.e. the jitter), both scales might not
be in sync, and the result would be unusable.
But I still can't find a real situation where the user would need these values
to be in sync...
...
But maybe we are still discussing different issues actually, so it would
be useful that the core issue that triggered the discussion about
periodic mode precision be exposed again.
The core issue is that:
I think the driver development should be kind of independent from the user
programs. That said, if the driver needs a precise timestamp, it should be
able to get it, even if the user is fine with a, say, 100ms periodic tick. If
the user have a loop with a deadline of 100ms, and if it takes two
consecutive images for estimating speed in the same loop, the user will need
to have a higher precision timestamps for the images. So, the driver will
need a high precision timer reading for making possible to provide those
timestamps...
This is exactely what rt_timer_tsc() or clock_gettime(CLOCK_MONOTONIC)
[or whatever ends up calling xnarch_get_cpu_tsc() from the underlying
architecture] are there for.
The thing is that rt_timer_read() is expected to return values
compatible with the timer mode, always. But rt_timer_tsc() is there to
return the most precise timestamp available from the underlying
architecture, regardless of the current timing mode. If no TSC exists on
x86, then it is going to be emulated (using the PIT's channel #2), but
in any case, you will get a high precision timestamp, up to the best
precision the architecture can provide, that is.
The key issue is to acknowledge the fact that periodic ticks and precise
timestamps are two _unrelated_ units. What I'm reluctant to is to try
finding some artificial binding between both units, because there is
none (being stable, that is).
In your example above, you would be able to estimate the elapsed time
using something like rt_timer_tsc(), and convert this to ticks using
rt_timer_ns2ticks(rt_timer_tsc2ns(timestamp)). The main problem would be
the rounding here, and work around the lack of precision the periodic
mode currently exhibits due to the constant delay between timer shots.
I think that you should try convincing Jan that rtdm_clock_tsc() might
be a good idea to provide, instead of tweaking rtdm_clock_read() in a
way which changes its underlying logic. ;o)
I hope that was what you were asking for...
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
[email protected]
https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
_______________________________________________
Xenomai-core mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-core
