Why have a UART to USB bridge?

[espmich]

Many Espressif devkits (ESP32-C6-DevKitC-1) include a UART USB bridge, usually the Silicon Labs CP2102N.

Most of the chips (ESP32-S3, ESP32-C3, ESP32-C6) in these devkits can support USB serial communication (standard USB CDC-ACM) easily without use of any other hardware, so it seems like adding a UART USB bridge IC is totally redundant.

Questions

What are the top reasons any hardware developer would add a UART USB bridge IC like the CP2102N to a custom device using a ESP32 MCU that can already support standard USB CDC-ACM?

Is it just to be able to set a custom VID and PID, is that the only benefit to adding a UART USB bridge IC?

Reasoning

I see that Mr @SpriteTM added a UART USB bridge (CH340C) to his PDP emulator custom hardware project, so there must be a good reason to do this. I wonder what would happen to his project if he tried to design it without the bridge chip? It doesn't seem like the bridge IC can support HID or MSC.

[Sprite]

I see that Mr @SpriteTM added a UART USB bridge (CH340C) to his PDP emulator custom hardware project, so there must be a good reason to do this.

There is. That project is based on the original ESP32, which didn't have an integrated USB-JTAG-serial device yet (that came with the -C3 and -S3). For later projects where I don't use the original ESP32, you'll see I've switched to using the internal USB-serial-JTAG as well.

For why there is a separate USB-to-serial chip on some boards, there's a few reasons:

- For the -S3, if you want to use USB-OTG, it also occupies the USB port. Having a separate USB-serial chip allows you to debug the chip even with the 'main' USB port occupied.
- For the -C series of chips: As the USB-serial-JTAG device is part of the chip, it'll not work if you enable some sleep modes (e.g. deep sleep). In that case, it can be more practical to use an external chip, as that USB connection will stay alive even if the ESP is in deep sleep mode
- For the older devboards: it took us a while to fully trust the USB-serial-JTAG implementation to the point that we wanted to solely rely on it, so we added it as a backup option. By now, it's mature enough, so that's not really a reason anymore, but still, old habits die hard.