USB Part 1: Fundamentals & System Architecture

USB Architecture Basics

Host ↔ Device Model

USB uses a strict host-controller / peripheral device model. This is fundamentally different from CAN bus or Ethernet, where any node can initiate communication. In USB:

• The host (typically a PC, Raspberry Pi, or STM32 in OTG host mode) controls all bus activity. It decides when each device gets to transmit. It initiates all transfers.
• The device (your STM32, RP2040, nRF52, etc.) is entirely reactive. It can never spontaneously send data to the host. It can only respond to host-initiated requests or pre-schedule data in a buffer that the host will poll.

This asymmetry has profound implications for firmware design. Your USB device firmware must:

1. Always have valid data ready when the host reads an endpoint (IN direction)
2. Always have buffer space available when the host writes to an endpoint (OUT direction)
3. Respond to control requests (Endpoint 0) within a tight timing window (typically 50 ms, but often much less in practice)

USB Topology & Hubs

USB forms a tiered star topology rooted at the host controller. The host contains a root hub — the first hub in the chain. External hubs extend the tree, with each hub adding another tier.

USB Host Controller (root hub)
├── Device A (direct connection — Tier 1)
├── Hub 1 (external hub — Tier 1)
│   ├── Device B (Tier 2)
│   ├── Device C (Tier 2)
│   └── Hub 2 (nested hub — Tier 2)
│       ├── Device D (Tier 3)
│       └── Device E (Tier 3)
└── Hub 3 (external hub — Tier 1)
    └── Device F (Tier 2)

Maximum depth: 7 tiers (USB spec limit)
Maximum devices: 127 per host controller

Key topology constraints:

• Maximum 7 tiers (including root hub) — a device at tier 7 must still meet timing requirements
• Maximum 127 simultaneously addressed devices per host controller
• Hubs are USB devices themselves — they have their own descriptors and enumeration
• Bus bandwidth is shared — adding devices reduces available bandwidth per device

USB Speeds

Low Speed through SuperSpeed

Choosing the Right Speed

Transfer Types — The Critical Concept

USB transfer types are the single most important concept in USB firmware design. The transfer type you choose for an endpoint determines the bandwidth guarantee, error handling behaviour, and latency characteristics of every data exchange between your device and the host. Getting this wrong produces firmware that works in testing but fails unpredictably under real conditions.

Control Transfers

Control transfers are mandatory — every USB device must support them on Endpoint 0. They are used exclusively for device configuration and management: enumeration requests, descriptor retrieval, class-specific configuration.

• Structure: SETUP stage → optional DATA stage → STATUS stage (three phases)
• Reliability: fully error-checked, retried on error
• Bandwidth: reserved — the host guarantees at least 10% of FS frame time for control
• Use case: enumeration only. Do not use control for application data — it is slow and ties up Endpoint 0

/* TinyUSB: every control request arrives here */
bool tud_vendor_control_xfer_cb(uint8_t rhport, uint8_t stage,
                                 tusb_control_request_t const *request)
{
    if (stage != CONTROL_STAGE_SETUP) return true;

    switch (request->bRequest) {
        case VENDOR_REQUEST_GET_VERSION:
            /* Respond with firmware version string */
            return tud_control_xfer(rhport, request,
                                    &fw_version, sizeof(fw_version));
        default:
            return false; /* Stall unsupported requests */
    }
}

Bulk Transfers

Bulk transfers are the workhorse of USB data transfer. They offer guaranteed error-free delivery (via CRC and retry) but no bandwidth guarantee — the host schedules bulk transfers in the remaining frame time after control and periodic transfers.

• Max packet size: 64 bytes (FS), 512 bytes (HS)
• Error handling: CRC16 per packet, NAK/retry, up to 3 consecutive errors before abort
• Bandwidth: best-effort — can be very fast when bus is quiet, very slow when congested
• Use cases: CDC serial data, mass storage, data loggers, oscilloscopes

Interrupt Transfers

Despite the name, interrupt transfers do not generate hardware interrupts on the host. The name comes from their scheduling: the host polls the endpoint at a guaranteed maximum interval — the polling interval — specified in the endpoint descriptor.

• Max packet size: 64 bytes (FS), 1024 bytes (HS)
• Polling interval: 1–255 ms (FS), 125 µs – 4096 ms (HS) — set in endpoint descriptor
• Bandwidth: reserved — the host allocates fixed bandwidth for the polling period
• Use cases: HID (keyboard, mouse, gamepad), CDC notification endpoint

