Dear Graeme Russ,
Hi Reinhard,
On Tue, May 31, 2011 at 2:07 PM, Reinhard Meyer u-boot@emk-elektronik.de wrote:
Dear Graeme Russ,
Hi Reinhard,
On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer u-boot@emk-elektronik.de wrote:
Dear ALL,
it still escapes me why everyone tries to make things so complicated INSIDE the loop.
Why not just define an API like this:
u32 timeout = make_timeout(5); /* minimum 5 millisecond timeout */ u32 start = get_timer();
while ((get_timer() - start)< timeout) ...
The would work if we typedef'd 'timeout'. Otherwise, one runs the risk of not calling make_timeout() and assuming get_timer() always has a 1ms resolution
If you think people cannot follow API conventions, then typedef it...
make_timeout() can be arch/soc/platform specific and take into account to return at least
Actually, make_timeout() would not need to be platform specific - All it needs is a get_min_ms_resolution() which wuld be a simple inline usually returning a const so the compiler would optimise it away
such a value that the timeout is never cut short. (In case of a 10 ms NIOS timer, make_timeout(5) would have to return the value 20, resulting in a real timeout of at least 10 ms but upto 20 ms )
What about this:
u32 start = get_timer(); while (!timer_expired(start, timeout)) ...Again.. why put the complicated calculations INSIDE the loop?
Well, the calculations are hidden from the user, and we aren't running a high performance system. Also, the most complex calculations will be performed each time you call get_timer() anyway. The additional overhead of performing a precision rounding will be insignificant
Best to make the API as defensive as possible rather than try to trim off a few CPU instructions per loop.
Excuse me, but THIS API does not prevent the user to do a "(get_timer() - start) < timeout" inside the loop, making your argument moot. But as I said before, it escapes me why by all means the loop must be more complicated and obscure (on the user side) then essentially necessary...
Regards,
Reinhard