What are USB device classes and name the common ones used in embedded systems?

USB device classes are standardized specifications published by the USB-IF (Implementers Forum) that define the protocol and behavior for categories of devices. When a device declares a recognized class code in its interface or device descriptor, the host OS can load a built-in class driver — no vendor-specific driver installation is required. This is why you can plug a USB keyboard or flash drive into any computer and it works immediately.

The most commonly used classes in embedded systems are: CDC (Communications Device Class, class code 0x02) — used to implement virtual serial ports (CDC-ACM subclass). This is the go-to class for embedded developers who need a simple debug/command interface between an MCU and a PC. The host sees a COM port (Windows) or /dev/ttyACM device (Linux), and firmware sends/receives data through bulk endpoints. CDC requires two interfaces (a communication interface with an interrupt endpoint for notifications, and a data interface with bulk IN and bulk OUT endpoints). HID (Human Interface Device, class code 0x03) — originally designed for keyboards and mice, HID is widely used in embedded for any low-bandwidth bidirectional communication that needs to work without driver installation. HID uses interrupt transfers and report descriptors that define the data format. Custom HID devices can send up to 64 bytes per report at full-speed, making them suitable for sensor data, configuration tools, and firmware update utilities. MSC (Mass Storage Class, class code 0x08) — makes the device appear as a removable disk drive. Used in embedded systems for data logging (expose an SD card as a USB drive), firmware update (user copies a binary file to the "drive"), and configuration file exchange. MSC uses bulk transfers and the SCSI transparent command set (BOT — Bulk Only Transport).

Other classes encountered in embedded: Audio (0x01) for USB microphones and speakers, Video (0x0E) for USB cameras, DFU (Device Firmware Upgrade) for in-field firmware updates via USB, and Vendor Specific (0xFF) when no standard class fits and you provide your own host driver. The key interview point: using a standard class eliminates the need for custom host drivers, dramatically simplifying deployment and cross-platform support.