/* TinyUSB HID: called when host polls the interrupt endpoint */
void hid_task(void)
{
    /* Wait until host is ready to receive */
    if (!tud_hid_ready()) return;

    /* Send keyboard report if a key is pressed */
    if (btn_pressed()) {
        uint8_t keycode[6] = { HID_KEY_A };
        tud_hid_keyboard_report(REPORT_ID_KEYBOARD, 0, keycode);
    } else {
        /* Send empty report to signal key release */
        tud_hid_keyboard_report(REPORT_ID_KEYBOARD, 0, NULL);
    }
}

Isochronous Transfers

Isochronous transfers provide guaranteed bandwidth and fixed latency but no error recovery. If a packet is corrupted, it is discarded — there is no retry. This is the only correct choice for real-time streaming data where a lost packet is better than a late one.

• Max packet size: 1023 bytes (FS), 1024 bytes (HS)
• Transfer occurs every frame (1 ms FS, 125 µs HS micro-frame)
• No handshake, no retry — data is transmitted once
• Use cases: USB audio microphone/speaker, USB video, music MIDI with strict timing

Transfer Type Comparison

The USB Protocol Stack

Stack Layers Explained

USB firmware is always structured as a layered stack. Each layer has a clear responsibility, and understanding the boundaries between layers is what separates developers who understand USB from those who cargo-cult example code.

┌─────────────────────────────────────────────────────┐
│  APPLICATION LAYER                                  │
│  Your firmware logic: read sensor, blink LED        │
│  Calls: tud_cdc_write(), tud_hid_report(), etc.     │
├─────────────────────────────────────────────────────┤
│  CLASS DRIVER LAYER                                 │
│  CDC, HID, MSC, Audio, MIDI class implementations  │
│  Implements class-specific protocol on top of USB   │
├─────────────────────────────────────────────────────┤
│  USB CORE LAYER                                     │
│  Enumeration, descriptors, Endpoint 0 handling     │
│  Transfer scheduling, frame management             │
├─────────────────────────────────────────────────────┤
│  CONTROLLER DRIVER (DCD) LAYER                      │
│  MCU-specific: STM32 OTG_FS, RP2040 USB, nRF USB   │
│  Programs USB peripheral registers, handles IRQs   │
├─────────────────────────────────────────────────────┤
│  HARDWARE (PHY)                                     │
│  D+/D- signalling, NRZI encoding, CRC, bit stuffing│
└─────────────────────────────────────────────────────┘

Where TinyUSB Fits

TinyUSB is an open-source USB device (and host) stack that implements the USB Core Layer and Class Driver Layer. It provides a clean API for your application layer and has ports for every major embedded MCU family. This is why TinyUSB is the recommended USB stack for embedded development today — it separates concerns cleanly and is much more maintainable than ST's USB middleware.

USB vs Other Protocols

Choosing USB over simpler protocols is a deliberate engineering decision. The complexity cost is real — USB adds weeks of development time. The benefits must justify that cost.

Use USB when:

• You need the device to appear as a standard class (keyboard, serial port, flash drive) without the user installing drivers
• You need USB power delivery (up to 100 W with USB-C PD)
• You need hot-plug detection and automatic OS enumeration
• Your throughput requirement exceeds what UART can reliably deliver

Do not use USB when UART, SPI, or I2C between two MCUs on the same board would suffice. The complexity of USB is justified only when connecting to a general-purpose host (PC, SBC) or when the standard class benefits (no driver install) matter to the end user.

Exercises

USB System Assessment

Use this tool to document your USB system design — target MCU, required speed, transfer types, device classes, and USB stack selection. Download as Word, Excel, PDF, or PPTX for project documentation or design review.

Conclusion & Next Steps

In this opening article we have built the foundational mental model that every USB developer needs:

• USB is a system — not a simple protocol. It spans electrical signalling, packet-level framing, device class behaviour, and OS driver interaction simultaneously.
• The host-device model is asymmetric and non-negotiable: the host controls all bus activity; the device is entirely reactive. This drives every firmware design decision.
• The four transfer types — Control, Bulk, Interrupt, Isochronous — each offer a different combination of bandwidth guarantee, error recovery, and latency. Choosing the wrong type produces firmware that works in the lab and fails in production.
• Full Speed (12 Mbit/s) with an internal PHY covers the vast majority of embedded USB use cases — CDC, HID, MSC, composite devices. High Speed is needed only for high-throughput applications.
• TinyUSB is the recommended USB stack for new embedded projects — clean architecture, no dynamic memory, multi-MCU, and well-maintained.