Ok, I am going to check the accuracy of the battery-backed clock and
the system clock. I have an atomic clock that syncs every night and is
always within 1 second.
If the battery backed clock is more accurate, it might make sense for
my application to call the following every 24 hours:
hwclock --hctosys
Don.
On 4/17/06, Jesse Off <> wrote:
> 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
>
>
> 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/
|