What Is USB?

Detailed Explanation

USB was designed to replace the proliferation of incompatible PC peripheral connectors (serial ports, parallel ports, PS/2, proprietary cables) with a single standard. Since USB 1.0 in 1996, it has become the dominant interface for PC peripherals, embedded debug interfaces, device charging, and mobile device connectivity. For embedded engineers, USB most often appears as a DFU (Device Firmware Upgrade) port, a virtual serial port (CDC-ACM) for debug output, or a HID interface for bootloaders and configuration tools.

Host-centric topology

USB is inherently host-centric. The host (PC, hub, or OTG host device) controls all bus transactions — it schedules when each device may transmit and polls devices at defined intervals. Devices never initiate transactions unprompted; they only respond when the host addresses them. This makes USB simpler to implement than a peer-to-peer bus like Ethernet, but means the PC driver determines much of the user-visible behaviour.

The physical topology is a tiered star: the host has one or more root hub ports, each of which connects to a device or an external hub. Hubs extend the topology up to five tiers deep. Each device connects point-to-point to its upstream port; devices cannot detect or communicate with each other.

Descriptor hierarchy

Every USB device describes its capabilities via descriptors returned during enumeration:

Device Descriptor: one per device. Contains USB specification version (bcdUSB), device class/subclass/protocol (if class is defined at device level), maximum packet size for endpoint 0, VID (Vendor ID), PID (Product ID), number of configurations.

Configuration Descriptor: one or more per device (though one is most common). Describes the power requirements (bMaxPower, in units of 2 mA) and whether the device is bus-powered or self-powered.

Interface Descriptor: one or more per configuration. Each interface represents an independent function — a USB audio device might have one interface for audio streaming and another for HID control. The interface class/subclass/protocol fields identify which USB class driver the host should load.

Endpoint Descriptor: one or more per interface. Each endpoint is a unidirectional data pipe. Endpoint 0 is a mandatory bidirectional control endpoint; additional endpoints carry bulk, interrupt, or isochronous data. Each endpoint has a defined type, direction (IN = device to host, OUT = host to device), and maximum packet size.

USB device classes

Rather than requiring custom drivers for every device, USB defines standardised device classes that use generic OS-provided drivers:

CDC-ACM (Communications Device Class, Abstract Control Model) is the most common choice for embedded devices: the device appears as a virtual COM port, allowing the host to use any terminal program (PuTTY, screen, Arduino Serial Monitor) to communicate with the embedded device over UART-like serial communication. No driver installation is required on Linux and macOS; Windows 10 and later include a native CDC-ACM driver.

USB 2.0 vs USB 3.x

USB 2.0 (2000) standardised High Speed (480 Mbit/s) using the familiar two-wire differential D+/D− bus. USB 3.x added a SuperSpeed channel using two additional differential pairs (SS TX+ / SS TX−, SS RX+ / SS RX−) routed alongside the USB 2.0 pairs in the cable, backward-compatible with USB 2.0 devices. USB Type-C connectors support USB 3.x, USB 2.0, and alternate modes (DisplayPort, Thunderbolt) on the same connector.

For most microcontroller-based embedded designs, USB 2.0 Full Speed or High Speed is sufficient. Full Speed (12 Mbit/s) covers CDC-ACM, HID, and DFU applications. High Speed (480 Mbit/s) is needed for bulk data transfer (audio recording, video capture, test instruments) and requires a High Speed capable USB PHY on the MCU (STM32F4xx, STM32H7, nRF52840).

USB power delivery

USB specifies maximum current from the host port depending on device configuration state:

• Unconfigured: 100 mA maximum (USB 2.0), 150 mA (USB 3.x)
• Configured: up to 500 mA (USB 2.0), 900 mA (USB 3.x), as declared in the configuration descriptor
• USB-PD (Power Delivery): negotiated via USB Type-C CC lines, supports up to 240 W (USB-PD 3.1)

Embedded devices must not draw more than 100 mA from VBUS before the host has read the configuration descriptor — doing so causes the port to current-limit and enumeration to fail. See STM32 DFU bootloader for an example of USB clock and power considerations in a microcontroller USB implementation.

Practical Examples

An STM32-based embedded controller uses USB CDC-ACM to present a virtual serial port to the PC for debug logging, parameter configuration, and firmware updates. The same USB port drives the DFU bootloader in the STM32 system memory for production programming. This eliminates the need for a separate USB-to-UART bridge IC and programmer connector — a single USB connector handles debug, configuration, and programming. See the forum discussion on STM32 USB not detected after bootloader jump for common USB enumeration issues in this scenario.

The nRF52840 uses USB Full Speed (12 Mbit/s) for MCUboot DFU updates and CDC-ACM logging. See nRF52840 USB and MCUboot DFU for hardware requirements (32 MHz crystal, series resistors, VBUS detection) and firmware implementation details.

Design Considerations

• USB clock accuracy: USB Full Speed requires a 48 MHz ±0.25% clock to meet the bit rate tolerance. This typically requires a PLL locked to a crystal — the internal RC oscillator on most MCUs is not accurate enough for USB FS. Confirm the USB clock source in the MCU clock tree.
• D+ pull-up: USB FS devices signal their presence to the host by pulling D+ high through a 1.5 kΩ resistor. On many MCUs this pull-up is integrated and software-controlled; on others it requires an external resistor. The pull-up must be enabled only after the USB stack is initialised — pulling D+ high during MCU boot before stack initialisation causes enumeration failures.
• VBUS detection: detecting VBUS (the 5 V USB power line) is required to know when a host is connected. Connect VBUS through a resistor divider to a GPIO or ADC input; threshold around 3 V. Many MCUs have a dedicated VBUS sense input.
• ESD protection: USB connector data lines are exposed to ESD. Add low-capacitance TVS protection (under 1 pF per line for High Speed, under 2 pF for Full Speed) on D+ and D− between the connector and the MCU.
• USB current draw at startup: comply with the USB specification's 100 mA unconfigured limit. Large capacitors on VBUS charge through the USB cable's impedance and can look like an overcurrent event. Soft-start or inrush-limiting may be required for designs with bulk capacitance on VBUS.

Common Mistakes

• Not handling USB disconnect and reconnect in firmware: if the USB cable is unplugged and re-plugged, the host resets enumeration. Firmware that does not properly handle the USB reset and re-enumeration sequence will leave the USB stack in a dead state until the MCU is power-cycled.
• Using the wrong USB class for your application: a custom CDC-ACM virtual serial port is the easiest choice but has throughput limits (typically under 10 Mbit/s effective). Applications requiring higher throughput should use USB Bulk transfer (Vendor class + libusb on the host side) for maximum bus utilisation.
• Incorrect VID/PID in the device descriptor: USB VID (Vendor ID) must be assigned by the USB Implementers Forum — using a VID that was not assigned to your organisation is a protocol violation and may conflict with other devices. For prototyping, USB-IF allows the use of shared development VID/PID allocations from vendors like FTDI or Microchip for non-commercial use.
• VBUS powering the 5 V rail without inrush protection: VBUS is nominally 5 V but can drop to 4 V under load. Directly powering a 5 V rail from VBUS without inrush limiting can trigger the host's overcurrent protection and prevent enumeration.