Hi Andreas,
Le 24/01/2011 09:25, Andreas Bießmann a écrit :
>> That's where I come back to one point of my proposal: if we can get a
>> general framework for get_timer() to return a 64-bit free-running tick
>> value, then we might not need a ms-based get_time() at all, because we
>> could use get_timer() as well for ms timings, provided we can convert
>> our timeout from ms to ticks, i.e.
>>
>> /* let's wait 200 milliseconds */
>> /* Timing loop uses ticks: convert 200 ms to 'timeout' ticks */
>> timeout = ms_to_ticks(200);
>> u32 start = get_timer(); /* start time, in ticks */
>> do {
>> ...
>> } while ( (get_timer() -start)< timeout);
>
> You may think about the following change to this proposal:
>
> /* lets wait 200 ms */
> /* get the end point of our timeout in ticks */
> u64 timeout_end = get_timer() + ms_to_ticks(200);
> do {
> ...
> } while ( get_timer()< timeout_end);
The problem here is that in the loop exit condition you replace a
difference between two unsigned times (which always yields the correct
duration) with a comparison of two dates (which does not).
For instance, if at loop entry get_timer() was, say, 10 ticks to
rollover and the loop timing was 12 ticks, you end up with an end date
of 2. If your loop body runs long enough, get_timer() may already have
gone past this and will this stay greater than timeout_end for a very
long time.
OTOH, using get_timer() on entry of loop and subtracting it from
get_timer() at each loop iteration always yields the time elapsed,
unaffected by rollover. You can then safely compare this elapsed time
with the time-out value.
Amicalement,
--
Albert.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
