John Kasunich wrote: > Sebastian Kuzminsky wrote: >> The "long period" argument to realtime functions registered with >> hal_export_funct()... It's in nanoseconds like hal.h says, right, not >> in cycles? Is it actual measured wallclock time since the previous >> invocation, or is it just reporting what the requested thread period was? > > Yes, it is in nanoseconds. It is not the time since the previous > invocation - it will always be the same value for a given thread. It is > not necessarily the requested period though, since the requested period > is usually rounded to hardware limitations (for the fastest thread) or > to a multiple of the fastest thread (for slower ones). 'period' is the > rounded value.
Ok, that makes sense. It would be useful for me to know the amount of time that passed between "the current reading of stepgen position" and "the previous reading of stepgen position", to accurately compute velocity. In a previous thread you warned me that rtapi_get_time() could be very slow on some systems. How should I measure intervals of wallclock time? Surely other drivers need this... -- Sebastian Kuzminsky Computer Science for life, that's my direction Instead of b-balls, my homies throw exceptions -- MC Plus+ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
