Dear Graeme Russ, > 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!
Moot argument again. Any fast 64 bit tick can be very simply brought into a 32 bit, just sub-ms granularity by a simple right shift. But I would also be happy with 64 bits as well, since all calculations in the loop would be just add/subtracts and no mul/divs. > >> 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 ;) typedefs would prevent accidental misuses, there is no cure against deliberate misuses except peer review... Reinhard _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
