Embedded Insight Archives

/*------------------------------------------------------------------*\

Embedded Insight

The Monthly Newsletter for Embedded Systems Professionals

Published by Base2 Software Design, Inc.
    http://www.base2software.com
    mailto:info@base2software.com

September, 2002

\*------------------------------------------------------------------*/

• Interrupt-Driven or Polled I/O?
• Base2 Specialties
• Microchip PIC16F72

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.

Development Time

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 system performance.

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.

Throughput. If your system throughput requirements are very high, you must use interrupt-driven I/O. Polled I/O won't work because the CPU efficiency won't be high enough to move the data and do everything else. However, if you've got a specialized system with extremely high data rate requirements, it may actually be faster to use polled I/O. That's because polled I/O doesn't incur any interrupt overhead or interrupt latency (see below).

Interrupt latency. Interrupt latency is the time it takes for the processor to respond to an interrupt event. These times range from 100's of nanoseconds to 10's of microseconds. In very rare cases, if interrupt latency is long or unpredictable, it may be preferable to poll for an event in very controlled conditions to ensure quick capture of an event.

Interrupt availability. Most of today's microcontrollers have several external interrupts. If a hardware interrupt is not available, you will have no choice but to poll for I/O (see Simulating Interrupt-Driven I/O below). It's best to work with the electrical engineers to make sure that the microcontroller you choose works for both the electrical and firmware designs.

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

Conclusion

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 Specialties

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.

Microchip PIC16F72

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:

• DC to 20 MHz clock rate
• 2K x 14 program memory (Flash)
• 128 x 8 RAM
• 3 timers
• Capture, Compare, and PWM module (CCP)
  • 16-bit capture and compare
  • 10-bit PWM
• 5-channel 8-bit ADC
• 1 Synchronous Serial Port (supports SPI and I2C)
• up to 22 I/O pins
• watchdog timer
• 1,000 Flash erase/write cycles typical

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:info@base2software.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:info@base2software.com?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:

Copyright 2002, Base2 Software Design, Inc.
http://www.base2software.com. mailto:info@base2software.com.