[U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Graeme Russ
graeme.russ at gmail.com
Sat May 28 10:59:20 CEST 2011
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
More information about the U-Boot
mailing list