alternatives to USB virtual serial / COM port for PC <-> uC USB communication? - Page 1
Forum section: electronics / projects

author: Chendy
author_rank: Contributor
timestamp: April 18, 2016, 03:18:20 pm
content: 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 appreciatedChendy

author: Kilrah
author_rank: Unknown
timestamp: April 18, 2016, 04:22:40 pm
content: Welp...Quote from: Chendy on April 18, 2016, 03:18:20 pmIf 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.

author: zapta
author_rank: Super Contributor
timestamp: April 18, 2016, 04:37:06 pm
content: 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?

author: Jeroen3
author_rank: Super Contributor
timestamp: April 18, 2016, 04:47:31 pm
content: QuoteUSB Hid is what you are looking for.

author: _Wim_
author_rank: Super Contributor
timestamp: April 18, 2016, 06:51:50 pm
content: Quote from: Jeroen3 on April 18, 2016, 04:47:31 pmIt 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_WindowsI have used this framework in the past, and it works perfectly. Really recommended if you want to get your feet wet into USB HID...

author: Scrts
author_rank: Frequent Contributor
timestamp: April 18, 2016, 07:04:33 pm
content: Maybe it's worth looking for the smallest microcontroller with USB support to put something together as an open source and newer than PIC18F?

author: stmdude
author_rank: Frequent Contributor
timestamp: April 18, 2016, 07:06:16 pm
content: 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 sideThe 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 uCThird, 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.

author: Kilrah
author_rank: Unknown
timestamp: April 18, 2016, 07:08:13 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: April 18, 2016, 07:19:29 pm
content: 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.

author: stmdude
author_rank: Frequent Contributor
timestamp: April 18, 2016, 07:51:09 pm
content: Quote from: Kilrah on April 18, 2016, 07:08:13 pm??Quote from: Chendy on April 18, 2016, 03:18:20 pmPretty sure he did..

author: _Wim_
author_rank: Super Contributor
timestamp: April 18, 2016, 08:24:28 pm
content: Quote from: stmdude on April 18, 2016, 07:51:09 pmWhy would you think that?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 18, 2016, 09:04:57 pm
content: 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.

author: Chendy
author_rank: Contributor
timestamp: April 22, 2016, 10:40:33 am
content: 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

author: stmdude
author_rank: Frequent Contributor
timestamp: April 22, 2016, 03:04:38 pm
content: Quote from: Chendy on April 22, 2016, 10:40:33 amYep, 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 23, 2016, 01:47:29 pm
content: Quote from: Chendy on April 22, 2016, 10:40:33 amFTDI'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.