On Fri, May 27, 2011 at 4:52 AM, J. William Campbell jwilliamcampbell@comcast.net wrote:
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
How will sync_timebase() know that a rollover has happened before all 1's?
We would then need to tell sync_timebase() what the maximum value returned by get_ticks() is. Easier to do have get_ticks() handle it as that is a platform specific detail
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
Correct - the tick counter is a platform specific implementation detail and therefore the implementation of the HAL (get_ticks()) must also be platform specific
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).
But how do you handle cases like the sc520 - A microsecond counter which counts 0-999, kicking a 16-bit millisecond counter on rollover. Reading of the millisecond counter latches the microsecond counter and resets the millsecond counter to zero
There is no uniform tick counter to read - It has to be fudged - in get_ticks()
Regards,
Graeme