Mike Hord wrote:
> So what's the solution?  The intuitive method for dealing with
> multiple interrupts is to check the most important interrupt first,
> deal with it, check another, deal with it, check another, etc. until
> all interrupts have been serviced, the RETFIE.  If we only check one
> interrupt, then RETFIE, the possibility exists that if that interrupt
> recurs before the RETFIE, it could block all other interrupts from
> being serviced.  Another possibility is checking different interrupts
> at different places within the ISR; I'm not sure I like that.  So
> what's your candidate for best solution, Wouter?

I'm not Wouter, but I check interrupt conditions in priority order, handle
the first one I find, then get out as quickly as possible.  If there are
multiple interrupt conditions, then a new interrupt will be taken
immediately after RETFIE.  This takes the least number of cycles to handle
the most important interrupt.  Most of the time, interrupts do not overlap
anyway, so the extra cycles that optimize for that case usually pessimize
the overall system.  If your highest priority interrupt occurs so frequently
that you have another interrupt immediately after finishing the previous,
you're processor is overloaded and you've got other problems anyway.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist