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:

I have a clock of 20MHz that meens 50nsec

then I have three instructions for each function so what i did is

50nsec X 3inst X (how many time to be multiplied (n))= 1msec

so,

n = (1m X 20MHz) / 3inst = 6666.66666

then,

I devided that number by 100 to split it into two equations, so I got 67 and 100.

the following is my iomplemented function, however, i am not getting the right delay. I am geting larger delay

Wait1ms movlw .67 movwf temp11Wait1msB1 movlw .100 movwf temp12Wait1msB2 decfsz temp12,1 ; this is one instruction goto Wait1msB2 ; this is two instructions which make 3 total decfsz temp11,1 ; the same here goto Wait1msB1 return

can any body help

Thank you

regards,

Paul

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
--
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

Paul 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:
>
>I have a clock of 20MHz that meens 50nsec

>then I have three instructions for each function so what i did is
>50nsec X 3inst X (how many time to be multiplied (n))= 1msec
>so,
>n = (1m X 20MHz) / 3inst = 6666.66666
>then,
>I devided that number by 100 to split it into two equations, so I got 67
>and 100.
>
>the following is my iomplemented function, however, i am not getting the
>right delay. I am geting larger delay
>
>
>
>Wait1ms
> movlw .67
> movwf temp11
>Wait1msB1
> movlw .100
> movwf temp12
>Wait1msB2
> decfsz temp12,1 ; this is one instruction
> goto Wait1msB2 ; this is two instructions which make 3 total
> decfsz temp11,1 ; the same here
> goto Wait1msB1
> return

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

The problem is: it takes 4 cycles of the 20MHz clock for each instruction
(and 8 for branches and skips 'taken'). So your results are off by a factor
of 3. (note: I didn't actually verify your code, just your comments).

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

> I have a clock of 20MHz that meens 50nsec
> then I have three instructions for each function so what i did is
> 50nsec X 3inst X (how many time to be multiplied (n))= 1msec
> so,
> n = (1m X 20MHz) / 3inst = 6666.66666
> then,
> I devided that number by 100 to split it into two equations, so I got 67
and 100.
>
> the following is my iomplemented function, however, i am not getting the
right delay. I am geting larger delay{Quote hidden}

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

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

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

Vasile Surducan wrote:
>
> 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
>

Hi Vasile, sorry I don't really understand what
you are asking!

I initialsed TMR0 with no prescaler, so it clocks
at 1:1 with the clock speed (fosc/4).
With 16MHz crystal gives 4MHz clock speed.
Then TMR0 generates an int every 256 instructions.

This simply subtracts 256 "ticks" from the main
24bit variable. When the variable gets below 0
we just add another 4,000,000 ticks (1 second) to
it and it keeps going. My system of testing <256
is better than <0 because it speeds the math.
:o)
-Roman