USB HID, CDC virtual COM port or vendor class: which should a custom device use?

CDC ACM, the virtual COM port, is the usual first choice. Windows 10 and later, macOS and Linux load their built-in serial drivers for it automatically, and the application just opens a serial port from any language or terminal program. Internally it uses bulk endpoints, so at full speed the data moves in 64-byte packets, and the theoretical ceiling is about 1.2 MB/s (up to 19 packets of 64 bytes per 1 ms frame); real throughput is lower but still ample for a few hundred kilobytes.

The baud rate setting is only a number passed to the device. There is no real UART, so data moves at USB speed whatever the application selects. The drawbacks are those of serial ports: the application has to find the right port, and the stream has no message boundaries, so you need your own framing and checksum.

HID needs no driver on any desktop system and no hunting for a serial port: the application opens the device by its vendor and product ID through the operating system's HID interface, and a library such as hidapi makes that portable. Data moves in fixed-size reports over interrupt endpoints. At full speed a report packet is at most 64 bytes and the endpoint is polled at most once per millisecond, so the ceiling is 64 kB/s in each direction.

That is fine for configuration and live readings but slow for bulk logs: 500 kB takes about 8 s at best. HID also requires a report descriptor; for a generic data pipe a short vendor-defined descriptor is enough. It is the natural choice if the device also behaves as a keyboard, mouse or game controller.

A vendor-specific interface gives the most freedom: your own bulk endpoints and protocol, accessed from the application with libusb. Linux and macOS allow that without a kernel driver. Windows needs the generic WinUSB driver bound to the interface, and the way to get that without an installer is to include Microsoft OS descriptors in the firmware that declare the device as WinUSB-compatible; Windows 8 and later then load the driver by themselves. It is a little more firmware work, but it gives a clean, driverless bulk pipe with proper packet boundaries.

Classes can also be combined. A composite device can expose, for example, a CDC port for a console plus a mass-storage interface that presents the log files as a read-only drive, which needs no application at all on the PC side.

Whichever class you choose, the device needs a vendor ID and product ID that are yours to use. The example IDs in a chip vendor's demo code are meant for development. For a product, either obtain a vendor ID from the USB Implementers Forum or use a product ID that the microcontroller vendor sub-assigns under its own vendor ID, if it offers such a programme. Operating systems cache driver decisions by VID and PID, so change the PID when you change the interface layout during development, or you will chase phantom problems.

For your logger, CDC is the least effort and fast enough. Choose the vendor interface with WinUSB if you want message boundaries and no COM port confusion, and HID only if transfers stay small.