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...
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
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
