> Note that this allows for (something like) priority in interrupt
> handling, even in 12- and 14-bit core chips.  Multiple simultaneous
> interrupts will be serviced in the order they are checked.  Any
> interrupt NOT serviced will cause an immediate return to the interrupt
> vector upon RETFIE.  This doesn't mean that a lower priority interrupt
> can be interrupted by a higher priority interrupt, just that more time
> critical ones can be allowed to finish their business before less time
> critical ones.

I am not sure this is a good idea. It will reduce the *average*
interrupt latency for the higher priority serivice code, but it might
not reduce the *worst case* latency. This will make latency-related
problems harder to reproduce. As a user, I (grudgingly) prefer a program
that misbehaves only once an day. As a tester I much prefer a program
that misbehaves each second!

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
 

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