Embedded Priority Interrupts

           Most embedded systems use interrupts to reduce software overhead. The problem is, what happens if you have more than 1 event triggering interrupt? Should they trigger the same interrupt, or be treated individually? The answer is that interrupt signals should be treated on a priority basis, with the most important one first.
           This article will continue from the previous PIC Interrupts vs. Polling article and talk about how to design priority interrupt systems, how they run and how to build one. A circuit with the PIC 18F452 will be designed/built in order to demonstrate embedded priority interrupts.

Embedded Priority Interrupts - Demonstration

PIC Priority Interrupts - Setup

Purpose & Overview of this project
           The main purpose of this article is to build a two-tier event driven system. The two events will be interrupts on the PIC's PORTB interrupt-on-change, the same as was used in the previous Interrupts vs Polling article. This time, one interrupt will have a high priority and the second a low priority. Each interrupt will have an associated interrupt service routine that identifies itsself via an LED bar when triggered. The main program loop will consist of a single LED floating back and forth like 'knightrider'.
           Two push buttons will be used to generate the interrupt-on-change going into PORTB of the PIC on pins RB0 and RB1. RB0 will be set to high priority interrupt and RB1 to low priority. The end goal of this system is to show how a high priority interrupt has the capability to over-ride a low-priority interrupt as well as the main program loop.