'PIC, check thyself'
Subject: Time: 2:25
PIC, check thyself
Here is a subroutine to delay x milliseconds (4Mhz crystal, thanks
; call with # ms in W
ms_dly movlw .199
decfsz temp, f
decfsz temp1, f
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:
bsf INTCON, GIE
bcf INTCON, GIE
Overflows of TMR0 would be caught by an interrupt service routine which
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 Ockers <anl.gov> wrote: ockers
That's correct; the routine delays 1000W + 4 cycles, including
CALL and RETURN overhead.
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
Of course, you'll have to subtract a little from your 16-bit
timer to compensate for the time spent copying TMR0 to the
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
=== Andrew Warren - ix.netcom.comfastfwd
=== Fast Forward Engineering - Vista, California
=== The reports of my demise have been greatly exaggerated.
More... (looser matching)
- Last day of these posts
- In 2000
, 2001 only
- New search...