If you really want A and B to be interrupt driven then a scheme like this can work: inthand: ...savestate... btfsc INTAFLAG ; is A trying to run? call int_a_hand ; yes: run it btfss INTBFLAG ; is B trying to run? goto int_exit ....start handling B.... btfsc INTAFLAG ; is A trying to run? call int_a_hand ; yes: run it ...continue handling B... btfsc INTAFLAG ; is A trying to run? call int_a_hand ; yes: run it ...etc... bcf INTBFLAG ; done processing int B int_exit: ...restore state... retfie int_a_hand: ...process interrupt a... bcf INTAFLAG return -- Scatter enough checks on INTAFLAG to ensure the required latency. -- Make sure the int_a_hand routine doesn't trash any state required by the in-progress B handler Bob Ammerman RAm Systems ----- Original Message ----- From: "Craig Anderson" To: Sent: Tuesday, March 05, 2002 4:16 PM Subject: [PIC]: Multi-level interrupts and the PIC16F628 > Hi. > I'm designing an application in which i would really like to have two interrupt > sources. One of the interrupts is highly time critical (A) and the other (B) is not. > It will be running on a 16f628. Interrupts A and B will occur at regular, > but effectively random intervals. > > While servicing the interrupt for B i need to be able to process an interrupt for > A and then return back to where i was in the interrupt service routine for B. > > Is this practical? or should i redesign the application to avoid having to do this? > If it's ok, then how do i deal with context saving? > > -Craig > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. > > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.