On 5/26/2011 10:53 AM, Wolfgang Denk wrote:
Dear "J. William Campbell",
In message4DDE8639.3090909@comcast.net you wrote:
I think it is the task of get_ticks to return the hardware tick counter as an increasing counter, period. The counter may wrap at some final count that is not all ones. That is ok. Sync_timebase deals with the
NO! We want to be able to compute time differences using simple unsigned arithmentics, even after a rollover of the counter. For this it is mandatory that the counter always gets only incremented until it wraps around at te end of it's number range, and never gets reset
Hi All, I agree that that is what must happen, but it should happen inside sync_timebase. Sync_timebase does what is needed to convert the less-than-fully capable counters into a fully capable one. You could move that functionality down into get_ticks, but if you do, you end up much like the present scheme where the multiple different get_ticks routines expected to cope with expanding the hardware counter properly. To date, it has been shown conclusively that this process cannot be relied upon, or we wouldn't be having this discussion. If we put that functionality inside sync_timebase, it is in one place and debuggable once. All sync_timebase requires to do this is ticks per second and maximum tick value. I do request that counters that decrement be negated in the get_ticks routine, but beyond that, it should be a simple read of the tick register(s).
Best Regards, Bill Campbell
before.
You will have to call the routine that initializes sync_timebase. This routine should have a name, like void init_sync_timebase(void)?
init_timebase().
Best regards,
Wolfgang Denk