We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 21550

11.1 EDK MicroBlaze/PowerPC - What is the difference between polled mode and interrupt-driven mode?


Keywords: I/O, response time, throughput, stability, OS, RTOS

What is the difference between polled mode versus interrupt-driven I/O with respect to MicroBlaze and PowerPC processor systems? What effect does the addition of an operating system have in terms of stability, response time, and throughput?


In polled mode, the application program continually polls the various system peripherals to determine if they need servicing. This is usually implemented in an infinite loop in which the peripherals are polled on a "round robin" basis. Such polled applications are simple to implement. When a peripheral is ready for servicing, it must wait until the software polls this peripheral before it can be serviced. Consequently, polled-mode peripherals experience slower response time from the microprocessor as more peripherals are added to the embedded system. In a round robin polled-mode, a peripheral cannot have higher priority over another. If the polling is implemented in a round robin infinite loop, the worst-case response time is the sum of all other task code within that loop. Polled-mode systems can become unstable as more peripherals are added to the system, since the response time of each peripheral is affected. If the system is small enough, a polled-mode application can be appropriate, since it will generally provide a higher throughput.

In interrupt-driven mode, each peripheral usually has one interrupt indirectly feeding into the microprocessor's interrupt port through an interrupt controller. The interrupts coming from peripherals can be prioritized. For example, one peripheral can be assigned a higher interrupt priority than another. In interrupt-driven mode, a peripheral asserts an interrupt when it needs to be serviced. The microprocessor always services the highest priority interrupt first. If the peripheral is the highest priority interrupting peripheral, the microprocessor services the peripheral almost immediately. Consequently, the response time of an interrupt-driven system is much faster. However, in interrupt-driven systems there is the possibility that lower-priority peripherals are not serviced. As such, interrupt-driven systems must be carefully designed according to the real time requirements of the various peripherals. There is generally more stability with interrupt-driven systems, since the response time for each interrupt can be estimated with more accuracy and peripherals can be added to the system without affecting the response time of existing peripherals. However, depending on the system, the throughput might not be as high as a simple polled application.

Real Time Operating Systems (RTOS) use an interrupt-driven methodology, and generally have good response time and are more stable than polling software loops. RTOSs are designed with very accurate response time specifications and are more predictable. However, due to the kernel overhead and context switching, RTOSs can have less throughput than stand-alone interrupt applications and even less throughput than a polled-mode application.

AR# 21550
Date 04/25/2009
Status Active
Type General Article