'PIC check thyself'
Subject: Time: 3:06
RE: PIC check thyself
In reply to Andrew Warren:
Thanks so much for responding to my posting. Your response made
me think, (which I should have done in the fist place). After many
things began to dawn on me. I'm responding through the list because
faulty thinking will help someone else.
First, it never occurred to me to put a clrf TMR0 inside the isr. I was
to just clear it once and let it run. The overflows would be collected
as the value of TMR0 just after the call to the delay routine finished.
I figured all this would happen in the background and not affect the
the delay. Of course the isr is going the affect the delay timing! Isr
instructions take time just like delay routine instructions do.
I still don't see the necessity of having a clrf TMR0 inside the isr.
timer is locked in step with the isr anyway, so the occurance of a TMR0
while the isr is active won't take place unless the isr routine takes
My isr routine is rather short:
movwf w_temp ; save W
swapf STATUS,W ; save status
movwf status_temp ; without changing flags
incf overflo, f
swapf status_temp,W ; get original status back
movwf STATUS ; into status register
swapf w_temp,f ; old no flags trick again
swapf w_temp,W ; to restore W
bcf INTCON,T0IF ; clear the TMR0 interrupt flag
At first thought I could get away without saving STATUS and W but then
decided that Z is affected, (even though probably never set), so I had
save STATUS. Then in saving STATUS W was changed. Drats!
The main part of my routine runs:
bsf INTCON, GIE
movf binbr, W
movf TMR0, W
bcf INTCON, GIE
As to your particular points:
bcf INTCON, GIE
btfsc INTCON, GIE
goto $ -2
Is there some reason to doubt that the 1st instruction will be carried
You seem to be even less of a trusting soul than I am.
2. The register pair will accumulate any time spent anywhere
performed unless you modify that by resetting TMR0. A clrf TMR0 in the
essentially subtracts out the instruction time between the time of
and when the clrf TMR0 instruction takes place, (plus a couple for the
latency). 6 of one, half a dozen of the other. Either way you have to
for instructions other than those in the delay routine.
3. I plan to run with W=1 but I don't KNOW that the routine takes 1004
Just because I said it or you said it or even if MPLAB says it, that
make it true. That whole idea of the process is to demonstrate that it
is true. What if we are all wrong? Really, I just want to see if I can
4. Good idea to test with code other than the delay routine.
I have tested my code with W values 1 - 7. here are the results:
W overflo timecnt 256*overflo+timecnt
1 5 44 1324
2 9 71 2375
3 13 97 3425
4 17 124 4476
5 21 151 5527
6 25 177 6577
7 29 204 7628
There seems to be a pretty consistant difference between the values of
1050 or 1051 usec. I don't understand why the first number is not
1050 however. I think the display and number choosing portions of the
are working else the values wouldn't have come out as regular as they
have. The only thing left are the two sections of code given above.
I also don't see how you can get the numbers 1004, 2004, 3004 out of
numbers. Maybe I need to look at some larger values.
I guess the main lesson I've learned so far is that if you have delay
routines based on instruction length timing and isr routines running at
the same time, don't expect the delays to be accurate.
More... (looser matching)
- Last day of these posts
- In 2000
, 2001 only
- New search...