What is the difference between control, bulk, interrupt, and isochronous transfer types? When do you use each?

USB defines four transfer types, each optimized for a different data pattern. The choice is made at design time and declared in the endpoint descriptor — you cannot change the transfer type at runtime.

Control transfers are the only type that uses the setup-data-status three-phase transaction. They are used for device configuration (enumeration requests like GET_DESCRIPTOR, SET_ADDRESS) and class-specific commands (e.g., CDC SET_LINE_CODING). Every device must support control transfers on endpoint 0. Control transfers are reliable (hardware retries on error) and guaranteed a portion of bus bandwidth, but they are relatively slow and have high protocol overhead per transaction. Maximum payload per transaction: 8 bytes (low-speed), 64 bytes (full-speed), 512 bytes (high-speed).

Bulk transfers move large amounts of data with guaranteed delivery but no guaranteed timing. The host controller schedules bulk transfers in whatever bandwidth remains after control, interrupt, and isochronous transfers are served. Bulk transfers use error detection (CRC16) and automatic retry — data is never lost, but latency is unpredictable. Use bulk for mass storage (USB flash drives, MSD class), printers, and file transfers. Available only at full-speed (64 bytes max per packet) and high-speed (512 bytes max per packet) — not available at low-speed.

Interrupt transfers guarantee a maximum latency — the host polls the device at a regular interval specified in the endpoint descriptor (bInterval, 1-255 ms for full-speed, 1-16 microframes at high-speed). Despite the name, USB interrupt transfers are polled, not truly interrupt-driven — the host initiates every transaction. They are reliable (CRC + retry) and latency-bounded, making them ideal for HID devices (keyboards, mice, game controllers) and infrequent status updates. Maximum payload: 8 bytes (low-speed), 64 bytes (full-speed), 1024 bytes (high-speed).

Isochronous transfers guarantee bandwidth and timing but not delivery — there is no retry on error. A corrupted packet is simply dropped. This tradeoff is correct for real-time streaming (audio, video) where a retransmitted packet arriving late is worse than a dropped packet. Isochronous endpoints reserve a fixed fraction of bus bandwidth each frame (1 ms at full-speed, 125 microseconds at high-speed). Maximum payload: 1023 bytes (full-speed), 1024 bytes (high-speed, up to 3 per microframe). Not available at low-speed. The lack of retry means isochronous applications must tolerate occasional errors — audio codecs interpolate, video decoders conceal artifacts.