On Tue, May 31, 2011 at 2:53 PM, Reinhard Meyer <u-b...@emk-elektronik.de> wrote: > Dear Simon Glass, > >> On Mon, May 30, 2011 at 5:24 PM, Graeme Russ<graeme.r...@gmail.com> >> wrote: >>> >>> Hi Reinhard, >>> >>> On Tue, May 31, 2011 at 4:57 AM, Reinhard Meyer >> >> ... >>>> >>>> make_timeout() can be arch/soc/platform specific and take into account >>>> to return at least >>>> 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)) >>> ... >>> >> >> Hi Graham, >> >> I like this, although I have a small preference for: >> >> u32 stop = time_get_future_ms(1234); >> >> while (!time_reached(stop)) >> .. > > I would perfectly like such a solution, it is equivalent to what I have been > proposing > almost a year ago!
Don't forget the API will have a get_current_ms() so we can do duration measurements. So you could still accidentally do: u32 stop = get_current_ms() + 1234; bypassing the resolution correction. If time_reached() did the resolution correction, would this solve the problem of API misuse (yes, I know it puts a complicated calculation back in the loop) >> since it possibly means the processing happens up front. However any >> such function is good and I hope you can add it to your API. > > Exactly! And (saying it silently) this would not mandate that the now hidden > internal > timer needs to be in ms units, it could be the bare "natural" tick of the > hardware... > Making time_get_future() to return the "tick" (in whatever granularity) that > has to > be passed would reduce time_reached() to a very simple function. Half the point of refreshing the timer API was to solidify the fact that timers operate on a fixed time base (milliseconds or microseconds) so they can be used trivially for a variety of things (delays, timeouts, durations measurement etc). Ticks can be very short, so doing durations would require 64-bit 'start tick', and a conversion at the end: u64 start = get_current_tick(); ... do something ... u32 duration = ticks_to_ms(get_current_tick() - start); Yetch! - We will not be exposing ticks! > But I get the feeling that exactly this simplicity of above concept is the > problem > for people that have the urge to invent elaborate and complicated solutions > ;) I like simple as much as the next guy - I also like hard to misuse ;) Regards, Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot