I haven't looked at the code, but ...
This sounds like a design issue. You can't use a free running clock and
put some comparison value in it, resetting the clock each time you hit the
compare value. If you do, then all the clocks which occur between the
comparison and the interrupt service of it are `lost'. Perhaps this is
what you are seeing.
What has to be done is to have a fixed amount that is added to the
comparison value, and each time you hit the compare, and get to service
it, the compare value `increment' is added to give the next compare value.
This is the only way I know of not losing time.
On Fri, 28 Jan 2000, Bob wrote:
> 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.
> > firstname.lastname@example.org
> > 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 message resent by the email@example.com list server http://www.uClinux.com/
This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:34 EST