alternatives to USB virtual serial / COM port for PC <-> uC USB communication?

[Chendy]

Hi gang,

Apologies my terminology is probably wrong...

Im wondering if there is anything better than using the ubiquitous virtual serial port? The goal is to communicate between a chrome browser using the serial api and a USB microcontroller, but be cross platform without drivers.  There are many USB classes that are supported by the operating system (linux / Mac / Windows), virtual serial port is one such example.

But is there anything similar that might have perhaps better performance? Perhaps typical driver implementations might have shorter poll times? or uses a different USB mechanism (virtual serial/COM uses 'BULK' endpoints)? or otherwise somehow allow higher data rates or lower latency or more reliability???

Any tips appreciated

Chendy

[Kilrah]

Welp...

The goal is to communicate between a chrome browser using the serial api and a USB microcontroller

If you want to use the serial API, you've got no choice but to use a virtual COM port.

You could make your device report as an HID instead.

[zapta]

The bottleneck would be Chrome, that is, what does Chrome allows you to access. Than you can make your device matching Chrome's requirements.

What does Chrome allow to access, serial port?  USB file system? anything else?

[Jeroen3]

but be cross platform without drivers.

USB Hid is what you are looking for.

[_Wim_]

USB Hid is what you are looking for.

It could indeed be an alternative, but I am not sure if it actually has better performance. And it add a lot of complexity in your software.

What I do like about it, is that there can be no confusion between com ports (because you device is uniquely identified by a PID and VID. A good starting point (if you are into PIC's) is this site: http://www.waitingforfriday.com/index.php/Open_Source_Framework_for_USB_Generic_HID_devices_based_on_the_PIC18F_and_Windows

I have used this framework in the past, and it works perfectly. Really recommended if you want to get your feet wet into USB HID...

[Scrts]

Maybe it's worth looking for the smallest microcontroller with USB support to put something together as an open source and newer than PIC18F?

[stmdude]

Pretty sure HID wouldn't give you very good bandwidth.

In my experience, the absolute best bandwidth is accomplished with a custom USB class, implementing BULK EPs in both directions. I've pushed 200+ Mbps over such links between SoCs and PCs.
Downside: You'll need to write drivers (or implement it with libusb/winusb) for the PC side

The next best thing, when it comes to bandwidth and compatability, would be CDC-ECM. Works without drivers in Linux, Windows and OSX.
Downside: You'll need an IP-stack on the uC

Third, is good old CDC-ACM (aka, serial port). You get decent performance over CDC-ACM, however, most vendor implementations are quite slow, so you'll need to spend some time tuning it for performance if that's critical.
I've run CDC-ACM at about 60Mbps, so it's not inherently slow.

As for interfacing with a browser, depending on how user-friendly it needs to be, you could probably implement SLIP or PPP over the serial link, but you'll need an IP stack on the uC again..  And then you might be better off with CDC-ECM anyways.

[Kilrah]

Nowhere did he mention high bandwidth or performance was needed, only the "no custom driver" requirement.

Could simply be for sending a few configuration bytes back and forth and there HID fits the bill pretty well. Need more info from OP.

[nctnico]

If it needs to be cross-platform then serial port CDC is the way to go. Nowadays even Windows (Windows 10) caught up after 15 years so serial port gadgets finally work out of the box.

[stmdude]

Nowhere did he mention high bandwidth or performance was needed, only the "no custom driver" requirement.

??

But is there anything similar that might have perhaps better performance? Perhaps typical driver implementations might have shorter poll times? or uses a different USB mechanism (virtual serial/COM uses 'BULK' endpoints)? or otherwise somehow allow higher data rates or lower latency or more reliability???

Pretty sure he did..

[_Wim_]

Nowhere did he mention high bandwidth or performance was needed, only the "no custom driver" requirement.

??

But is there anything similar that might have perhaps better performance? Perhaps typical driver implementations might have shorter poll times? or uses a different USB mechanism (virtual serial/COM uses 'BULK' endpoints)? or otherwise somehow allow higher data rates or lower latency or more reliability???

Pretty sure he did..

Why would you think that? 

[mikeselectricstuff]

FTDI's D2xxx API for their USB-serial and parallel devices works well, and can do decent speeds, though you do need to take care with packet sizes for max throughput.
You can easily keep multiple 4Mbaud ports pretty much saturated.

[Chendy]

Hi gang,

thanks for all the responses...

no I dont need to use a COM port, just something supported by chrome. So yes, USB HID is supported by Chrome it seems.

Sorry if I didn't explicitly state what my goals were, whether high bandwidth or ??:
Yes, high bandwidth is welcome...
... And/or lower latency
... higher poll rate / responsiveness
... Or higher reliability... less connection issues...
... as well as any other features that may be beneficial. E.g. identification via VID and PID as opposed to chasing around serial ports, mentioned above.

OK, so USB HID is perhaps worth exploring, but which sub-class?

stmdude suggests CDC-ECM, at the expense of the IP-stack.

And also that CDC-ACM can work well. Im guessing most of the tuning is on the MCU end, as only the baud rate, parity_bit, stop_bits, bufferSize can be changed by the PC application without drivers. Any tips?

mike rekons mulitple 4Mbaud doable with FTDI, but that seems custom driver stuff right?

nctnico suggests for cross platform CDC-ACM is the way to go, which is what I suspected.

My current plan is to use an Arm MCU (STM32F042G4)

cheers

[stmdude]

And also that CDC-ACM can work well. Im guessing most of the tuning is on the MCU end, as only the baud rate, parity_bit, stop_bits, bufferSize can be changed by the PC application without drivers. Any tips?

Yep, it's all tuning on the MCU side. It's pretty much down to keeping the buffers filled when you need them, and quick turnaround in the IRQ handlers. DMA needs to be utilized, unless you can dedicate most of your CPU-time to just USB comms.
The STM32 should suffice. It has nice configurable DMA engines which can be utilized for the USB periph block.

Also, baud-rate is not really relevant in this context. Basically, baud-rate is just a setting that's passed from the host to the MCU, telling it how quickly the async RS232 port should clock out the data. Since you don't use an actual RS232 port, you can go however fast you please, even if windows/linux/osx/whatever thinks you're running 9600baud.

[mikeselectricstuff]

mike rekons mulitple 4Mbaud doable with FTDI, but that seems custom driver stuff right?

FTDI's driver, which is included as standard with Windows, not sure of others.
However if you want to have your own VID/PID to make it look like a more customised device, you need a tweaked version, which has got more fiddly now that signing is more enforced.