Side-by-side comparison
| Parameter | Polling | Interrupt I/O |
|---|---|---|
| CPU Utilisation | Low — CPU loops checking status register | High — CPU works on other tasks between events |
| Response Latency | Proportional to poll interval — can miss fast events | Low — typically 1–2 µs after interrupt assertion |
| Implementation Complexity | Simple — software loop, no hardware support needed | Higher — needs ISR, stack management, 8259 PIC for multiple sources |
| Hardware Required | None beyond I/O port (e.g., 8255 PPI Port C status bit) | Interrupt controller (8259A PIC) for multiple sources; INT line wired to CPU |
| Determinism | Deterministic — known worst-case response time | Non-deterministic — depends on interrupt latency and ISR execution |
| Power Consumption | High — CPU always running at full speed | Lower — CPU can enter HALT/sleep between interrupts |
| Missed Events | Possible if event occurs between polls | Not missed — hardware latches the interrupt request |
| Typical 8085 Example | Read 8255 Port C bit in loop until BUSY = 0 | Wire printer BUSY to RST 5.5; ISR sends next byte |
| Suitable For | Slow peripherals, simple single-task systems | Fast peripherals, multitasking, low-power systems |
Key differences
Polling burns CPU cycles proportional to the wait time — a printer taking 5 ms to print a character means the CPU checks the BUSY line thousands of times before it clears. Interrupt-driven I/O lets the 8085 execute the HALT instruction (or other tasks) until the printer asserts the RST 6.5 line low, triggering the ISR automatically. The 8259A PIC extends this to 8 prioritised interrupt sources, cascadable to 64, allowing the 8086 PC architecture to handle keyboard, timer, serial port, and disk simultaneously. The cost is software complexity: the ISR must save registers, service the device, issue EOI to the 8259A, and restore context — steps polling skips entirely.
When to use Polling
Use polling when you have a single slow peripheral, simple single-threaded code, and predictable timing matters more than CPU efficiency. Bit-banging an I²C bus or waiting for an ADC conversion complete flag in a bare-metal loop are classic polling applications.
When to use Interrupt I/O
Use interrupt-driven I/O when the peripheral is asynchronous, fast, or when the CPU must do other work between events. A UART receiver generating an interrupt on every incoming byte (connected to the 8086's INT line via 8259A) is the standard example — polling a UART at 115200 baud would waste thousands of cycles per character.
Recommendation
For any system design question in exams or interviews, choose interrupt-driven I/O whenever the peripheral is faster than a few milliseconds or the system is multitasking. Choose polling only when you explicitly need deterministic timing or the peripheral is trivially slow.
Exam tip: The examiner will ask you to write the 8085 ISR entry sequence: push all registers to the stack, service the device, pop registers, and execute EI followed by RET — missing EI before RET (re-enabling interrupts) is the single most common marks-losing error.
Interview tip: A TCS or Wipro embedded interviewer expects you to explain the role of the 8259A PIC — how it prioritises 8 interrupt sources, sends an interrupt vector to the CPU, and requires an End-of-Interrupt (EOI) command in the ISR before the next interrupt is acknowledged.