Frank Dalton wrote:

> I am using a PIC14000 chip and have a stupid newbie
> question.
>
> If two different interrupt conditions occur
> at the same time (say from a timer interrupt and a
> pulse on the OSC1 input pin) does one take priority
> over the other?
>
> A related question is what happens if while you are
> servicing one kind of interrupt another kind of
> interrupt event occurs?
>
> I suspect my questions are flawed in some way because
> there is no discussion of interrupt priority in the
> data sheets; however, I really need to know exactly
> what happens when two different kinds of interrupt
> events occur simultaneously or nearly simultaneously.
>

  Mmm Hmmm.... They don't go into great detail in the book on priority
because there is none.  The following comments refer to most every 14
bit word family.

When any interrupt occurs ( I assume it is clock synchronized, could be
wrong) INT occurs and vector is called.  It is imperitive to check on
each interrupt, and for each, check that the int is enabled and the flag
is set.  The hole in the concept is enabling an interrupt in INTCON and
not checking it in the INT routines.  The flag will remain set and never
cease interrupting.  Be certain to automatically reset the flag on any
and every interrupt that turns out to be enabled and flagged.  If two
interrupts happen simultaneously, either or cause the interrupt, and
they will simply be serviced in the order that you check them.  If one
occurs, and another occurs while you are tinkering your way through the
INT routine, you will service it if you haven't reached that piece of
check code yet.  If you have already checked that int, you won't
serviceit, but upon RETFIE, you will int right away.

Just a quick note.  Check the comments on saving the context, which are
absolutely critical.  There is no effort on the part of the PIC to save
the context (W, STATUS, FSR, PCLATH).  I have inherited code from others
that didn't do this.  Imagine that your mainline code is interrupted in
the middle of using W, and upon return, the data has mysteriously has
changed.  The mainline code doesn't know the difference.  Make sure that
you set aside some register files for the saved context data, the fist
one (W or STATUS I think) of which must cover both pages (if using a
processor with 2 pages, all four if using four).  If you study the
comments in the data book, the reasons for this will become clear.

I have formed a habit of starting each project with a piece of code that
checks all of the interrupts, even peripheral ones, and then comment out
the unused ones.  At least I don't have to re-invent or re-type and then
spend an hour finding that F in place of W.

Chris Eddy
Pioneer Microsystems, Inc.
Pittsburgh, PA
www.nb.net/~ceddy