Programmed I/O, Interrupt-Driven I/O and DMA — Complete Guide

🔄The Three I/O Techniques

Every computer system must solve the same fundamental problem: how does the CPU coordinate data transfers between itself, memory, and much-slower peripheral devices — without wasting CPU time or losing data? Three techniques address this, each a step more sophisticated than the last:

Figure 1 — The three I/O techniques: CPU involvement decreasing left to right

The three I/O techniques in order of increasing CPU efficiency. Programmed I/O (polling) wastes CPU cycles waiting. Interrupt-driven I/O frees the CPU between transfers but still requires it to handle each data word. DMA delegates entire block transfers to dedicated hardware, involving the CPU only at the start and end.

👀Programmed I/O — How It Works

In programmed I/O (also called polling or busy-wait I/O), the CPU has direct, exclusive control over every step of the I/O operation. It initiates the transfer, monitors the device status, and transfers each data word manually.

Step-by-step sequence for a read

CPU issues a READ command to the I/O module (via control bus)
I/O module initiates the operation with the peripheral device
CPU enters a busy-wait loop — it repeatedly reads the I/O module’s status register until the READY bit is set
When READY is detected: CPU reads the data word from the I/O module’s data register
CPU writes the word to main memory (or processes it directly)
Repeat from step 1 for the next word

The fundamental waste: At step 3, the CPU spins in a tight loop doing nothing useful. For a printer running at 100 characters/second, the CPU is idle for 99.99% of its time between each character. At 1 GHz: 10 million wasted cycles per character.

When programmed I/O is acceptable

Single-purpose embedded systems: A microcontroller running one fixed task (e.g. a thermostat) has nothing else to do while waiting — polling is perfectly fine.
Very short wait times: If the device response time is shorter than the interrupt overhead, polling is actually faster. SPI reads on a high-speed device (SCLK=50 MHz, 8 bits = 160 ns) are often better handled by tight polling loops than interrupts.

📊Programmed I/O — Flowchart

Figure 2 — Programmed I/O flowchart (read operation)

Programmed I/O read flowchart. The CPU issues a READ command, then enters a tight polling loop reading the status register. The “NO” branch of READY? loops back — this is the busy-wait. Once READY, the CPU reads the data word and writes it to memory, then repeats for the next word.

🔔Interrupt-Driven I/O — How It Works

Interrupt-driven I/O eliminates the busy-wait by allowing the CPU to do useful work while the I/O device operates. Instead of the CPU asking “are you ready yet?”, the device says “I am ready now” via an interrupt signal.

From the CPU’s perspective

Issues READ command to I/O module
Continues executing other instructions — no polling
At the end of each instruction cycle, checks the IRQ line
When IRQ detected: saves context (PC, registers, PSW)
Executes the ISR — reads word from I/O module’s data register, stores it in memory
Restores context, resumes the interrupted program

Figure 3 — Interrupt-driven I/O: CPU and I/O device operate concurrently

Interrupt-driven I/O timing. While the device operates (yellow), the CPU executes other instructions (green). When the device is ready, it pulses the IRQ line (purple). The CPU runs the short ISR, reads the data word and stores it, then resumes its previous work. Device and CPU activity overlap.

Remaining limitation: Interrupt-driven I/O still requires the CPU to execute ISR code for every single data word transferred. For a disk reading a 64 KB file at 32-bit word granularity, that means 16,384 interrupts — 16,384 context saves, 16,384 ISRs, 16,384 context restores. This motivates DMA.

🔍Interrupt I/O — Identifying the Device

When an interrupt fires, the CPU must know which device triggered it. Four identification methods exist:

Method	How it works	Advantage	Disadvantage
Multiple IRQ lines	Each device gets its own dedicated interrupt line. CPU examines which line is asserted.	Fastest identification — hardware direct	Limits number of devices to number of CPU interrupt pins
Software poll	All devices share one IRQ line. On interrupt, CPU polls each device’s status register in priority order.	Unlimited devices on one IRQ line	Slow — must poll all devices
Daisy chain (HW poll)	Interrupt ACK propagates along a chain. First device that requested the interrupt claims it and places its vector on the data bus.	Fast hardware identification · Scalable	Priority fixed by position in chain
Bus mastering	Device must claim the bus before raising an interrupt. Used in PCI.	Combined bus arbitration and interrupt	Complex arbitration protocol

