What are you using to interface with microcontrollers?

[bk81]

I recently tried a couple hobby projects that needed a computer interface.  This is the first time I have tried such a thing since RS232 ports were common.  Interfacing to computers has become vastly more complicated now that the only thing available are USB C ports!   

One project used a PIC24F and the Microchip supplied USB CDC interface.  The other had a USB interface to a PIC32MZ using the Microchip supplied Harmony bulk endpoint framework.  On the client side for both I used USB4Java and Java 1.8.  Going to a newer Java release would have required recompiling USB4Java.

Everything worked eventually, but I feel like there might have been a much better solution.  Different microcontrollers, different tool chains, better USB libraries, whatever.  USB4Java has also been abandoned and hasn't been recompiled for Apple silicon. 

Is there an easier solution that runs on OS X and allows a few MB/s to be transferred and processed on the host side? 

[kripton2035]

each time it's possible, I use an ethernet or wifi interface. it is the simpliest even if not available to any microcontroller.
usually esp8266 or esp32 are my goto devices.

[Smokey]

One advantage of the UART<->USB chip is that as long as the board stays powered up, the CDC virtual serial port on the computer will stay connected even if the uC resets. 

It's sort of a pain, especially during development/programming cycles, that the computer CDC port disconnects/reconnects every time with native uC USB CDC.

[Peabody]

The standard wired communications option in the Arduino world is a USB-to-UART adapter using the FT232RL:

https://www.ebay.com/itm/256072581134

It requires a driver at the computer end, but in Windows it shows up as a COM port.  Don't know about Apple.  The adapter can also provide power to the microcontroller, and has a jumper to set 3.3V or 5V.  These work quite well, but baud rates are limited to about 115,200 I think.

[nctnico]

I use USB-CDC together with a command line interpreter which can also be used to implement SCPI style control. On the PC side I let the software scan all COM ports until it finds the device it intends to control so the user doesn't need to bother filling in the right COM port. If the connection is lost, then the software retries until the port is there again.

[djacobow]

You can do an awful lot with just the FTDI part and no microcontroller at all. For example, you can put them in gpio mode or i2c mode or SPI. Despite my misgivings about FTDI, their parts are pretty neat.

At work I have used 4232's to make some very flexible debug hardware without much effort.

[SiliconWizard]

One advantage of the UART<->USB chip is that as long as the board stays powered up, the CDC virtual serial port on the computer will stay connected even if the uC resets. 

It's sort of a pain, especially during development/programming cycles, that the computer CDC port disconnects/reconnects every time with native uC USB CDC.

When using a UART for debugging purposes, I concur 100%
I have a few UART to USB isolated adapters, that come in handy for just about everything like this. No need to add this to your board. The isolation is a plus, and gives level shifting for "free". They also expose RTS and CTS, which can be handy for some applications.
(Not affiliated in any way, but that's what I have: https://www.tindie.com/products/saimon/debug-board-usb-to-uart-isolated-with-flow-control/ , but they also have versions without flow control.)

[PlainName]

For isolated debugging I sometimes use a HC04/5/6 to do serial over Bluetooth:

https://www.ebay.co.uk/itm/155669533099

Your PC need BT, of course, but which one doesn't nowadays.

[bk81]

Thanks for the responses!  There's lots of good ideas here I hadn't looked into.   The Espressif parts with wifi look really interesting.

[Andy Chee]

Asynchronous serial still seems pretty common theme for debugging interfaces, regardless of whether the USB-serial chipset is Future Technologies FTD232, Prolific PL2303, or SiLabs CP2102.  YMMV if you get stung by counterfeit versions each.

Bluetooth over serial using a HC05 module is certainly an easy option for an isolated interface.  Normally you pair the HC05 directly to your PC's bluetooth.  But you can also pair a HC05 with second HC05 to make a transparent wireless serial cable.

Finally, some Zigbee modules also contain a serial pass through interface, which can also be used to create a transparent wireless serial cable.

[hans]

Debuggers are often mildly useful, because they halt a program which usually must run real-time.

UART is still pretty common for console, logging or tracing etc. I often use the latter. Console/logging in my view is printing human-readable text over serial so you can see whats going on. This often includes the use of printf() and whatnot, which is often quite slow. For faster routines, you could also use tracing libraries. Segger has SystemView using RTT transport, or you could roll your own library. I did the latter as its integrated in my build system capturing trace messages and then performing the printf on the host machine. The buffer can either be transmitted via an UART or via a debug probe (e.g. RTT).

If tracing is still problematic, then a last resort could be to use a SPI bus at max bitrate, and send individual data bytes for debugging, and trace+decode them with a scope/LA. You could use GPIOs to sync up to the serial stream. Its far more invasive form of debugging, but if you need to trace data from a very short IRQ, it may be the only viable way to do it.

I never bother with USB CDCs for debugging. Perhaps for field diagnostics (such as a serial console with hidden commands), but other than that I would only use USB CDCs for the operational aspect of a board.
Its far easier to use one of the many dozen USB-UART converters (the high-speed FTDI chips can do 12Mbaud+).

[NiHaoMike]

If you need many ports, the Raspberry Pi Pico can be programmed to provide 6 of them. What I would like to see is a version of the firmware that also offers I2C and SPI.

The standard wired communications option in the Arduino world is a USB-to-UART adapter using the FT232RL:

https://www.ebay.com/itm/256072581134

It requires a driver at the computer end, but in Windows it shows up as a COM port.  Don't know about Apple.  The adapter can also provide power to the microcontroller, and has a jumper to set 3.3V or 5V.  These work quite well, but baud rates are limited to about 115,200 I think.

Official Arduino stopped using FTDI long ago, instead they switched to a second microcontroller programmed to perform that function.

[Smokey]

...
Official Arduino stopped using FTDI long ago, instead they switched to a second microcontroller programmed to perform that function.

... This sometimes leads to a bizarre situation, where the dedicated USB<->UART uC is actually more powerful than the application processor on the Arduino board.

[tooki]

It requires a driver at the computer end, but in Windows it shows up as a COM port.  Don't know about Apple.

They show up as a standard serial port on the Mac (as /dev/ttysomething, with the something being the name of the bridge device). Same as Linux. A driver may or may not be needed, depending on the OS version and device.

[amwales]

I use the CH430 USB-to-UART, chips are very cheap https://www.lcsc.com/search?q=ch340

[thm_w]

CH340 and HC05 are not fast enough, and OP is not talking about debugging, come on guys:

"Is there an easier solution that runs on OS X and allows a few MB/s to be transferred and processed on the host side?"

[djacobow]

I'm going to repeat myself, but most  FTDI parts have a thiing called MPSSE (Multi-Protocol Synchronous Engine) that lets them support synchronous protocols at high speed. So, in addition to being a UART, they can do SPI, JTAG, and other protocols quite fast. You can access this mode from C, but there are also python drivers that make it easy. This lets you build all sort of things with off-the-shelf FTDI breakout boards. I actually have a design at work where we use one chip to do SWD programming over OpenOCD, SPI access to a flash chip, i2c access to various thingies, and have UART left over for regular serial console. It's a nice solution and I'm glad I have it rather than writing software for another target just to do debug.

[PlainName]

... and allows a few MB/s to be transferred and processed on the host side?"

Mea culpa. I read that as MB's rather than literally tens of MBps.

Nevertheless, I stand by the HC0x in the context of the post I replied to