Re: [PIC]: Interrupts in a PIC16F84 by Bob Ammerman .

----- Original Message ----- From: "Tony Nixon" <@spam@Tony.Nixonspam_OUTspamENG.MONASH.EDU.AU> To: <PICLISTEraseMEspam_OUTMITVMA.MIT.EDU> Sent: Thursday, April 26, 2001 2:22 AM Subject: Re: [PIC]: Interrupts in a PIC16F84 {Quote hidden}> "Andrei B." wrote: > > > Sometime during the ISR (after checking cause), RB0/INT signals an > > interrupt. What happens next ? > > (I expect in my application to have at most 2 interrupt signals on) > > If GIE is clear nothing, until you exit the interrupt with RETFIE and > then the interrupt will trigger again because of RB0INT. > > > Questions: > > 1) should I disable GIE in ISR or leave it on? > > Depends on what you need to happen. Sorry, no. The GIE is automatically disabled on entry to the ISR and reenabled by the RETFIE instruction. Now, to qualify this a bit: The PIC will automatically disable GIE during the interrupt handler and reenable it during the RETFIE. It _is_ possible to deliberately reenable interrupts in your interrupt handler but this is pretty ugly (you have to have multiple save areas and decide which one applies to a given invocation of the interrupt). Here is pseudocode for a is a reasonable way to go at it if you are expecting a lot of interrupts. This avoids repeatedly handling interrupts and saving/restoring context: interrupt_handler: save context check_next: if RB0/INT interrupt clear RB0/INT flag handle RB0/INT condition goto check_next endif if TMR interrupt clear TMR interrupt flag handle TMR condition goto check_next endif restore context RETFIE Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) -- http://www.piclist.com hint: To leave the PICList @spam@piclist-unsubscribe-requestEraseMEmitvma.mit.edu