>
> Jeethu, there is a method ( Steinhart ? method ) for no errors timing
> generation. A wile ago, Roman Black promised an example with this method
> on his site, maibe it was just a promise... I don't know.
> Here is the story of that method posted by Roman :
> (I hope will help you )
>
> 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.
>
> On Thu, 21 Jun 2001, Jeethu Rao wrote:
>
> > Hi,
> >
> > Although I've been using PICs for a while now, I'm not feeling good while
> > using TMR0 overflow interrupt.I've given a formula below which I have
> > derieved and I think it's correct. can someone tell me if there is any error
> > in it? The formula is for obtaining the frequency at which TMR0 interrupt is
> > called.
> >
> > (Fosc /4)
> > Fout= __________________________
> > (256-TMR0Val) * Prescaler
> >
> > Fout :- The frequency of TMR0 Calls
> > Fosc :- The External Clock frequency of the PIC
> > TMR0val :- The value which will be loaded into TMR0 reg on Overflow
> > Prescaler :- The Prescaler Value
> >
> > THe first noticable problem is that there is no compensation given for the
> > loss of prescaler counts when TMR0 Reg is reloaded with a new value. Does
> > anyone have a better formula ?
> >
> > Thanking You,
> >
> > Jeethu Rao
> >
http://www.jeethurao.com
embedinc.com, http://www.embedinc.com
