Sure, if the interrupt servicing is SHORT.
If long, like mine, then I want to get back to other stuff ASAP.

Now, say, your interrupt source gives lotsa interrupts in a short time.
You "may" never return to your main code.
I've seen this, before.  Really, though, what happens is your
main line code does not get enough time and you seem to lose
system response in the non interrupt code.

The true question is: how much interrupt introduced latency are you
wiiling to accept?

In a "well behaved" system, you may well go back and see if any
other interupts are pending, before the ISR releases control.
It, most likely, won't make any difference.

But, what if you have lotsa interrupts?  Say a couple of timers
(asynchronous of each other and not a harmonic,) serial comms,
SPI, external digital or discrete interupt sources.  Oh ya, and
you have another interrupt source.  This is a real world example,
BTW, running on a 17C756.  The second interrupt routine is Timer0.
In this setup, I simply give up control after the highest priority
interrupt is serviced.  I don't waste time looking for other
interrupts, I get in and out quick.  Quick is like 6 instuctions.
That's a context switch, if you need to view it like that.
"I" find this approach very KISS.   And hence very stable.
I do not want to accept the (random?) latency introduced
by all the different combinations.  Sure, you can compute
the maximum time if all ints happened, but that is almost
a poor example of the longest latency.  That's because, it
will never happen that all happen at the same time.  Am I
making sense?

Basically, I want the interrupts to not take too long and
allow the main code to execute frequently.  This sorta splits
the available time so that all get the service they need.
This seems to maintain good system response.

Hope this clears it up a bit.

-W
-----Original Message-----
From: M. Adam Davis [mailto:adavis@UBASICS.COM]
Sent: Monday, April 10, 2000 11:45 AM
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: Simultaneous Interrupts


I thought about that, but my understanding is that it would take longer to
do:

retfie
pop off stack, try to jump to last location
interrupt is seen
jump to interrupt handler.

if there are two interrupts pending, than it would take to simply jump back
to
the top if the global interupt flag is till set after clearing it?

-Ada,

"Quitt, Walter" wrote:
>
> So that interrupts don't take too long,
> I service the highest one first, clear the interrupt flag and iret.
> That way only 1 (one) service is performed per interrupt.
> This is done so time critical (timer) interrupts are not held off.
> Basically, I want to minimize the time spent in any interrupt event.
> Get in and get out as fast as you can.
>
> My technique works for me, your milage may vary,
> Walt...
>
> -----Original Message-----
> From: M. Adam Davis [mailto:adavis@UBASICS.COM]
> Sent: Monday, April 10, 2000 8:21 AM
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Re: Simultaneous Interrupts
>
> Each interrupt sets its own flag.  If the intcon, pir/pie, etc registers
are
> set
> right, then certian interrupts will set the global interrupt, which then
> branches to your interrupt routine.  It is not the peripheral which
> interrupted
> the processor, but the global interupt, which is triggered by another
> interrupt.
>
> This means that you can have every interrupt triggered on the PIC, or have
> them
> triggered while you are sevricing an interrupt, etc.
>
> This is why the global interupt is turned off when your interrupt routine
is
> called, we don't want an endless loop.
>
> You can handle interrupts a few ways:
>
> Let's say two interrupts are triggered at the same time.  The uC drops you
> into
> the interrupt routine.
>
> You check the interrupt flags according to a certian priority, and take
care
> of
> a process when you run into a flag.
>
> At this point you can do three things:
> Exit the interrupt routine, assuming only one flag was set
> Continue to check the remaining interrupt flags
> Jump (not call) to the beginning of the interrupt routine to start
checking
> for
> flags again, and only exit when all flags are clear (basicly looping
through
> the
> routine until no more interrupts are happening).
>
> If you exit the routine without checking other flags, and there are other
> flags
> set, your uC will be interrupted immediately after your RETFIE (which sets
> the
> global interrupt flag again).
>
> You will not lose an interrupt.
>
> -Adam
>
> Jim Dossey wrote:
> >
> > How are simultaneous interrupts handled in the 16C74A?  For example,
> > should I check all of the interrupt flags when I receive an interrupt,
> > or can I stop after finding the first flag that is set?  Can several
> > interrupt flags be set on 1 interrupt?
> >
> > If this is covered somewhere else, just point me in the right
> > direction.  I couldn't find a clear answer to this question in the PIC
> > manuals.
> >
> > Thanks,
> > Jim Dossey