Re: [uCsimm] rtc and processor maintained clock

From: David Smead (smead@amplepower.com)
Date: Sat Jan 29 2000 - 05:08:18 EST


Bob,

Are you telling me that interrupt latency is one tick or less?

Sincerely,

David Smead
http://www.amplepower.com.
http://www.ampletech.com.

On Sat, 29 Jan 2000, Bob Lees wrote:

> David Smead wrote:
>
> > Bob,
> >
> > 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.
>
> >
> > Sincerely,
> >
> > David Smead
> > http://www.amplepower.com.
> > http://www.ampletech.com.
> >
> > 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.
> > > > mdurrant@rt-control.com
> > > >
> > > > This message resent by the ucsimm@uclinux.com list server http://www.uClinux.com/
> > >
> > > This message resent by the ucsimm@uclinux.com list server http://www.uClinux.com/
> > >
> >
> > This message resent by the ucsimm@uclinux.com list server http://www.uClinux.com/
>
> This message resent by the ucsimm@uclinux.com list server http://www.uClinux.com/
>

This message resent by the ucsimm@uclinux.com list server http://www.uClinux.com/



This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:34 EST