On Thu, 13 Sep 2001, Olin Lathrop wrote:

> > int:
> >     movwf   _w
> >     incf    min,f   ;Increment minutes
>
> This irreversibly alters STATUS.  This will have the effect of randomly
> changing STATUS at random locations in the main code.  You need to save
> STATUS before changing it.  This is all well described in the manual - read
> it.  I also have an example interrupt service routine in HAL_INTR.ASPIC at
> http://www.embedinc.com/pic/hal.htm.


This was my first observation too. So to reiterater Olin and Joe (aka
Jinx), you need to preserve status and W upon entry into the ISR.

However, let me suggest a different way to approach this. It may be
convenient to place a chunk of code in an ISR, but often it's not the best
design choice. I can't really say for your particular case whether it's
appropriate or not. (The fact that you mention "PWM" suggests not.) My
inclination would be to put all of the processing outside of the interrupt
and just use the interrupt to record that something has occurred.

If all you're doing is monitoring 1-sec ticks on an I/O line (of PORTB)
then you can do this in the interrupt routine:


      org   4

      bsf   SOME_FLAG,bONE_SECOND_INT   ;record the event

      RETURN                            ;exit with interrupts disabled



and in the main code:


BIG_LOOP:


      ...


      btfss  SOME_FLAG,bONE_SECOND_INT ;Did we capture a one-second event?
       goto  next_task

      bcf    SOME_FLAG,bONE_SECOND_INT ;Maybe, but clear the flag anyways

      movf   PORTB,W                   ;Clear the pending interrupt

      BSF    INTCON,GIE                ;Re-enable the interrupt

      ; code to increment RTC registers...

next_task:
      ...


      goto    BIG_LOOP


Be very carful when writing code like this! There are several subtle
things happening. First, it's assumed that the current register bank is
is in view when the interrupt fires. If you're using the F84 or the F877,
then this isn't an issue. On the F877 make sure you place the variable
"SOME_FLAG" in one of the aliased registers. On the F84, all of the
registers are aliased. On the C64, etc, be very careful...

Another subtlety is that the status and W registers don't need saving
since they're not being modified.

Another subtlety is that the interrupt routine exits with interrupts
disabled! So care is taken in the main loop to disable the pending
interrupt and then re-enable interrupts. But be aware that the main loop
needs to run fast enough to ensure that an interrupt does not get missed.

Another tricky thing to do in the interrupt routine that would get around
this problem:

    org 4

    ;assume that we're looking for a rising edge on portb, pin SEC_EDGE

    btfsc    PORTB,bSEC_EDGE     ;Check i/o pin AND clear pending
                                 ;interrupt. This is tricky in that
                                 ;the portb interrupt on change is
                                 ;cleared by reading portb.
     bsf     flag, bONE_SEC      ;I/O line is high

    RETFIE                       ;re-enable ints upon exit


----

In the past I've needed to determine approximately how fast an RC
oscillator configured PIC was running. If there's another external time
base such as an RTC then you can count TMR0 rollovers between one second
events. If you enable TMR0 interrupts, you can count roll overs like so:

    org  4

    bcf      INTCON,T0IF   ;clear the interrupt

    incfsz   count_lo,f    ;count the times it occurred
     incfsz  count_hi,f
      retfie
    retfie

This code has several tricks. One is that the Z bit in the status register
is not modifed by the incfsz instruction (unlike the incf instruction). So
this can be safely placed in an interrupt routine without having to save
the STATUS register. Second, this trick uses Andy Warren's devious 16-bit
increment mtrick. I won't explain it now until someone makes the false
claim it can't work. As Olin would say, "Search the archives."

Incidently, in one application I need a variable frequency PWM. Rather
than varying the frequency in software, I varied the PIC's oscillation
frequency with an RC oscillator where part of the 'R' was a potentiometer.
The PWM duty cycle remained constant (or actually under software control
- which was desired), but the frequency was variable with a knob (which
was also desired). At the same time it was necessary to perform some
polling at a relatively constant rate. The poll rate was determined by
counting the number of TMR0 roll overs in a second. In a more recent,
application I ran into a different set of circumstances that required the
same solution. Can't say what thouse circumstances are, but this solution
worked for me!

Scott

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu