USB device mode vs USB host mode — which does a typical MCU implement and why?

The vast majority of MCUs implement USB device mode only. In device mode, the MCU acts as a peripheral that is discovered, enumerated, and controlled by a host (typically a PC, laptop, or smartphone). This is the natural role for an embedded system — when you plug your custom sensor board into a laptop, the MCU is the device and the laptop is the host. Device mode requires significantly simpler hardware and software: the MCU's USB peripheral contains a Serial Interface Engine (SIE) that handles the low-level protocol, a set of endpoint buffers, and transceiver logic. The firmware responds to host requests rather than initiating them.

USB host mode is far more complex because the host is responsible for all bus management: detecting device connections, issuing resets, running the enumeration state machine, scheduling transactions across all connected devices, managing bandwidth allocation, handling hub topology, and providing bus power (VBUS at 5V, up to 500 mA per port). This requires a host controller (OHCI, EHCI, or xHCI), a device driver stack, and substantially more RAM for descriptor parsing and transfer management. Few MCUs include host-capable USB peripherals, and those that do (STM32F4/F7/H7, NXP LPC, some TI Sitara) are higher-end parts with more memory and processing power.

The practical consequence: if your embedded device needs to connect to a PC for data transfer, debug output, or firmware updates, you need device mode — and every MCU with USB supports it. If your embedded device needs to read a USB flash drive, connect to a USB barcode scanner, or act as a USB host for other peripherals, you need host mode — and you must select an MCU that specifically supports it, bring a USB host stack (like TinyUSB in host mode or the STM32 USB Host Library), and provide VBUS power circuitry. Host mode is uncommon in deeply embedded systems and more typical of embedded Linux platforms where a full USB stack is available.