On Thu, 28 Aug 1997 11:14:17 -0700 Ravindra Divekar writes: >has any of you come across an application, where you were using all >the internal/external interrupts in 16c84 (timer,RB0,PA4-7,eeprom) >and you ran out of stack(8 deep) because one interrupt occured before >the previous one was serviced , assuming that you could not >disable other interrupts, and the service routines were >quite complicated ? > Without special programming this does not happen, because the PIC hardware is designed to process only one interrupt at a time. When an interupt occurs, the GIE flag is automatically cleared, so another cannot happen. If, for example, an interrupt-causing transition on the INT pin occurs while the PIC is processing a TMR0 interrupt, nothing will happen except the INT flag will be set. The PIC will *not* push another address on the stack and go to address 4 because the GIE bit is clear. Usually the program uses the retfie instruction to return from interrupt, then reset the GIE flag (*after* the return address has been removed from the stack.) If another interrupt is pending, it will then be processed immediately. I don't think any instructions of the main program will be processed between the two interrupts, but I'm not sure of that. One can allow interrupts to be interrupted by setting GIE during the ISR (but after clearing the flag for the original interrupt). Besides using more stack, this method is not compatible with the usual practice of storing W and STATUS in dedicated RAM locations. So it should be used very cautiously, if at all. If it is necessary to recognize another interrupt during a lengthy ISR, it could also be done by polling the flag bit and calling another processing routine if necessary. Another oft-discussed topic about 16CXX interrupts is that the change of PORTB interrupt may be missed if the PIC is running. It should be used only to wakeup the device from sleep. There are rumors that new revisions of silicon and proper programming techniques can avoid this problem, but using the change of PORTB interrupt while the PIC is awake is definitely an advanced and uncertain practice that should be avoided if possible.