David Smead wrote:
> 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.
The comments I have been making are referenced to the uclinux kernel as distributed on
the cdrom and patched with pre1. This is the current way the processor maintained
runtime clock and scheduling clock is derived. It may be that what you suggest below is
a better way of achieving this in the long term. It would allow for other timer events
to be used. I will look at this. The timer still wraps around at 0xffff, ie 65536 and
it may lose a tick at this point. We shall see.
> 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.
The way outlined below works. If you are aware that the clock reset is synchronous and
you allow for this lost tick. The lost tick is entirely predictable in this case.
> David Smead
> 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.
> > > email@example.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 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