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:
Search entire site for: 'PIC check thyself'.

Truncated match.
PICList Thread
'PIC check thyself'
2000\01\28@160956 by Stan Ockers

                           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
maybe my
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 well
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
length of
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
over 256
usec.  True?

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:
              clrf overflo
              clrf TMR0
              bsf INTCON, GIE
              movf binbr, W
              call delay_xms
              movf TMR0, W
              movwf timecnt
              bcf INTCON, GIE
              call display

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
instructions are
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
do it.

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
- Today
- New search...