I don’t think you’ve grasped what interrupts are Mike.

Firstly, in a PIC they’re all generated by Hardware. Be it interrupt on change on a PIC pin, a Timer Overflow, a byte arriving at the USART, whatever. That Hardware Interrupt has THEN got to be serviced by your Software Program.

Secondly, the program in the PIC can only do one thing at a time. Whilst Hardware events are happening all around, the software can only attend to one thing. If your going to service an interrupt event, then, because individual PIC’s don’t parallel process yet, you must by the very nature “interrupt” what you’re doing a go do something else. That’s why some no-brainer named this an “Interrupt”.

If your software is say in the middle of your Sound command, and a Hardware event occurs which would trigger an interrupt, then this can be handled in one of only THREE ways.

1. No Interrupt. Interrupts are NOT enabled, however the Hardware event still sets the event Flag. Once you complete what you’re doing (say your Sound command), you go check what Flag has been set (if any) and do your thing appropriately. In this option, the Sound command completes happily before you check you Flags status.

2. PBP Interrupt. The Hardware event happens, but PBP ignores it until it completes the current command (eg PBP will wait until your Sound command finishes what it’s doing), only then it will jump into your Interrupt Service Routine. You’ll note that here as in option 1 above, the Sound command will be unaffected and will complete without interruption.

3. Assembler Interrupt. This now replaces the way that PBP would handle an Interrupt event. As soon as the interrupt occurs, it will be serviced, therefore execution of what you’re currently doing (eg the Sound command) will be broken whilst the Interrupt Service Routine (ISR) executes. In this instance the Sound command will be broken for the duration of the ISR.

I can see what you want. You want instant access to a Hardware event, without affecting what you’re currently doing. You can only do that by compromising you’re requirement against one of the three options I’ve outlined. If you’re application absolutely depends, life or death, on being able to complete the Sound command for example, but you MUST attend to the Hardware event, then Option 3, but (and it’s a big BUT), your ISR must not be longer than a few instructions (which might be very hard to achieve), otherwise you’ll notice ‘clicks’ and breaks in the Sound output as the ISR executes. The only other way is to synchronise your ISR execution to the output of the Sound command, ensuring your ISR completes before the next High/Low sound transition. For that you will need to write your own Sound command.

It might be simpler here to have a dedicated baby PIC for your uninterrupted sounds, and a second one attending to your Hardware events. There you go - parallel processing…