Ok, the system clock must be a fair ways off. I adjusted the frequency
of the on-board clock so that over a few hours, it aggrees very
closely with the system cock. I had assumed the system would not gain
or lose more than small fractions of a second every day. This brings
up another issue of how the optional on-board battery-backed real-time
clock (which I have) interacts with all of this. What is the accuracy
of the battery-backed real-timer clock? I have noticed that the "date"
command line function does NOT set the battery-backed clock, so, the
next time you re-boot, the system time is NOT correct. Well, I have
lots of little issues I am working on . . . .
On 4/17/06, Jesse Off <> wrote:
>
> --- In "Don W Carr`" <> wrote:
> >
> > I have been testing this timer using the example code, and find the
> > speed, at least on the 7260 I have to be close to 983.285 Khz.
>
>
> The speed is 983040, exactly. It is the external 14.7456Mhz crystal
> input divided by 15. All you should have is the 50PPM error in the
> 14 Mhz crystal. The Linux system tick (and gettimeofday()),
> however, is much less accurate. Linux wants a precise 100.0Hz
> system tick which cannot be arrived at perfectly from the ep93xx
> timing hardware. All we can get is something like 100.09Hz (I can't
> recall exactly what it is)
>
>
> Also,
> > I also created a similar macro that gives micro-seconds instead of
> > mili-seconds:
> >
> > #define FRTimerToUs(A) (((unsigned long long) A) * 1000000ULL /
> > 983285ULL)
>
>
> Here's another way. long-long division on an ARM is a very slow
> operation. The below uses the 32bit by 32bit multiply with 64bit
> result insn. I wrote these functions for the NetBSD port so
> gettimeofday() can interpolate time between clock ticks.
> gettimeofday() on the current 2.4 ep93xx Linux returns times only as
> precise as the system tick rate (~100Hz) and does not use TIMER4 to
> return more precise timestamps. I think this is changed in 2.6
> though.
>
> /* This is a quick ARM way to multiply by 983040/1000000 */
> #define US_TO_TIMER4VAL(x) { \
> u_int32_t hi, lo, scalar = 4222124650UL; \
> __asm volatile ( \
> "umull %0, %1, %2, %3;" \
> : "=&r"(lo), "=&r"(hi) \
> : "r"((x)), "r"(scalar) \
> ); \
> (x) = hi; \
> }
>
> /* This is a quick ARM way to multiply by 1000000/983040 */
> #define TIMER4VAL_TO_US(x) { \
> u_int32_t hi, lo, scalar = 2184533333UL; \
> __asm volatile ( \
> "umull %0, %1, %2, %3;" \
> "mov %1, %1, lsl #1;" \
> "mov %0, %0, lsr #31;" \
> "orr %1, %1, %0;" \
> : "=&r"(lo), "=&r"(hi) \
> : "r"((x)), "r"(scalar) \
> ); \
> (x) = hi; \
> }
>
>
> //Jesse Off
>
>
>
>
>
>
>
>
> ________________________________
> YAHOO! GROUPS LINKS
>
>
> Visit your group "ts-7000" on the web.
>
> To unsubscribe from this group, send an email to:
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
> ________________________________
>
--
Dr. Don W. Carr
J. G. Montenegro 2258
Guadalajara, Mexico
+52-333-630-0704
+52-333-836-4500 ext 2930
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|