Dear "J. William Campbell",
In message <4ddeafe0.8060...@comcast.net> you wrote:
>
> I certainly agree using 64 bits for all calculations is vast overkill.
> In fact, I think using 64 bit calculations on systems that have only a
> 32 bit or less timer register is probably overkill. :-) However, to
> date,AFAIK, no processor has exceeded the u32 in ticks per second. As I
Not yet. But it makes no sense to start a new design with settings
already in critical range, especially since there is zero problem
with breaking it down by a factor of 1000 or 1e6.
> pointed out in a previous e-mail, if they ever do this, we can just drop
> one or 2 bits off the 64 bit counter and in millisecond resolution,
> nobody will ever know. Also as previously pointed out, usec2ticks is
No. I will not accept a design that is so close on the edge of
breaking.
What is your exact problem with the existing interfaces ticks2usec()
and usec2ticks() ?
> not present yet in lots of implementations. Also, if the fundamental
> clock frequency is 32 kHz (or anything less than 1 MHz), usec2ticks is
> 0! This probably rules out using it to get ticks per millisec or ticks
> per sec.
The statement "usec2ticks is 0" makes absolutely no sense as long as
you don't say which argument you pass in. You get a return value of
0 even for a tick rate in the GHz range if you pass 0 as argument.
Hoewver, usec2ticks(1000) or maybe usec2ticks(100000) will probably
return pretty useful values.
[Note that by passing properly scaled arguments you can also avoid a
number of rounding errors.]
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
Any sufficiently advanced technology is indistinguishable from magic.
- Arthur C. Clarke
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
