--- 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
<*> 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/
|