Dear Lee Jones, In message <20121121100228.gj28...@gmail.com> you wrote: > > > > -#define COUNT_TO_USEC(x) ((x) * 16 / 133) > > > +#define COUNT_TO_USEC(x) ((x) / 133 * 16) > > > > Before the change, the result is useful for all values of x in the > > interval from 0 through UINT_MAX/16 = 268435455 = 268 seconds, i. e. > > for all values that make sense to be measured in microseconds. > > We're actually discussing this elsewhere. I don't have > permission to paste the other side of the conversation, but > I can show you my calculations: > > > The original implementation is fine until we reach 32.28 seconds, which > > as you predicted is 0x1000_0000: > > > 0x10000000 * PRESCALER) / (CLOCK_SPEED_133_MHZ) > > (268435456 * 16 ) / (133 * 1000 * 1000) == 32.28 seconds > > > If we spend >30 seconds at the u-boot commandline, which is not > > unreasonable by any stretch, then the kernel assumes responsibility for > > the remaining of the time spent at the prompt, which is obviously not > > acceptable for this usecase.
This makes no sense to me. An overflow will not happen before UINT_MAX/16 = 268435455 = 268 seconds. Anyway. If you have overflof problems, then use proper arithmetics. > > If you need a bigger number range, then use proper arithmetics. It';s > > available, just use it. > > Would you be able to lend a hand here, as I'm no mathematician? > > What are the correct arithmetics? There are routines like do_div() or lldiv() etc. that can be used when 32 bit arithmetics is really not good enough. However, I fail to see why that should even be needed here. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "If God had wanted us to use the metric system, Jesus would have had 10 apostles." _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot