Dear "J. William Campbell",
In message <4e1cf2e0.1030...@comcast.net> you wrote:
>
> Yes, this is true. However, the time_elapsed_since routine can do
> this dynamically (i.e. add twice the timer resolution) . I think you had
That would IMHO be a very bad idea. We have a number of places where
we have to deal with pretty long timeouts (usually because of protocol
specifications that require this - often in the order of several
seconds), where the normal path is very fast. The typical approach is
to break the timeout into a large number of very short loops.
Sometimes we use udelay() for this, other places use get_timer().
So assume we have a timeout of 5 seconds, and implement this as 50,000
loops of 100 microseconds. If you silently turn each of these into 20
milliseconds on NIOS, the timeout would become 1,000 seconds instead
of 5 - users would return boards as broken and report "it just
freezes" because nobody expects that it will wake up again after some
16 minutes.
> another function name (at_least) involved, but you can define
> time_elapsed_since as always compensating for the resolution. That will
> fix any resolution questions in a processor-specific way. It is either
> that or the ifdefs. One way or another, the resolution must be
> addressed. Up to now, the implicit resolution has been 1 ms, but we now
> know that is not general enough.
It's not as simple as this. You have to change a lot of code to make
this work for such slow clock systems.
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
Sometimes a man will tell his bartender things he'll never tell his doctor.
-- Dr. Phillip Boyce, "The Menagerie" ("The Cage"),
stardate unknown.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
