CDC, the Communications Device Class, makes the MCU appear to the host as a virtual serial (COM) port, so the PC sees a COMx or /dev/ttyACM0 device and applications talk to it exactly like an old UART/serial port. The huge benefit is that CDC is a standard class with drivers built into every modern OS, so the device works with no custom driver to write, sign, or install, you get UART-like simplicity (open a port, read/write bytes) over a USB connector, without a separate USB-to-serial cable or chip. For firmware, a USB stack's CDC class reduces your application code to "send these bytes / here are received bytes" while the stack handles enumeration, descriptors, and endpoint management. This is why so many dev boards and instruments expose a USB virtual COM port for logs, configuration, and command interfaces. More broadly, choosing any standard class (CDC, HID, MSC) that the OS already supports avoids the cost and friction of a custom host-side driver, which is a major reason to design to a standard class rather than a vendor-specific protocol when you can.
Communication Protocols · Interview question
Why do MCUs usually implement a USB "CDC" device, and what's the benefit?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
USB Basics
Host-controlled, self-describing, and far more complex than UART: enumeration, descriptors, endpoints, and the four transfer types, plus device classes like CDC that need no custom driver.