Searching \ for 'PIC, check thyself' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'PIC, check thyself'.

Truncated match.
PICList Thread
'PIC, check thyself'
2000\01\27@160144 by Stan Ockers

flavicon
face
                           Subject:                        Time:    2:25
PM
                           PIC, check thyself
1/27/00
                                                            Date:
Here is a subroutine to delay x milliseconds (4Mhz crystal, thanks
Alice):

                         ; call with # ms in W
delay_xms
           movwf temp1
ms_dly      movlw .199
           movwf temp
dly_lp      clrwdt
           nop
           decfsz temp, f
           goto dly_lp
           nop
           decfsz temp1, f
           goto ms_dly
           return

By my count it is 4 microseconds too long.  1 msec is actually 1004 usec,
2 is 2004,
3 is 3004 etc.  The 4 usec is basically the call and return time.  I
would like to check this.

I thought the PIC might be used to check itself.  I would try to have the
PIC count microseconds
using TMR0.  GIE would be set and cleared before after the call to
delay_xms.  The closure of a
switch would start the following:

               clrf TMR0
               movlw #
               bsf INTCON, GIE
               call delay_xms
               bcf INTCON, GIE

Overflows of TMR0 would be caught by an interrupt service routine which
increments the
register overflo and clears T0IF.

the PIC would then enter a loop which sucessively displays TMR0 and
overflow on 8 leds
connected to port B.

Does this seem reasonable?  Are there any gotcha's I have to look out
for?  There are 2
instructions between the clrf TMR0 and the call.  Does this take care of
the 2 cycle latency
after loading TMR0?

Any help would be appreciated.

Stan

2000\01\27@224143 by Andrew Warren

face
flavicon
face
Stan Ockers <spam_OUTockersTakeThisOuTspamanl.gov> wrote:

{Quote hidden}

   Stan:

   That's correct; the routine delays 1000W + 4 cycles, including
   CALL and RETURN overhead.
{Quote hidden}

   A few ideas:

       1.  The "BCF INTCON,GIE" will stop the interrupts and keep
       the "OVERFLO" register from being incremented any further
       (especially if you follow it with a "BTFSC INTCON,GIE / GOTO
       $-2"), but TMR0 will continue to increment regardless of the
       GIE state... So you'll need to store the contents of TMR0 in
       another register and display THAT, instead of displaying TMR0
       directly.

       Of course, you'll have to subtract a little from your 16-bit
       timer to compensate for the time spent copying TMR0 to the
       other register.

       2.  Your OVERFLO:TMR0 register-pair will accumulate any time
       that's spent in the interrupt routine between the "CLRF
       TMR0" and the RETFIE, so the "CLRF TMR0" should be placed
       IMMEDIATELY before the RETFIE.

       3.  You'll have to subtract some fixed number of counts from
       your OVERFLO:TMR0 counter in order to compensate for time
       spent copying TMR0 to another register, etc.  Rather than
       trying to figure out what that constant number of cycles is
       by staring at the code, just run the thing with W=1 and look
       at what's displayed.

       Since you KNOW that the delay_xms routine takes 1004 cycles,
       the difference between the displayed value and 1004 is the
       number of cycles that you'll have to subtract from your
       16-bit cycle-counter before displaying it.

       4.  To test the reliability of your timing method, try
       setting up known delays of 250,251,252,....259,260,261 cycles
       and making sure that they're displayed properly.

       To ensure that the delays are actually as long as you think
       they are, construct them very simply... The easiest way would
       be to place 125 to 130 "GOTO $+1" instructions -- followed
       optionally by a "NOP" -- between the "BSF INTCON,GIE" and
       "BCF INTCON,GIE" instructions.

   Of course, if your only reason for writing this code is to check
   delay routines quickly and easily, you're wasting your time...
   Doing it by hand or with the MPLAB simulator would be MUCH more
   efficient.

   -Andy


=== Andrew Warren - .....fastfwdKILLspamspam@spam@ix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499
===
=== The reports of my demise have been greatly exaggerated.

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...