[U-Boot] [RFC][Timer API] Revised Specification - Implementation details

[Graeme Russ <graeme.russ@gmail.com>]

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