Embedded Insight Archives
Interrupt-Driven or Polled I/O?
When designing an embedded system, a fundamental decision is the type
of I/O scheme. Should we use interrupt-driven or polled I/O? We'll explore
how this important decision has an impact not only on the firmware but
on the hardware as well.
Fishing for I/O
Polled I/O is much like fishing: there is a lot of waiting. In a polled I/O scheme, software is written to check the status of an I/O device. If there is no data to be received (Rx) or if the device is not ready to transmit (Tx), the software must wait. This technique is called busy-waiting. After waiting for some time, eventually the software can receive or transmit some data, and the rest of the software can execute (see Diagram 1).
Diagram 1: Flowchart for polled I/O
If this sounds inefficient, that's because it is. It's a very simple way of dealing with I/O with no surprises for the developer, but a lot of CPU time is spent waiting for data to transfer.
Interrupt-driven I/O uses a little hardware to aid in efficiency. When the I/O device has already received some data or the I/O device is ready to transmit, an interrupt is generated, and the appropriate interrupt service routine (ISR) handles reading or writing some data. Interrupts add a level of complexity, and can be very difficult to debug, but the resulting system wastes no time waiting for data to transfer (see Diagram 2).
Diagram 2: Flowchart for interrupt-driven I/O
Yes, ISRs can be this simple. The above diagram shows separate
ISRs for the receiver and transmitter if there are two separate interrupts.
Sometimes there is only one interrupt for both functions, so the ISR is
a little more complicated.
From the simple example above, it may appear that interrupts and ISRs
are very easy to implement. In many cases they are, but they can also
be very complicated. The development cost of ISRs is generally higher
than polled I/O. Consider that you're not only developing the functionality
of the polled I/O routines, but you've also got to deal with how interrupts
work in your particular system. Polled I/O occurs at very specific points
in the firmware (i.e. whenever the polled I/O routines are called). Interrupts
can happen at anytime. An interrupt bug can cause anything from simple
system crashes to really frustrating intermittent data loss and unreliable
Which Is Best?
The decision to use polled or interrupt-driven I/O is usually pretty easy. If you've got the interrupt, use it! In the long run, even though it may take more time to develop, interrupt-driven I/O leads to a solid design, predictable performance, and holds up well to modifications of application code. However, if you've got a very simple design, using a straightforward polled I/O scheme may be preferable. There are a few factors which can influence your design.
By the way, there is no reason that you can't incorporate both types
of I/O in a system. For example, perhaps your Ethernet driver uses interrupts
and your serial port driver doesn't. It's all a matter of using a suitable
technique for each situation.
Simulating Interrupt-Driven I/O
So what if you've got a system where there are no more external interrupts and you want some interrupt-driven I/O? You can simulate interrupt-driven I/O by using a dedicated task in an RTOS. While you can't really address interrupt latency with this technique, it gives CPU time to other tasks when there is no data to receive or transmit. An example task is shown below which handles receiving and transmitting characters on a UART.
Diagram 3: Flowchart of UARTTask
Both polling and interrupt-driven techniques should be in the embedded designer's toolbox. While we recommend using interrupt-driven I/O whenever possible, it doesn't really matter which technique you use as long as the final design meets product requirements, is easy to understand, and is easy to maintain.
Base2 Software Design specializes in the development of embedded software for medical devices and consumer electronics. We understand the requirements for these industries, and we work with you to meet your goals.
Medical device manufacturers need more than just working software. Besides good quality software, you need to follow a software development process and provide supporting documentation for FDA scrutiny. We can help you with these requirements in addition to the normal software development activities.
In consumer electronics, speed is often the key. Your window of opportunity is closing fast. Maybe you need to get a demo running in a couple of months, and the only thing you have now is a drawing on a napkin. We have the experience and resourcefulness to get the job done quickly. We'll work closely with the entire product development team to make sure things are done right the first time, so your product will be successful in the marketplace.
We have the expertise to work across disciplines and bridge gaps between software engineering, electrical engineering, and even mechanical engineering. Whether you need help on an existing project or you're starting a new one, you should give us a call and see how you can benefit from our services.
The latest offering from Microchip is the PIC16F72 PICmicro® microcontroller. This field programmable microcontroller is pin-out and code compatible with the PIC16CR72 (OTP) and PIC16C72 (EPROM) microcontrollers. Here are some of the features of the PIC16CR72:
With the PWM and ADC, this microcontroller would be a good choice for control applications in the automotive, industrial, and appliance industries. As with other PIC micros, most I/O pins are multifunction pins, so you'll be trading off peripheral pins for I/O.
The PIC16F72 is available in 28-pin PDIP, SOIC, SSOP, and QFN packages. Budgetary pricing is around $2 each (Qtr 1K). For more information on the PIC16F72, see the Microchip website at http://www.microchip.com/1010/pline/picmicro/category/embctrl/14kbytes/devices/16f72/index.htm.
If you know anyone who would like to receive this informative newsletter, please forward this to them. They can sign up by sending an e-mail to mailto:email@example.com?Subject=Subscribe.
If this newsletter was sent to you in error or if you'd like to unsubscribe to our newsletter, simply send an e-mail to mailto:firstname.lastname@example.org?Subject=Unsubscribe.
You may use the contents of Embedded Insight in whole or in part if you include the following complete copyright notice and live links:
© 2002-2009, base2 software design, inc.