At 06:21 AM 3/16/2012, Byron Jeff wrote: >Your example of wanting to disable the interrupt so that the main=20 >loop can finish is a perfect counterexample to why one is needed.=20 >The main loop is the priority over the ADC. So the ADC should not be=20 >in an interrupt. Exactly right! Most of my code is written such that things like timer events are=20 handled by polling flags in either my foreground or background tasks=20 (depends on the project). I keep interrupts for critical things like=20 serial comms, over-current shutdown, PWM, etc. By my definition: an interrupt should start and finish in not more=20 than a dozen or two cycles. If an interrupt takes hundreds or=20 thousands of cycles, it probably shouldn't be an interrupt. As always, there are exceptions. (*) dwayne (*) Just for giggles and laughs - I once did a project where=20 EVERYTHING was done in the interrupt service routines. The=20 foreground task was a forever loop with nothing inside. As a result,=20 I could dispense with saving and restoring context in the ISR's,=20 which made them REALLY quick. Did it just to see if I could. And - Yeah - it worked=20 perfectly. But it WAS a simple project. dwayne --=20 Dwayne Reid Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax www.trinity-electronics.com Custom Electronics Design and Manufacturing --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .