Michael Durrant wrote:
> > We have an application which requires accurate timing in the short term,
> > little on no drift within say 5 minutes. The ucsimm seems a good
> > starting point and we have one which is working fine, I think. We have
> > been doing some timing tests and it appears that the processor
> > maintained clock is running approx 7% slower than real time and the rtc
> > on the ucsimm. That is the processor maintained clock is loosing 7
> > seconds in every 100.
> Their can be many reasons for this possibly dram refresh and or
> dma for the lcd. Both of these steal bus time from the cpu.
Nope. Found it, at least I think I have. The 16 bit timer is free running. In the
mode it is being used for as the time source, when the compare value is reached, the
current count value is set to zero. It appears that this is a synchronous reset, ie
it is taking a pre-scaled clock cycle to reset to zero. So when TCMP is being
loaded with 10, it is actually taking 11 pre-scaled clock cycles per overall cycle.
This has implications for any use of the timer/counter in this mode.
32768 / 32 = 1024 / 11 = 93.09. Which within experimental error is what I'm seeing.
So for those of us who want close to real time the following seem to work and can be
verified by putting a scope on the TIO pin with output enabled
32768 / 3 = 10922.67; 10922 / 109 = 100.20
32kHz source; pre-scale by 3 (TPRE = 2); compare to 109 (TCMP = 108)
1036288 / 3 = 345429.33; 345429 / 3454 = 100.01
sysclk / 16 source; pre-scale by 3 (TPRE = 2); compare to 3454 (TCMP = 3453)
So you pays your money, you takes your choice of source, notwithstanding the
correctness of the 32kHz source, it's slighty more accurate with sysclk.
Someone who understands the correction code in sched.c for the clock could probably
come up with a way of correcting for the error at 32kHz and that would be good.
For those that wish to make these changes in pre1
/opt/uClinux/linux/arch/m68knommu/platform/68EZ328/config.c in function
BSP_sched_init is where these values are setup. No diff files cause of the choices
offered. I guess this could be conditional compilation, if required I can do this
and submit the diffs.
> ... stuff deleted
> > We have looked around all the init code and the various timers appear to
> > be setup ok. We are running a pre1 kernel. One interesting fact come
> > to light is the cpuspeed reported in /proc/cpuinfo is only 15.2MHz
> > rather than the 16.5ishMHz that is supposed to be running. We have not
> > changed any of the PLL settings. This difference is in the order of the
> > 7% we are looking for, so somewhere in the kernel timing code or timer
> > setup stuff something must be awry. The fact that the onboard rtc is
> > maintaining real time indicates that the 32kHz xtal is near enough the
> > correct frequency.
> The /proc/cpuinfo has not been verified to be accurate.
> Michael Durrant
> RT-CONTROL Inc.
> This message resent by the email@example.com list server http://www.uClinux.com/
This message resent by the firstname.lastname@example.org list server http://www.uClinux.com/
This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:34 EST