> Thanks for the enlightenment!

You're most welcome

One other thing to bear in mind is that you don't HAVE to
respond immediately to an interrupt. In several of my projects
it's enough for the source's IF to be set by an event and polled
when convenient. You might have a non-urgent event on the
INT0 pin and you want to know ASAP that it happened but
you don't need to know right now. So you don't set its IE,
which keeps it out of the h/w IRQ system, and check its IF
as and when

There could be two events you want to keep track of. Perhaps
a 100ms timer tick and a switch closing. Either of those may be
more important than the other, so you'd put one on IRQ, the
other can be polled. Or both could be polled. Is it important that
the switch closure be detected and acted on immediately to
trigger another event ? Is the 100ms vital for another process ?

A trivia point - you might exit an ISR with RETURN instead of
RETFIE. This disables the interrupt system by not setting GIE,
maybe you want to detect a one-off. You can manipulate GIE
manually of course

> Most ISR info I see says to keep it as short as possible

They usually do say that, but really it depends on the s/w as
a whole, what task priorities you set, what the ISR has to do,
what else is going, etc etc. There's no compelling reason to
make an ISR any particular length per se

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist