An Overview Of The Embedded Priority Interrupts
The two priority interrupts used here were triggered by push buttons and represented a very simple type design for an event driven system. The microcontroller had a main state that cycled forever and unique routines for each interrupt, both Low and High Priority. It was demonstrated that the high priority code could not be interrupted and over-ruled all other possible inputs and the low-priority interrupt came in 2nd on the importance scale. The main program loop is always the lowest priority for a system like this.
What To Do Now
The reason for needing priority interrupts might not be initially clear: but if you think about a car, for example, if I press both the brake and the accelerator at the same time, which pedal do you think should have priority? Probably the brake. With the knowledge offered to you in this tutorial you can now move onto using the many different types of peripheral devices and their interrupts in the PIC with different priority levels. Try using the timers, Serial communication or Capture and Compare module interrupts and see how the priority interrupts operate with one other. The end result is usually a system that runs so fast you can't even tell there are multiple processes occuring inside.
Conclusion
While perhaps not the most exciting article, embedded priority interrupts offer us, as designers, the ability to control multiple processes and build event driven systems which clear a lot of software overhead in timing-critical devices. In any case, this article offered a simple example design that can be duplicated with very little cost and modified for many different types of interrupts available in the PIC. With that said, I believe I was successful in reaching purpose and goals set forth for this article.
If you have any further questions, I implore you...don't be shy, take a look at the forums or ask a question there. I check them out regularly and love getting comments & questions.
The two priority interrupts used here were triggered by push buttons and represented a very simple type design for an event driven system. The microcontroller had a main state that cycled forever and unique routines for each interrupt, both Low and High Priority. It was demonstrated that the high priority code could not be interrupted and over-ruled all other possible inputs and the low-priority interrupt came in 2nd on the importance scale. The main program loop is always the lowest priority for a system like this.
What To Do Now
The reason for needing priority interrupts might not be initially clear: but if you think about a car, for example, if I press both the brake and the accelerator at the same time, which pedal do you think should have priority? Probably the brake. With the knowledge offered to you in this tutorial you can now move onto using the many different types of peripheral devices and their interrupts in the PIC with different priority levels. Try using the timers, Serial communication or Capture and Compare module interrupts and see how the priority interrupts operate with one other. The end result is usually a system that runs so fast you can't even tell there are multiple processes occuring inside.
Conclusion
While perhaps not the most exciting article, embedded priority interrupts offer us, as designers, the ability to control multiple processes and build event driven systems which clear a lot of software overhead in timing-critical devices. In any case, this article offered a simple example design that can be duplicated with very little cost and modified for many different types of interrupts available in the PIC. With that said, I believe I was successful in reaching purpose and goals set forth for this article.
If you have any further questions, I implore you...don't be shy, take a look at the forums or ask a question there. I check them out regularly and love getting comments & questions.