Modern systems use a dedicated interrupt controller (Intel 8259A PIC; ARM GIC handles up to 1020 sources with programmable priority). The interrupt controller signals the CPU on a single INTR line and provides the interrupt vector when the CPU acknowledges.

🎚️Multiple Interrupts & Priority

In a real system, many devices can interrupt simultaneously. The interrupt controller assigns priorities so the most urgent device is serviced first. Higher-priority interrupts can preempt lower-priority ISRs already running:

🔍 Worked Example — Priority Interrupt Handling

Setup: Three interrupt sources: Timer (priority 1 — highest), Disk (priority 2), UART (priority 3 — lowest).

t=0ms: UART fires IRQ (priority 3) → CPU saves context, enters UART ISR
t=1ms: Disk fires IRQ (priority 2 > 3) → UART ISR preempted
CPU saves UART ISR context, enters Disk ISR
t=3ms: Timer fires IRQ (priority 1 > 2) → Disk ISR preempted
CPU saves Disk ISR context, enters Timer ISR
t=3.1ms: Timer ISR completes → restores Disk ISR context
t=5ms: Disk ISR completes → restores UART ISR context
t=5.5ms: UART ISR completes → restores user program context

Stack at deepest nesting: [User context] [UART ISR context] [Disk ISR context] → Timer ISR running. The stack depth is bounded by the number of priority levels.

⚡DMA — Why It Is Needed

Both programmed I/O and interrupt-driven I/O share two fundamental drawbacks for large data transfers:

Transfer rate limited by CPU speed: The CPU must execute instructions to move each word.
CPU tied up per word: For interrupt-driven I/O, every word requires a context save + ISR + context restore — typically 50–200 cycles overhead per word.

Quantified cost: A disk read of 512 KB at 32-bit word granularity = 131,072 words = 131,072 interrupts. At 100 cycles per interrupt = 13,107,200 wasted cycles. At 3 GHz this is ~4.4 ms of pure overhead. DMA reduces this to a single interrupt at the end of the entire block.

DMA (Direct Memory Access) introduces a dedicated hardware controller that can take over the system bus and transfer data directly between a peripheral and main memory without the CPU processing each word. The CPU is involved only at the start (to program the DMA controller) and end (to receive the completion interrupt).

🚀DMA — How It Works

To initiate a DMA transfer, the CPU programs the DMA controller with four pieces of information:

Parameter	What the CPU tells the DMA controller
Direction	Read (device → memory) or Write (memory → device)
Device address	Which peripheral device (I/O port address or device identifier)
Memory start address	Starting address in RAM where data will be read from or written to
Word/byte count	How many words (or bytes) to transfer in total

Once programmed, the CPU continues with other work. The DMA controller executes the entire transfer autonomously:

DMA controller requests the system bus (asserts DMA_REQ to the bus arbiter)
Bus arbiter grants the bus (asserts DMA_ACK)
DMA controller reads one word from the peripheral into its internal data register
DMA controller writes that word to the next memory location (auto-increments the address register)
Decrements the word count register
If count ≠ 0: repeat from step 1 for the next word
When count = 0: assert IRQ to notify the CPU that the block transfer is complete

Cycle stealing: The DMA controller steals one bus cycle from the CPU at a time. The CPU is suspended just before it would access the bus (between instruction decode and operand fetch). This is not a context switch — the CPU does not save registers. It simply pauses for one cycle, then resumes. The net effect is the CPU runs slightly slower, but the DMA transfer proceeds at full bus bandwidth.

🔧DMA Block Diagram

Figure 4 — DMA controller: internal registers and system bus connection

DMA controller internal structure. Three key registers: Data Register (one-word buffer), Address Register (auto-incrementing memory pointer), and Count Register (words remaining). DMA_REQ/DMA_ACK signals arbitrate for bus ownership. When Count reaches zero, INTR fires to notify the CPU.

🔀DMA Configurations

Three DMA hardware configurations exist, differing in how the DMA controller connects to the system bus:

Figure 5 — Three DMA configurations: detached, integrated, and separate I/O bus

