As the name implies, an Interrupt Service Routine will interrupt what a program is currently doing in order to execute the code within the routine. In the simplest of programs that behavior is generally harmless regardless of how an ISR is written, but as the size and scope of the program increases it becomes increasingly important to write efficient ISR’s in order to minimize the amount of time that typical program execution is being interrupted.

ISR’s are best used to quickly receive and store or fetch and send data, and/or reflect a change in state for the rest of the program. When receiving or sending data, the goal should be to process data from the hardware peripheral that triggers the ISR only and use flags or changes in state to inform the primary program application that data has been processed in order for the main program to control what is done with that data outside of the ISR.

On the topic of flags and best practices, when using global variables inside of an ISR to act as flag, counter, or any other variable that will be modified inside of the ISR, the global variable must be declared as a volatile variable. If the volatile keyword is not used, the compiler may determine the variable is not being used inside of an ISR and optimize it out of the ISR. This would prevent the variable from being modified when the ISR executes and the program will not run as intended. A missing volatile declaration for a global variable is one of the most common programming errors when using interrupts and should always be part of a code review checklist.

Key common mistakes that cause issues with ISR’s include: doing data crunching within an ISR, running loops in an ISR that prevent it from quickly exiting, or sending data with blocking commands such as UARTprintf where the ISR cannot exit until the data is transmitted properly. Each of these impede the ISR from quickly executing and cause latency that can impact system performance, and in each case, these should be handled within the main program execution instead.

If a system is experiencing unexpected behaviors and there is suspicion a slow ISR may be to blame, there is a simplistic method to measure the duration of ISR’s using an oscilloscope. Toggling a GPIO at the entry and exit of an ISR will allow for a measurement of how much time passes each time the ISR executes. If the ISR has multiple branches, additional GPIO can be added to help shed light on which branch is executing.