USB to UART bridge similar to the MCP2221

[shaunmulligan]

Would it be possible to implement a USB-to-UART bridge that shows up on USB-CDC similar to how the MCP2221a has the USB-HID and USB-CDC which maps the TX and RX pins to /dev/ttyACM0 on your laptop?

I found this project https://github.com/Noltari/pico-uart-bridge but I would like to combine that functionality with the u2if firmware.

[ericwertz]

So, I just got here and am trying to figure out how all of this works.

I think that the problem with your proposal is that it only preserves the HW/SW interface (USB HID/CDC) to the software on the PC side, but only offers a UART interface to the MCU, and not USB HID/CDC. As such, the C++ blob that gets loaded on the Pico side would have to be re-shimmed to expect UART I/O rather than I/O through the USB endpoints. This implementation is locked into USB for both the HW interconnect as well as the USB datapipes (HID and CDC), and not the more generic/ubiquitous serial data stream that most communication for tasks like this is built on.

I came here trying to find out why plain 'ol serial wasn't used rather than USB_xx as a design choice. The former is so generic as to run anywhere, whereas this solution requires a USB electrical interface plus either a USB peripheral, or something bit-banging it like TinyUSB plus some custom USB-specific interface hardware (IDK, maybe just termination resistors?).

I was hoping to figure out the rationale for locking this solution into USB on the MCU side rather than just using UART/serial. I only had two guesses, either performance or the some of the conveniences that USB gives you when trying to identify what's on the other end of the wire(s). I suppose also that by not tying-up perhaps the only hardware UART present on some platforms, you still have the UART available to talk to native MCU hardware that wants hardware serial (versus SoftSerial).

Other than those reasons, I'm at a loss to know what the design decision rationale was here to lock both sides to a USB interface when ultimately all you need is ultimately a byte stream. I would understand it if the goal were to turn any conceivable sensors into a faux-HID devices, but that's clearly not the intent here. I'm also confused why the MCU side isn't portable (as much as can be done in practice) in Arduino, but in PicoSDK.

So, in short, I'm confused here - there's gotta be something big here that I'm missing. If anyone knows, I'd be grateful to know. I was hoping that this was something that would work with non-Pico hardware (like the AF CPX), but it's clear that that wasn't a goal. Maybe the answer is that the Pico is just so attractive at $4 that there's no excuse to use anything else...?!?

regards