Yes, you would be correct if the timer is ticking at 1 millisecond granularity. However, I don't think this is the case at least with cpu/arm926ejs/omap/timer.c. It looks as if a countdown timer is simply decrementing at the frequency of its clock. I am not an OMAP expert but if anyone knows whether the timer is ticking in the ms range or not, please inform. There's nothing in the code to indicate as such.
Umar
-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: Thursday, June 21, 2007 1:44 PM To: Umar Quershey Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] CFG_HZ value
In message 87A697E50899F541B77272C331CEB744D506@exchange.Q-DOMAIN you wrote:
Ok, so just to clarify:
If I run the following code on a 1GHz machine vs. a 300 MHz machine
and
assuming that the read_reg always equals 0:
tmo = get_timer (0) + 1 * CFG_HZ; while ((((read_reg(0xa6)) == 0)&& tmo < get_timer (0)) /*NOP*/;
then the timeout should occur much quicker on the 1 GHz machine as opposed to the 300 MHz machine. The reason being that the timer will decrement much faster on the gig machine (assuming the timer is fed
the
system clock same as CPU).
No, this is not correct. The timeout will always oocur after one second. get_timer() returns the time (minus the offset passed in the argument) in milliseconds.
Is this a correct analysis or am I missing something? If true, then
the
Yes, you are missing that get_time() is counting in milliseconds.
timeout has to account for the clock of the timer (rate of timer
No, it has not.
Best regards,
Wolfgang Denk