Jinx wrote:
>> 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
>
>   
Ahhh...some very interesting points you have made! I will keep them in 
mind as my work progresses from basic obstacle avoidance to more 
sophisticated behaviour.
Thanks again!

-- 
Regards,
Stephen D. Barnes

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