Re: [uCsimm] rtc and processor maintained clock

From: Bob Lees (rhl@diamond.demon.co.uk)
Date: Tue Feb 01 2000 - 15:21:08 EST


David

Which tick are we talking about here? If you are referring to the timer/counter tick then
the synchronous reset after reaching the compare value will take place in one timer/counter
tick by definition. This will happen irrespective of the processor as the timer/counter is
in effect a separate piece of silicon on the same wafer as the rest of the micro-controller,
at least that's how I understand this micro-controller is implimented.

As far as 10ms clock ticks, I have no idea what the latency is but I'm fairly sure this info
is somewhere in the motorola doco. The linux kernel copes with the concept of missed ticks
providing the interrupt controller for the device is at least reset and that should happen be
ok.

Anyway the approach outlined before seems to be working as predicted for some days now with
the amount of drift the theory says should be present actually being the case in the real
world. It's nice that the theory sometimes actually turns into practice, rare but nice. In
any case the problem originally posted is now overcome and we can move onto the nest stage
which is to get our large execs to compile and run .... the saga continues.

PS for anyone who is following this we have run the clock at a 1ms rate (ie 1khz) and the
processor coped fine. It loaded it up a bit :) but maintained time ok.

Another thought, has anyone tried to use any other timing source, I'm thinking of the lcd or
pwm timers to generate the scheduler clock so that the timer/counter can be used for other
functions??

Bob

David Smead wrote:

> 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.
> > >

>>>>>> ...stuff deleted

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