Roman, is not true, I saw it and is already copy in my timer folder,
but what do you say about showing us the whole code who done this ...
or maybe just initialising tmr0 with xtal value in 24 bits.
Vasile


On Tue, 27 Feb 2001, Roman Black wrote:

> Paul Chicofsky wrote:
> >
> > Hello everybody,
> > I am having deficalty in getting the right dely to the clock i am
> > using for my pic16f877.  which i am using 20MHz clock.  I have
> > calculated a 1msec as follows:
>
>
> Hi Paul, nobody seemed to notice my last post re this
> but here is a good way to get any timer period you
> need with very little code:
>
>
>
> > Roman Black wrote:
> >
> > Hi Guys, I've implemented a version of Bob's
> > zero-error one second timer. I added two changes
> > and the whole thing fits in just a handful of
> > instructions. It will give perfect results with
> > any crystal speed (that divides evenly by 4).
> >
> > Basic theory: (example 16MHz crystal, 4MHz instruction)
> > * put one second value in 24bit var (4,000,000 ticks)
> > * the TIMER0 int is every 256 instructions
> > * every int we subtract 256 from value
> > * when value gets <0 we generate the one second event,
> >   and add another 4,000,000 ticks to var
> >
> > It has zero cumulative error and zero short-term
> > average error. There will be a max error per second
> > of 256 instructions (64uS at 16MHz crystal).
> >
> > The two changes I made from Bob's idea are;
> > * subtracting a set value of 256 (1x mid-byte)
> > * adding an extra 256 ticks at the start.
> >
> > The first change means that instead of doing a
> > proper 24bit subtract every int, you just need
> > to dec the mid byte of the var, (and do carry test
> > and dec msb if needed). Very fast and small code.
> >
> > The second change means the var never goes below
> > zero, instead our <0 test simply becomes a <256
> > test.. This is very quick, we just test that
> > msb=0 AND mid=0.
> >
> > This condition means that now to add the 4,000,000
> > ticks to the variable again we are guaranteed that
> > msb and mid bytes are 0, so we can simply load
> > the two values from literals straight into the
> > msb and mid bytes. We no longer need a proper
> > 24bit add! We must do an add on the lsb byte,
> > but this is only one byte add and one carry test.
> > If carry, we can just inc the mid byte, as it's
> > value is guaranteed.
> >
> > The whole thing is very small and quick as there
> > are no real 24bit add/subtracts needed. :o)
> >
> > -----------------------------------------------------
> > My code is specific to my app but here is the
> > psuedo code:
> >
> > initialising: (assuming 16MHz crystal, 4MHz clock)
> >         set TIMER0 to generate int every 256 clocks
> >         put 4,000,000 in 24 bit var
> >         add another 256 to var (inc mid byte)
> >
> > int handler:
> >         save off status/w
> >
> >         dec mid byte (subtract 256 from total value)
> >         check carry and dec msb if needed
> >                 (that was our entire 24bit subtract!)
> >
> >         now test for msb=0 AND mid=0 (detect <256)
> >         if not, goto int exit (very quick int in most cases!)
> >
> >         (here we have detected 1 sec event)
> >         generate 1 second event
> >
> >         (now we do the add 4,000,000 again)
> >         load msb value into msb (msb was guaranteed 0)
> >         load mid value into mid (mid was guaranteed 0)
> >         add lsb value to whatever is left in lsb
> >         if carry, inc mid
> >                 (that's our whole 24bit add done!)
> >
> >         int exit:
> >         restore status/w
> > -----------------------------------------------------
> >
> > There are a lot of good things about Bob's system.
> > Any crystal can be used, if it gives x instructions/sec.
> >
> > It will also work great for other timing periods,
> > like my datalogger that needs an event at 2Hz, 4Hz, 8Hz,
> > selectable. I just change the total value of ticks
> > added to the 24bit var. This can be done on the fly
> > with no problems.
> >
> > Quirky thing? With my 16MHz crystal, the clock is 4MHz.
> > So a one second period is 4,000,000 ticks. This just
> > happens to be 3D 09 00 in 24bit hex. Notice the lsb
> > is zero. This means that there will be NO ERROR on a
> > one second period. No jitter, as the only jitter with
> > this system is the lsb averaging. That was good luck,
> > I found it by accident! :o)
> >
> > The jitter is not a big problem as with most crystals
> > it will be a short term average. With a 8MHz crystal,
> > (2,000,000 ticks) one second will be 128 ticks late,
> > the next second will be perfect. A 2-cycle average
> > with zero average error. A 4MHz crystal gives 4-cycle
> > average with every 4th second perfect.
> >
> > Hope all this makes sense. Thanks Bob for the cool
> > idea!:o)
> > -Roman
> >
> > PS. If you just need to update a real time clock each
> > second and don't want to spend time in an interrupt
> > every 256 instructions, you could change the TIMER0
> > prescaler to 256. This gives an int every 256x256
> > instructions. Then just subtract one msb every int,
> > using the same principle. Just as quick. Remember
> > to add an extra 256x256 ticks at the start instead
> > of just an extra 256 ticks. Error per second (jitter)
> > is larger, but cumulative and average errors are still
> > zero. Max jitter per second becomes 16ms. Averaging
> > will take 24 seconds. An almost perfect real-time clock
> > with extremely low processing time requirement.
> >
> > --
> > http://www.piclist.com hint: PICList Posts must start with ONE topic:
> > [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
>
> --
> http://www.piclist.com hint: The list server can filter out subtopics
> (like ads or off topics) for you. See http://www.piclist.com/#topics
>
>

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.