On 28/05/11 16:18, Reinhard Meyer wrote: > Dear Graeme Russ, >> u32 get_timer(u32 base) >> { >> if (base != 0) { >> if (timer - base< (CONFIG_MIN_TIMER_RESOLUTION * 2)) >> return 0; >> else >> return timer - base - CONFIG_MIN_TIMER_RESOLUTION; >> } else { >> return timer; >> } >> } > > This is not good. get_timer() should not do more than just return the timer > difference since epoch and not contain any funky logic. > > I might point again to my futile suggestion of simply calculating the "end > tick" > of a timeout loop at begin of the loop and inside the loop just checking > whether that > "end tick" has passed. > > When that were used, none of those complicated quirks that were devised in > this > thread would be needed. Just calculate the "end tick" by rounding it up by one > and all is pretty simple...
This will not work - Example (10ms wait with 10ms timer resolution) get_timer(0) @ 109ms returns 100 end_time = 110 end_time will be reached in 1ms, not 10 as expected To make this work, you will need to do the resolution adjustment _at the timing loop_ - This is the last place to expect to have to make such an adjustment Alternatively, add _another_ API function: end_time() which does the adjustment: end_time = end_time(timeout); while (get_timer() < end_time) { /* Do Stuff */ } But this also is not failsafe: end_time = get_timer() + timeout is, to me, a more natural expression of what is desired and what many programmers are likely to write (naively ignorant of resolution concerns) It's all a matter of degrees and what is the lesser of two (or three or four) evils ;) Regards. Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot