Got it.  Thanks for all the replies and setting me straight.

Cheers,
-Neil.



On Tuesday 04 October 2005 02:55 pm, Byron A Jeff scribbled:
> On Tue, Oct 04, 2005 at 02:42:07PM -0500, PicDude wrote:
> > For clarification/completeness, I'm going to ask one more thing...
> >
> > Say a TMR0 interrupt occurs, and is being processed in the ISR.
>
> So GIE, TMR0IF, and TMR0IE are all set.
>
> >  During that
> > time say a TMR1 event occurs.
> >
> >  The TMR1IF flag gets set, but GIE is off.
>
> And TMR1IE is also set right?
>
> > Let's even go one step further and say a TMR2 event occurs as well before
> > the ISR Timer-0 code is complete, so the TMR2IF flag gets set.
>
> And again TMR2IE is also set.
>
> > We'll say that no more events occur after this.
>
> OK.
>
> > Now, upon exit of the ISR, GIE gets reset to it's enabled state.
>
> Yes.
>
> >As I
> > understand it, another interrupt will be generated, which I can then use
> > to check for the other interrupt flags.
>
> Under the presumption that the TMR1IE and TMR2IE are set, then yes.
>
> >  If say I process the appropriate
> > Timer-1 code, then exit the ISR again, would it generate another
> > interrupt for the pending TMR2 flag?
>
> Yes. An interrupt is generated whenever GIE, and both the IE and
> corresponding IF flags for a device are all set. And after an interrupt
> another will be generated as long as that's true.
>
> > Pretty-much, on each resetting of GIE to it's enabled state (via retfie),
> > does the PIC recognize that another event flag is set (TMR1IF, TMR2IF,
> > etc) with its corresponding enable flag (TMR1IE, TMR2IE, etc), and
> > generate an interrupt for it, or does it queue just one interrupt signal
> > if GIE is disabled?
>
> It's not a signal. It's a condition. An interrupt is generated whenever the
> condition that GIE along with the IE and corresponding IF are all set. It's
> a level triggered event. That's why entering the ISR autodisables the GIE.
> Otherwise you'd get an interrupt race condition where the ISR keeps getting
> interrupted. In fact an interrupt can be generated if GIE is reenabled in
> the ISR. A low priority interrupt may actually want to do this if it wishes
> for a higher priority interrupt to interrupt its interrupt service. However
> multiple levels of W/STATUS saving can get a bit dicey.
>
> >  This would of course affect how I handle each section in the ISR
> > -- whether I leave the ISR and let it come back for the other events due
> > to an interrupt, or if I need to have it sequentially run thru all
> > sections to process all possible interrupt sources in one call of the
> > ISR.
>
> Well there you go. It's possible to quickly AND the IF and IE flags to see
> if there are pending interrupts. You can use the result to decide whether
> to loop the ISR or not. It can save you the overhead of reloading and then
> resaving the W and STATUS registers at the beginning and end of the ISR.
>
> BAJ


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist