In addition to the mandatory Control Endpoint (EP0), USB devices can implement three other endpoint types for transferring application data:
- Bulk Endpoints
- Interrupt Endpoints
- Isochronous Endpoints
These endpoints are optional and are added based on the device's class and functional requirements. They are described in the device's Endpoint Descriptors.
1. Bulk Endpoints
Bulk endpoints are used for large, non-time-critical data transfers that require reliability.
Characteristics
| Property | Detail |
|---|---|
| Error recovery | Yes — CRC check + handshake + retransmission |
| Guaranteed bandwidth | No — uses leftover bandwidth after control/interrupt/isochronous |
| Guaranteed latency | No — variable; can be delayed under heavy bus load |
| Max packet size (FS) | 8, 16, 32, or 64 bytes |
| Max packet size (HS) | 512 bytes |
| Max packet size (SS) | 1024 bytes (with burst up to 16 packets) |
| Low-speed support | No |
How Bulk Transfers Work
- Host sends an OUT token (or IN token) to the endpoint
- Data packet is sent
- Receiver responds with a handshake:
- ACK — data received successfully
- NAK — endpoint busy, retry later
- STALL — endpoint error, requires host intervention
Data Toggle (Error Detection)
Bulk endpoints use a DATA0/DATA1 toggle mechanism:
- Each successful transaction alternates the expected data PID (DATA0 ↔ DATA1)
- If the receiver gets a packet with the wrong toggle, it knows a packet was lost or duplicated
- This provides an additional layer of error detection beyond CRC
Common Applications
| Device | OUT Endpoint | IN Endpoint |
|---|---|---|
| USB flash drive | SCSI commands, write data | Read data, status |
| USB printer | Print data | Status responses |
| USB Ethernet adapter | Outgoing packets | Incoming packets |
2. Interrupt Endpoints
Interrupt endpoints are used for small, periodic data that requires predictable response times.
Characteristics
| Property | Detail |
|---|---|
| Error recovery | Yes — CRC check + handshake + retransmission |
| Guaranteed bandwidth | Limited — reserved based on polling interval |
| Guaranteed latency | Yes — bounded by polling interval |
| Max packet size (LS) | 1–8 bytes |
| Max packet size (FS) | 1–64 bytes |
| Max packet size (HS) | 1–1024 bytes (up to 3 per microframe) |
| Low-speed support | Yes |
How Interrupt Transfers Work
Despite the name, interrupt endpoints are not driven by hardware interrupts. The host polls the endpoint at a regular interval specified in the Endpoint Descriptor (bInterval field).
| Speed | Polling Interval Range |
|---|---|
| Low-speed | 10–255 ms |
| Full-speed | 1–255 ms |
| High-speed | 125 µs × 2^(bInterval-1), i.e., 125 µs to 4 s |
In SuperSpeed, interrupt endpoints use an asynchronous notification model (NRDY/ERDY) instead of polling — see SS flow control.
Common Applications
| Device | Endpoint | Data |
|---|---|---|
| USB keyboard | Interrupt IN | Key press/release reports |
| USB mouse | Interrupt IN | X/Y movement, button state |
| Game controller | Interrupt IN | Joystick, button states |
| Keyboard LEDs | Interrupt OUT | Caps Lock, Num Lock state |
3. Isochronous Endpoints
Isochronous endpoints are designed for continuous real-time data streaming where timing is more important than reliability.
Characteristics
| Property | Detail |
|---|---|
| Error recovery | No — no handshake, no retransmission |
| Guaranteed bandwidth | Yes — reserved at configuration time |
| Guaranteed latency | Yes — fixed service intervals |
| Max packet size (FS) | 1–1023 bytes |
| Max packet size (HS) | 1–1024 bytes (up to 3 per microframe) |
| Max packet size (SS) | 1–1024 bytes (with burst up to 16 packets) |
| Low-speed support | No |
How Isochronous Transfers Work
- The host schedules isochronous transactions in the periodic schedule (once per frame/microframe)
- Data is sent without handshake packets — the receiver never NAKs or ACKs
- CRC errors are detected but not corrected — corrupted data is simply discarded
- The next scheduled transaction proceeds regardless of the previous result
Why No Retransmission?
For real-time streams like audio and video:
- A late packet is worse than a lost packet — retransmission would add unacceptable latency
- Applications can interpolate or conceal missing samples
- Consistent timing is more important than perfect data
Common Applications
| Device | Direction | Data |
|---|---|---|
| USB webcam | Isochronous IN | Video frames |
| USB microphone | Isochronous IN | Audio samples |
| USB speakers / DAC | Isochronous OUT | Audio playback stream |
| USB audio interface | Both | Full-duplex audio recording and playback |
Comparison of All Endpoint Types
| Property | Control | Bulk | Interrupt | Isochronous |
|---|---|---|---|---|
| Mandatory? | Yes (EP0) | No | No | No |
| Reliable? | Yes | Yes | Yes | No |
| Guaranteed timing | No | No | Yes | Yes |
| Guaranteed bandwidth | No | No | Limited | Yes |
| Direction | Bidirectional | Unidirectional | Unidirectional | Unidirectional |
| Low-speed? | Yes | No | Yes | No |
| Typical use | Config, commands | Storage, printers | Keyboard, mouse | Audio, video |
Low-Speed Device Restrictions
Low-speed devices (1.5 Mbps) have significant limitations:
| Endpoint Type | Supported? | Max Packet Size | Notes |
|---|---|---|---|
| Control | Yes | 8 bytes | EP0 only |
| Interrupt | Yes | 1–8 bytes | Max 2 interrupt endpoints |
| Bulk | No | — | Not permitted |
| Isochronous | No | — | Not permitted |
Low-speed devices are limited to simple, low-data-rate peripherals (keyboards, mice, simple sensors).
Choosing an Endpoint Type
| Requirement | Best Choice | Rationale |
|---|---|---|
| Data integrity matters most | Bulk | Full error recovery, retransmission |
| Small, timely updates needed | Interrupt | Guaranteed polling interval |
| Continuous streaming, timing-critical | Isochronous | Reserved bandwidth, fixed interval |
| Device setup and configuration | Control (EP0) | Always available, structured request/response |