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 

I hope that was what you were asking for...



Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!

Xenomai-core mailing list

Reply via email to