This is all very complex. That is why I liked my scheme of not nesting
interrupts, but rather periodically polling for and handling the
high-priority interrupt in the code that handles the low priority
interrupt(s). This allows a single state save area to get the job done. You
just have to be sure that you only poll for the high priority routine in
places where no important state exists (ie: not between setting the Z bit
and testing it, for example)

The high priority handler is written as a subroutine that does a normal
RETURN, and you can scatter:

    btfsc    HIGHPRIFLAG
    call      highprihandler


(or the "C" equivalent) throughout your interrupt handler code.

If code space is at a premium and cycles aren't you could just insert:

    call    highpricheck

which would call:

highpricheck:
    btfss    HIGHPRIFLAG
    return
    ...handle the interrupt...
    bcf       HIGHPRIFLAG
    return

Bob Ammerman
RAm Systems



----- Original Message -----
From: "Olin Lathrop" <olin_piclist@EMBEDINC.COM>
To: <PICLIST@MITVMA.MIT.EDU>
Sent: Thursday, March 07, 2002 6:39 AM
Subject: Re: [PIC]: Multi-level interrupts and the PIC16F628


> > interrupt:
> >     save STATUS to primary save area
> >     save PCLATH to primary save area
> >     set PCLATH to zero
> >     is it the high priority interrupt ?
> >       YES:
> >         save additional stuff, like FSR perhaps to primary area
> >         handle the interrupt
> >         restore state from primary save area
> >         RETFIE
> >       NO:
> >         move saved STATUS, PCLATH to secondary save area
> >         save additional stuff, like FSR perhaps to secondary area
> >         determine which interrupt it is and jump to handler routine
> >       END
> >
> > Each low priority interrupt handler routine:
> >     clear the interrupt condition
> >     re-enble interrupts
> >     handle the interrupt
> >     goto restore_low_priority_interrupt
> >
> > restore_low_priority_interrupt:
> >     restore additional stuff like FSR from secondary save area
> >     restore PCLATH and STATUS from secondary save area
> >     RETURN
>
> I just read my earlier response and realized that this is wrong.  You do
> need a separate save area for each low priority interrupt, since a low
> priority interrupt could be interrupted by another low priority interrupt
in
> this scheme.
>
>
> ********************************************************************
> Olin Lathrop, embedded systems consultant in Littleton Massachusetts
> (978) 742-9014, olin@embedinc.com, http://www.embedinc.com
>
> --
> http://www.piclist.com hint: To leave the PICList
> mailto:piclist-unsubscribe-request@mitvma.mit.edu
>
>

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