The battery backed RTC has a laser cut 32Khz crystal inside that is
supposedly a higher than typical accuracy crystal. Linux uses the
clock to bootstrap its own notion of time at the beginning of bootup
and then never uses it again. To set the date on the clock you
first set the Linux system time, then use the hwclock --systohc
command to write it to the hardware RTC.
//Jesse Off
--- In "Don W. Carr" <> wrote:
>
> 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`" <doncarr@> 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/
|