Three DMA configurations. Config ①: DMA separate from I/O devices on the same bus — each word transfer uses the bus twice. Config ②: DMA controller integrates I/O devices — reads device internally, one bus access to write memory. Config ③: I/O devices on a dedicated I/O bus; DMA bridges to the system bus — cleanest separation.

⚖️Technique Comparison

Figure 6 — CPU activity comparison across all three I/O techniques (reading a block)

CPU activity during a block I/O read. Programmed I/O (left): CPU occupies the entire transfer period. Interrupt-Driven (centre): CPU alternates between useful work and short ISRs, one per word. DMA (right): CPU runs user work uninterrupted; only one IRQ at the end of the entire block transfer.

Feature	Programmed I/O	Interrupt-Driven I/O	DMA
CPU during transfer	Busy — polling loop	Mostly free — ISR per word	Free — only start/end
Interrupts per block	0 (no interrupts)	N (one per word)	1 (block complete)
Hardware needed	Minimal (none extra)	Interrupt controller	DMA controller + arbiter
Transfer rate	Limited by CPU speed	Better	Full bus bandwidth
Best for	Short transfers, dedicated MCU	Word-sized transfers, low latency	Large block transfers (disk, NIC)
Complexity	Lowest	Medium	Highest

🔬VLSI Connections

🔬 DMA controllers in SoC — AMBA DMA-330 and channel descriptors

Every non-trivial SoC contains one or more DMA controllers. ARM’s PL330 / DMA-330 is the standard AMBA DMA engine used in STM32, Rockchip, Samsung Exynos, and many others. The DMA-330 has 8 channels, each with a dedicated thread executing a microcode program — the channel descriptor. Instead of simple source/destination/count registers, the DMA-330 executes a small instruction set (DMALP for loop, DMALD for load, DMAST for store, DMAEND for end) stored in a descriptor buffer in memory. This allows complex scatter-gather transfers — reading from 10 non-contiguous source regions and writing to a single destination — with a single CPU programming operation.

🔬 Cache coherence and DMA — a critical SoC design problem

DMA creates a subtle cache coherence problem. If the CPU writes data to a buffer in memory, and the CPU’s L1 write-back cache has not yet flushed those writes to DRAM (dirty cache lines), the DMA controller will read stale data from DRAM. Solutions: (1) Cache flush/invalidate in software — the driver explicitly flushes dirty lines before DMA TX and invalidates cache lines after DMA RX. (2) Hardware coherent DMA — the DMA’s AXI master port is connected to the cache coherent interconnect (ACE or CHI), so DMA automatically participates in the MESI protocol. ARM’s CCI-400 and CMN-600 support hardware-coherent DMA. Choosing between these two approaches — and correctly implementing the chosen one in both RTL and driver code — is one of the most common DMA-related bugs in SoC design.

🔬 Interrupt latency vs throughput — the engineering trade-off

The three I/O techniques represent a fundamental engineering trade-off between latency and throughput. Programmed I/O has the lowest latency — the CPU reacts to data as fast as it polls, with no interrupt overhead. Interrupt-driven I/O has moderate latency with multitasking. DMA has the highest throughput for bulk transfers but adds setup latency (programming the controller, cache maintenance) that makes it inefficient for small transfers. In SoC peripheral design: a touch screen controller generating 120 events/second uses interrupt-driven I/O; a camera ISP writing 4K frames at 60 fps uses DMA; a JTAG debug interface reading one byte at a time uses programmed I/O.

Summary — CA-09 key points: Three I/O techniques with decreasing CPU involvement. Programmed I/O (polling): CPU controls every step, polls status register in a busy-wait loop — wastes CPU time; best for single-purpose MCUs or very short transfers. Interrupt-Driven I/O: CPU issues command and does other work; device asserts IRQ when ready; CPU runs ISR for each word — eliminates polling waste but CPU still handles every word; four device identification methods (dedicated line, software poll, daisy chain, bus mastering). DMA: CPU programs DMA controller (direction, device address, memory start, word count); DMA transfers entire block via cycle stealing; single IRQ on completion — CPU free throughout. DMA creates cache coherence challenges requiring software cache maintenance or hardware-coherent bus connections.