{"id":2064,"date":"2018-07-12T15:18:15","date_gmt":"2018-07-12T15:18:15","guid":{"rendered":"https:\/\/deepbluembedded.com\/?p=2064"},"modified":"2023-08-17T23:53:23","modified_gmt":"2023-08-17T20:53:23","slug":"interrupts-in-pic-microcontrollers","status":"publish","type":"post","link":"https:\/\/deepbluembedded.com\/interrupts-in-pic-microcontrollers\/","title":{"rendered":"Interrupts In PIC Microcontrollers"},"content":{"rendered":"\n\n\n\n\n
\"Previous<\/a><\/td>\nPrevious Tutorial<\/strong><\/a><\/td>\nTutorial 7<\/span><\/strong><\/span><\/td>\nNext Tutorial<\/strong><\/a><\/td>\n\"Next<\/a><\/td>\n<\/tr>\n
<\/td>\nInterrupts in PIC Microcontrollers<\/strong><\/span><\/td>\n<\/td>\n<\/tr>\n
<\/td>\nPIC Microcontrollers Course Home Page <\/strong><\/span>????<\/a><\/td>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

In this tutorial, you’ll learn what are interrupts in PIC microcontrollers? How interrupt handling mechanism actually works? And how to respond (service) interrupt signals with C code in MPLAB XC8? You’ll learn all the fundamental mechanics of these processes. You’ll also understand the interrupt logic circuitry within our PIC16F microcontroller platform.<\/span><\/p>\n

This tutorial includes fundamental theoretical concepts which are substantial for any further investigations. The programming of almost all the upcoming modules involves handling interrupt signals. So it’s extremely\u00a0important to carefully read this tutorial. Understanding these concepts and mechanics demonstrated herein makes you way more aware of your system. And consequently, limits the probability of getting logical errors.<\/span><\/p>\n

And never forget, you can always ask any question you want whenever you want. I will read them all and will do my best to help you get everything right. Let’s get started!<\/span><\/p>\n

[toc]<\/p>\n

\n

\u00a0 \u00a0What Are Interrupts?\u00a0 \u00a0<\/span><\/strong><\/span><\/h3>\n

 <\/p>\n

Interrupts are basically internal\/external signals that suspend the main routine being done\/executed. While reading this article, your main routine is “Reading The Tutorial”. This main routine could be interrupted by many sudden events. If your phone suddenly started ringing during the “Reading” process, The main routine “Reading” will be suspended “Interrupted”.<\/span><\/p>\n

Handling the interrupt signal is mainly dependent on the interrupt source. It could be a phone ring, door bill, or whatever. Each interrupt of those can and will suspend the main routine “Reading”, and require a small portion of your time to handle this interruption. Then you can resume the main routine starting from where you left off.<\/span><\/p>\n

Using a small\u00a0bookmark will help you remember where you’ve been at the time of interruption! Which does in line with common sense. You just can’t start reading this article right from the beginning once again, only because you had a sudden phone call (interrupt)!<\/span><\/p>\n

The situation is similar for microcontrollers or computers in general. Any program being executed by a\u00a0computer could possibly get suspended by an interrupt signal at any instance of time. You should notice that a computer cannot use a bookmark to help it remember where it left off by the time of receiving the interrupt signal. That’s why there is a specific portion of memory dedicated to this function. Which we’ll discuss in more detail hereafter.<\/span><\/p>\n

 <\/p>\n

\n

\u00a0Why We Need Interrupts In Embedded Systems?\u00a0<\/span><\/strong><\/span><\/h3>\n

 <\/p>\n

Well, an embedded computer (e.g. MCU) is able to respond to any event in two different schemes. The first one is called Polling, <\/strong>which is obviously doing the main routine while checking for the event state from time to time. The second way is by using interrupts, which is obviously doing the main routine all the time until an event occurs which fires an interrupt signal which in turns suspends the main routine. Then the MCU will leave the main program to execute a specific pre-defined code (ISR Handler).<\/span><\/p>\n

Here is an example to make the difference much clearer. Consider the following main routine in which an MCU is blinking a LED once\/2-sec. Executing this loop takes around 2-seconds. Consequently, the MCU can Poll a push button connected to an input pin once\/2-second. Pressing this button should command the MCU to (e.g. do something..) which will not happen immediately on the button press event.<\/span><\/p>\n

On the other hand, an interrupt-driven system will immediately respond to the button press event which fires an interrupt signal that stops the current main routine even if it’s performing a delay macro.<\/span><\/p>\n

\u00a0 Polling\u00a0\u00a0<\/strong><\/span><\/h4>\n
while(1)\r\n{\r\n  LED = 1;\r\n  __delay_ms(1000);\r\n  LED = 0;\r\n  __delay_ms(1000);\r\n  if (Button == 1)\u00a0\u00a0\/\/ Polling the button's input pin !\r\n  {\r\n\u00a0   \/\/ Do Something...\u00a0 \r\n  }\r\n}<\/pre>\n
Completing the execution of 1-Round in this loop takes roughly 2-seconds of time. In which the MCU checks (polls) the button for a tiny little portion, roughly 1uS. If you’re lucky enough, the MCU will have finished the major 2 delays and will respond to your button press event. But the probability of this case is actually very low. One way to increase the probability of responding to your button press to be 100%, is to hold the button pressed for no less than 2-seconds!<\/span><\/p>\n
Which is not efficient in almost every situation. Down below is a simulation for the code shown above. Indicating how it’s more unlikely to have your MCU responding to your button press via Polling <\/strong>compared to the following case “Interrupt-Driven”.<\/span><\/p>\n
\u00a0 Interrupt-Driven\u00a0\u00a0<\/strong><\/span><\/h4>\n
On the other hand, for an interrupt-driven system the main loop will stay the same but with the polling if-statement removed. As shown below<\/span><\/p>\n
while(1)\r\n{\r\n  LED = 1;\r\n  __delay_ms(1000);\r\n  LED = 0;\r\n  __delay_ms(1000);\r\n}<\/pre>\n
Now, the button press event will be handled whenever the button is pressed. The MCU will leave off the main loop when an interrupt occurs and head over to the ISR handler which in this example will look like the code shown below<\/span><\/p>\n
void __interrupt() ISR(void)\r\n{\r\n  if (Button_Interrupt == 1)\r\n  {\r\n\u00a0   \/\/ Do Something...\u00a0\r\n  }\r\n}<\/pre>\n
The ISR handler will be immediately executed whenever an interrupt occurs. And the MCU will leave whatever it’s doing to respond to this interrupting event. <\/span><\/p>\n
Here is a simulation for the codes shown above. Indicating how it’s completely guaranteed to have your MCU responding to your button press immediately via Interrupts<\/strong>. And how low is the responsiveness of your system in case of using the POLLing<\/strong> method.<\/span><\/p>\n\n\n\n\n
\"Play<\/td>\n<\/tr>\n