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