USB (Universal Serial Bus) is a host-centric, hierarchical serial bus standard originally designed to replace the tangle of legacy PC peripherals ports, now widely adopted in embedded systems for device-to-host communication, firmware updates, and power delivery. It defines several speed grades -- low-speed (1.5 Mbps), full-speed (12 Mbps), high-speed (480 Mbps), and USB 3.x SuperSpeed (5 Gbps and above) -- along with a layered protocol stack, standard connector types, and a class system that enables driver-free operation for common device categories.
In practice
Most MCU-class USB peripherals implement full-speed (12 Mbps) or, on higher-end parts, high-speed (480 Mbps) using an external or embedded PHY. Common device classes used in embedded work include CDC-ACM (virtual COM port), HID (keyboard/mouse/gamepad/custom), MSC (mass storage), DFU (device firmware upgrade), and vendor-specific classes. CDC-ACM is particularly popular during development because it appears as a serial port on the host with no custom driver, making it easy to pipe debug output or a command shell over USB. Parts like the STM32F4, STM32H7, NXP LPC55S, Microchip SAM D21/D51, and nRF52840 include on-chip USB peripherals; many 8-bit and lower-end 32-bit MCUs do not, requiring an external USB bridge chip if USB connectivity is needed.
The USB protocol is host-driven: the host initiates all transactions, and the device only responds. This polling model means a device cannot spontaneously push data; it must stage data in endpoint buffers and wait for the host to request it. Developers new to USB often expect a UART-like "send when ready" model and are surprised by latency or throughput inconsistencies caused by host polling intervals, especially for interrupt and bulk endpoints.
USB enumeration -- the sequence in which the host discovers, identifies, and configures a device -- is a common source of bring-up headaches. The host requests descriptors (device, configuration, interface, endpoint, string) and must receive well-formed responses within defined timing windows; the exact tolerances vary by host implementation and USB speed mode. Errors in descriptor tables, incorrect endpoint configuration, or missed timing constraints cause silent enumeration failures. USB protocol analyzers (hardware or software-based, such as Wireshark with a USB capture backend) are invaluable here. Many MCU vendor SDKs and middleware stacks (STM32 USB Device Library, TinyUSB, Zephyr USB stack) provide pre-built descriptor templates to reduce the risk.
Power delivery is a practical concern in embedded designs. A USB 2.0 bus-powered device may draw up to 100 mA before enumeration and, after successful configuration, up to 500 mA if the host grants that allocation -- though actual limits depend on the host or hub port policy and the device's declared power requirements. USB-C and USB PD (Power Delivery) extend this significantly, allowing up to 100 W (20 V / 5 A) in some profiles. Many modern MCUs and companion ICs integrate USB PD controllers or BC1.2 (Battery Charging) detection to negotiate higher charge currents without full USB enumeration.
Discussed on EmbeddedRelated
Frequently asked
What is the difference between USB full-speed and high-speed, and how do I know which my MCU supports?
Full-speed runs at 12 Mbps and uses a simpler analog front-end that can be integrated directly into most
MCU I/O processes. High-speed runs at 480 Mbps and requires a dedicated UTMI or
ULPI PHY -- either embedded on-chip (as on the STM32H7 or NXP i.MX RT series) or external (connected via the ULPI bus). Check your MCU datasheet for 'USB FS' vs. 'USB HS' peripheral blocks. Some devices (e.g., STM32F4xx) have both: one FS-only core and one HS core that can operate in FS mode without an external PHY.
What is CDC-ACM and why is it so commonly used in embedded projects?
CDC-ACM (Communications Device Class -- Abstract Control Model) is a USB device class that emulates a serial (COM) port. The host OS loads a built-in driver -- no custom INF or kernel module needed on Linux, macOS, or modern Windows -- and the device appears as a virtual
serial port. This makes it a convenient drop-in replacement for a UART-to-USB bridge chip during development. Throughput is limited by USB full-speed bandwidth and host polling, but it is more than adequate for debug consoles, logging, and low-rate data transfer.
My USB device enumerates on one PC but not another. What should I check?
Enumeration failures across hosts are often caused by: (1) descriptor errors that a lenient host tolerates but a strict one rejects -- validate descriptors with a USB analyzer or 'usb-descriptor-validator' tools; (2) timing violations in the device's response to setup packets; (3) current draw exceeding what the host port reports as available; (4) cable quality -- passive USB 3.x cables can have degraded USB 2.0 lines. Start by capturing USB traffic with Wireshark (usbmon on Linux or USBPcap on Windows) to see exactly where enumeration stalls.
Can I implement USB without a dedicated USB peripheral in my MCU?
Low-speed (1.5 Mbps) USB has been bit-banged on AVR and other MCUs using projects like V-USB, which relies on carefully cycle-counted firmware and specific I/O voltage levels; V-USB is device-only and requires meeting tight voltage and timing constraints that not all AVR or
MCU configurations can satisfy. Full-speed (12 Mbps) bit-banging is generally not feasible on typical 8/16-bit MCUs due to the timing precision required. If your MCU lacks a USB peripheral and you need USB, the practical approach is an external USB bridge chip (e.g., an FTDI FT232, WCH CH340, or Microchip MCP2221) connected via
UART or
SPI.
What is USB DFU and how is it used for firmware updates?
DFU (Device Firmware Upgrade) is a standard USB device class (defined in the USB DFU specification) that provides a host-side protocol for downloading new firmware into a device and optionally uploading its current firmware. Many STM32 parts have a factory-programmed DFU
bootloader in ROM, reachable by asserting BOOT0 at reset, which allows programming via the 'dfu-util' command-line tool without a hardware
debugger. Custom application-level DFU can also be implemented using runtime DFU, allowing firmware updates from within the running application.
Differentiators vs similar concepts
USB is often compared to
UART/
RS-232 because CDC-ACM makes USB appear as a serial port to the host. The key differences: USB is host-centric (the host polls; the device cannot initiate), hierarchical (up to 127 devices on one bus via hubs), and defined by a layered
stack with enumeration, classes, and endpoint types. UART is peer-to-peer with no defined transport layer or device model. USB also has defined connector and power delivery contracts; UART has none. USB should not be confused with USB-C, which is a connector standard that can carry USB 2.0, USB 3.x, DisplayPort, Thunderbolt, and USB PD -- the connector and the protocol are distinct. USB 3.x is also distinct from USB 2.0: they share backward-compatible USB 2.0 signaling on connectors such as standard-A and USB-C, but USB 3.x adds separate SuperSpeed differential pairs and a different physical and link layer; exact pin usage varies by connector type.
