Designer’sDesigner’s Minimizing Interrupt Response Time By: David Kleidermacher, Vice President, ISR return instruction will reenable interrupts automati- CornerCorner Engineering, Green Hills Software, Inc. cally. By keeping ISRs short and simple, developers will avoid the common pitfall of leaving interrupts disabled THERE ARE MANY ASPECTS OF When an interrupt fires, the microprocessor executes for too long, thereby increasing the latency of higher an interrupt service routine (ISR) that has been installed priority interrupts. In addition, ISRs are notoriously diffi- OPERATING SYSTEMS, SUCH AS to service the interrupt. The amount of time that elaps- cult to debug and often must be analyzed by inspection CONTEXT-SWITCH TIME, SERVICE es between a device interrupt request and the first – practical only for simple implementations. Keeping instruction of the corresponding ISR is known as inter- ISRs short will minimize interrupt response time, testing CALL PERFORMANCE, SCHEDULING rupt latency. The interrupt handling code can optionally and debugging time, and your frustration level. ALGORITHMS, BUSINESS MODEL, TOOLS execute an operating system API that will cause a thread to be awakened. The amount of time that elaps- 2. Do Not Disable Interrupts AND MIDDLEWARE INTEGRATIONS, THAT es between the interrupt request and the first instruc- Operating system architecture is often the most signif- EMBEDDED SYSTEMS DEVELOPERS tion of the thread awakened to handle it is known as icant factor for determining response times in an thread response time. ISRs are usually written at least embedded system. A major contributor to increased SHOULD BE CONCERNED ABOUT; partially in assembly language and typically have limit- interrupt latency is the number and length of regions in HOWEVER, THE MOST IMPORTANT ed resources. Code executing in a thread is written in a which the kernel disables interrupts. By disabling inter- high level language such as C, has full access to the rupts, the kernel may delay the handling of high priori- CHARACTERISTIC – WHAT MAKES AN operating system API, and is easier to debug, analyze, ty interrupt requests that arrive in those windows in OPERATING SYSTEM A REAL-TIME and profile. This article will address the ability to guar- which interrupts are disabled. Most operating systems antee both a minimal interrupt latency and thread OPERATING SYSTEM – IS ITS ABILITY employ what we call a Simple architecture: whenever response time. the operating system wants to prevent preemption TO SERVICE INTERRUPTS QUICKLY. within a critical section of its code, the operating sys- In order to compute the system’s worst case response A FAILURE TO MEET A RESPONSE TIME tem simply disables interrupts for the duration of the time, it is necessary to examine all of the sources of critical section. Most RTOSes employ this Simple archi- REQUIREMENT IN A REAL-TIME SYSTEM interrupt response delays to ascertain which source tecture since it is easy to implement and the common- causes the longest delay to the servicing of the highest CAN BE CATASTROPHIC. IN ADDITION, ly used and understood mechanism (this is what we priority interrupt. Possibilities include: learn in university operating systems class). OPERATING SYSTEM VENDORS USUALLY • Longest hardware-induced latency • Longest software-induced (e.g. by the kernel) PUBLISH BEST CASE, AVERAGE CASE, By disabling interrupts, the Simple RTOS is in effect interrupt disabling region sacrificing the latency of the highest priority interrupt to OR WORST CASE RESPONSE TIMES IN • Longest disabling region caused by the ISR of a lower avoid problems caused by handling of lower priority priority interrupt A PARTICULAR TEST ENVIRONMENT. interrupts. A better solution, implemented in the Advanced architecture, is to never disable interrupts in BUT THIS IS MERELY MARKETING HYPE; The theoretical worst-case delay may depend on the kernel service calls. By never disabling interrupts, not choice of CPU, choice of operating system, and how WHAT REALLY COUNTS IS THE TRUE, only does the Advanced RTOS guarantee the minimum device drivers and other software are written. possible latency for the highest priority interrupt, but GUARANTEED WORST-CASE TIME. also the absolute worst case latency can be trivially THIS ARTICLE WILL DESCRIBE HOW Minimum Interrupt Response Time: proven (no need to examine all of those disabling 5 Simple Rules sequences in the kernel). A MINIMAL YET GUARANTEED WORST- Sound programming techniques coupled with proper CASE INTERRUPT RESPONSE TIME RTOS interrupt architecture can ensure the minimal All other things equal, an RTOS that does not disable response time. The recipe: interrupts in service calls will achieve better response CAN BE ACHIEVED IN ANY TYPE OF 1. Keep ISRs simple and short. times than an RTOS that does disable interrupts. This is ELECTRONIC PRODUCT, FROM SIMPLE 2. Do not disable interrupts. common sense: if a high priority interrupt arrives while 3. Avoid instructions that increase latency. executing within a Simple RTOS’s critical section, the CONTROL APPLICATIONS TO THE 4. Avoid improper use of operating system API latency for the high priority interrupt will be increased MOST COMPLEX, MULTI-PROCESS, calls in ISRs. by the amount of time it takes to execute the remainder 5. Properly prioritize interrupts relative to threads. of the critical section. I/O-INTENSIVE SYSTEMS. WE FOCUS ON MINIMIZING RESPONSE TIME FOR The following sections discuss these ingredients. 3. Avoid High-Latency Instructions THE HIGHEST PRIORITY INTERRUPT Certain CPU instructions, such as integer divide and 1. Short ISRs string manipulations, can take many cycles to execute; (SINCE LOWER PRIORITY INTERRUPTS Developers should keep ISRs short and simple, avoid- interrupts are inhibited until execution is complete. MAY BE DELAYED BY IT). ing loops and other constructs which can increase Although it is not always practical to avoid these latency and complexity. When an interrupt fires, the instructions in application code, the RTOS kernel itself microprocessor typically disables interrupts globally should avoid them. An RTOS that avoids these instruc- before transferring control to the ISR; then either the tions will, all other things equal, achieve better interrupt ISR must reenable interrupts (when safe to do so) or the latency than an RTOS that ignores this restriction. www.atmel.com page 21 4. Avoid Improper API Use in ISRs perform higher level interrupt handling services, such performance difference in interrupt latency between ISRs commonly do not require any kernel API access at as releasing a semaphore or placing a message into a the Simple and Advanced architectures in the midst of all. The ISR may record some information, check status, queue. The callback is executed by the kernel once it a high priority interrupt preempting a lower priority or perform some other basic operation before acknowl- has returned to a consistent state. If the developer must interrupt. edging the interrupt and returning. In some cases, a write code in the ISR to spawn the callback and then more complex ISR is required in order to wake up a write more code in the callback to do the service call, In addition to reducing ISR footprint, callbacks enable thread for higher level processing. This wake up may be this makes programming more difficult. the bulk of complex ISR processing time to be allocat- accomplished by releasing a semaphore or writing to a ed to specific threads (for example, time spent handling message queue. However, many RTOS vendors permit The good news, however, is that the Advanced RTOS Ethernet interrupts can be attributed to the network the use of a plethora of service calls from ISRs. can hide the details of the two-level handling by pro- TCP/IP thread using the Ethernet device). These per- Although this may seem convenient, it can be deadly viding the required set of service calls (e.g. releasing a thread callbacks provide finer grained control over time when misused. The RTOS vendor should carefully con- semaphore) to ISRs. The service call knows that it is spent in the system and reduce priority inversion (when trol and limit ISRs to a small set of service calls that are being called from an ISR and will place the callback on a low priority interrupt can delay a higher priority thread absolutely necessary and absolutely deterministic. behalf of the programmer. Thus, the code is identical to handling a higher priority interrupt source). This level that used with a Simple RTOS: the ISR calls an API to of control of processing time may not be important in Non-deterministic API calls release a semaphore or post a message. From the simple embedded systems, but as systems grow in As an example of the peril regarding API usage in ISRs, developer’s perspective, there is no additional setup or complexity with many tasks and interrupt sources, this consider how an RTOS handles the queue of threads complexity. Advanced approach can mean the difference between waiting for a resource (e.g. a semaphore or message). There are some important advantages to the Advanced meeting time budgets and going over them. Many Simple RTOSes use an ordinary linked list to hold architecture’s optional two-level handler. Service calls the queue of threads waiting on a resource. When the can take a significant amount of time (especially in the Because ISRs in the Advanced RTOS reenable inter- resource becomes available, the first thread, regardless case of the Simple RTOS that provides unbounded time rupts earlier and reduce overall interrupt latency in the of its importance relative to other waiting threads on the service calls). By pushing this work into the callback system, the Advanced RTOS is typically capable of han- list, is provided the resource and allowed to run (in con- (where interrupts are enabled), the Advanced RTOS dling systems with higher frequency interrupts (e.g. trast, the Advanced RTOS provides a mechanism to reduces the temporal footprint of the ISR which in turn from multiple interrupt sources).