>>> 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

Actually, I have developed several applications where nearly all the CPU 
time is consumed in an interrupt handler (up to 90%+). Typically the only 
interrupt enabled is a timer interrupt. This allows for short 'tasks' to be 
executed on a strictly scheduled basis, and, when done right, provides high 
assurance that appropriate real-time deadlines are being met.

In these programs the 'mainline' code usually contains nothing more than a 
command processor or simple state machine, which sets flags for the 
interrupt level code to handle.

-- Bob Ammerman
RAm Systems

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