On 5/26/2011 12:16 PM, Wolfgang Denk wrote:
Dear "J. William Campbell",
In message4DDEA165.9010403@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
I agree that that is what must happen, but it should happen insidesync_timebase. Sync_timebase does what is needed to convert the less-than-fully capable counters into a fully capable one. You could
I think you also want this behaviour for get_ticks().
Hi Wolfgang, I understand why that might be nice. But to do that with common code would require get_ticks to call a generic routine (say sync_ticks) that would expand the counter to 64 bits. Note that this is not always totally trivial, as the timer may roll over at 10 ms or some other not-so-nice number. Then sync_timer would convert the 64 bit number to milliseconds. That approach will work. However, I think that is overkill, as we really want the result in milliseconds. If you look at the prototype sync_timer routine, you can see an example of how this is possible without resorting to 64 bit math. I think that avoiding the 64 bit math on processors that don't have a 64 bit tick counter (and are therefore probably less capable) is worthwhile. I also think that the purpose of the get_time routine abstracting the time into milliseconds is to avoid dealing with ticks anywhere except in the timer routines. Presumably, nobody but sync_timer would ever have reason to call get_ticks. If that is not your thinking, fine, we just disagree on that point, and having a sync_ticks to expand the tick counter certainly can be done.
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).
I think using ticks per second is not a good idea. It may exceed ULONG_MAX, and having to use 64 bit for all calculations is probably overkill. The existing ticks2usec/usec2ticks work fine so far.
I certainly agree using 64 bits for all calculations is vast overkill. In fact, I think using 64 bit calculations on systems that have only a 32 bit or less timer register is probably overkill. :-) However, to date,AFAIK, no processor has exceeded the u32 in ticks per second. As I pointed out in a previous e-mail, if they ever do this, we can just drop one or 2 bits off the 64 bit counter and in millisecond resolution, nobody will ever know. Also as previously pointed out, usec2ticks is not present yet in lots of implementations. Also, if the fundamental clock frequency is 32 kHz (or anything less than 1 MHz), usec2ticks is 0! This probably rules out using it to get ticks per millisec or ticks per sec.
Best Regards, Bill Campbell
Best regards,
Wolfgang Denk