On Wed, Jun 15, 2011 at 11:27 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon,
On Thu, Jun 16, 2011 at 3:53 PM, Simon Glass sjg@chromium.org wrote:
Hi Graeme,
On Wed, Jun 15, 2011 at 4:09 PM, Graeme Russ graeme.russ@gmail.com wrote: [snip]
BTW should the deltas return a signed value?
No - times are unsigned utilising the entire range of the u32 so (to - from) will always returned the unsigned delta, even if there is a wrap between them. I cannot imagine we would ever need to measure time backward anyway.
Can you please explain this again in different words as I don't follow. The difference between two unsigned times may be +ve or -ve, surely. For example, say:
now = 100 event_time = 200
then the delta is currently -100. Some people might loop until the delta is >= 0. This is like setting a future time and waiting for it to happen. If the delta is unsigned then this won't work.
start = 0xffffff00 now = 0x00000010
So there was a timer wrap between 'start' and 'now'
delta = now - start = 0x110
Remember that the new timer API does not rely on the tick counter (and therefore the ms/us timers) to start at zero - It must be allowed to wrap without causing timer glitches at any arbitray time
Hi Graeme,
Yes I'm fine with that last bit.
Taking your example, say now is 0xffffff00. Then:
unsigned stop_at = time_now_ms() + 0x110; // stop_at = 0x10
int diff = time_since_ms(stop_at)
I think this will set diff to -0x110, right? You can then wait until diff goes +ve, at which point you know your timeout has passed. I think it is useful for the time delta to be negative or positive, for this reason. I suppose what I am saying is that there are two ways of doing timeouts:
1. Record the start time, then wait until the delta gets big enough
2. Record the finish time, then wait until it arrives.
The latter can be useful if you have multiple timeouts in progress at once, something I am thinking we may want to do with USB scanning.
Regards, Simon
Regards,
Graeme