# Is there a data transfer limit for virtual serial ports

I want to record 5/10 seconds of audio using an electret microphone and an STM32 nucleo development board and send it to my computer in real-time to be processed. I'm a beginner so I'm sure I'm making mistakes, but what limits the data transfer speed for a virtual serial port? I want to sample the audio at 48 kHz, at 12-bits per sample, which by calculation means I need a data transfer rate of 576 kb/s, is that possible via the virtual serial port? if not, is it possible at all with this board?

I have the STM32 nucleo-144 development board, I'm using mbed (https://os.mbed.com/platforms/ST-Nucleo-F746ZG/) and a electret microphone circuit (https://docs-emea.rs-online.com/webdocs/00af/0900766b800affa3.pdf)

• There is a buffer on the chip that converts the UART to USB. That chip itself also has a limit on how fast it can actually transmit the UART (obviously). I have a cable that can go up to 3MBps and another that's supposed to be able to go up to 12Mbps. However, I have had the buffer overflow on the 3Mbps cable when the transfer goes on for too long. – DKNguyen Oct 30 '19 at 17:08
• @jonk A virtual COM port is a HID device and it is NOT it is not the truth. Firstly VCOM is a CDC non HID class and it can archive a very high transfer rates – P__J__ Oct 30 '19 at 17:13
• @P__J__ My understanding comes only from reading USB 2.0. Can you refer me to the section which confirms what you are writing? I'd appreciate it. It's almost certainly my own confusion. – jonk Oct 30 '19 at 17:14
• Here is a question related to the CDC speed: stackoverflow.com/questions/44275560/… .. eventually one of the answers is from @P__J__ :) – Eugene Sh. Oct 30 '19 at 17:16
• @P__J__ For example, I find this in the documentation of one development board: "With the Virtual Com port Driver you can create a virtual COM-Port for your signature pad signotec Sigma, Omega or Gamma equipped with the connection method USB-HID, so that the device can be addressed via the serial interface." This is what I was thinking about. And they explicitly mention that 64 byte transfers are the limit in their own driver case. Note this is probably done to avoid installing O/S drivers. However, I do take your point as well and am very interested in your clarifying additions. – jonk Oct 30 '19 at 17:21

This is explicitly a "X-Y problem". You have a typical audio application. To implement the real-time data processing for the signal, you have two basic options:

1. Implement the most trivial and common and easy USB class - CDC (aka "virtual COM port"). To accomplish the overall data processing goal, you will need to invent a method/format to pack the electret mic ADC data into UART-type stream, then use a common Windows/Linux COM-port driver to buffer and store the data, and then to develop a proprietary application do deal with your proprietary format. The plus of this approach is that you control the raw data format and don't need to dig any specifications for the data stream. Minuses of this approach is that you will need to develop a lot of your own code.

2. Since this is an audio device, the formal solution is to implement the audio-class USB device within the Nucleo board. As I understand, there are code examples form STM development, see USB Audio device class on NUCLEO-F446RE and USB Audio device on Nucleo F446-RE with CubeMX. Advantages of this approach would be all well-established libraries in all known operating systems. Minus side is that you need to dig into audio specifications.

In all cases the bandwidth of USB (even in FS mode) is well sufficient for audio processing tasks.

Depending on the type of the USB peripheral it is limited to the 12MBPS (FS) or 480MBPS (HS). Both is enough for this task. On STM32F303 (FS USB) I am archiving a bit more than 1MB (bytes this time) continuous data throughput.

• The asker probably isn't using the target's USB port, but rather using its UART to proxy through the debugger on the board. If the want to go faster they should use the target USB connector rather than the debug USB connector but that means more software complexity. – Chris Stratton Oct 30 '19 at 18:23
• I agree. He says "virtual serial port" aka virtual COM port. – DKNguyen Oct 30 '19 at 18:24
• Either USB port could implement a "virtual com port", the issue is that the debug one has to go through a UART and the debug chips firmware, first. So it is less flexible in how you can use the virtual com port idea, since the implementation is basically fixed. – Chris Stratton Oct 30 '19 at 18:28
• @ChrisStratton if it is the ST-Link on the nucleo board the max it can achieve is 512kbps due to the stlink software limitations – P__J__ Oct 30 '19 at 19:23
• Can you point me in the direction of where to find out how to implement communication through the USB connector, (as in the one that isn't attached to the debug interface)? – A.Davies Nov 1 '19 at 19:06

This is a hard question, the theoretical limit would be the 480Mbit/s of the USB (because the STM32 nucleo has a phy on it), which is further reduced by the overhead of packets, which the overhead is a few percent. The other problem is how fast can the software send the data, and that is dependent on what other code is running on the processor.

USB FTDI chips can send data a ~3Mbaud so it's possible to send data at the speed that the design needs with a serial over USB link.

• what is the point of using external chips if you have built in peripheral? The other problem is how fast can the software send the data the problem with the HS is that hosts will not be able (especially Windows) to consume such a stream of USB CDC data. – P__J__ Oct 30 '19 at 17:51
• The F7's built in HS usb only works to 12Mbit in most (maybe all) models. If you want the full 480, you need a phy. I don't think any F7's have transceivers in them. The first problem would be sending data, It would be hard to get the F7 to spit out 480 even with a phy, and only sending random data. If you have to process the data, then send it, it wouldn't be able to fill the DMA buffer – Voltage Spike Oct 30 '19 at 17:52
• Some FTDI chips can handle 12Mbps, but yeah most seem to top out at 3Mbps. – DKNguyen Oct 30 '19 at 17:54
• @DKNguyen Actually 3Mbps for serial ftdichip.com/Support/Knowledgebase/… – Voltage Spike Oct 30 '19 at 17:55
• @VoltageSpike I think that's out of date. Check out the FTDI C232HD. It doesn't seem available in their RS-232/RS-422/485 cables though and I'm not sure why. Only their single-ended TTL cable. – DKNguyen Oct 30 '19 at 17:56

The easiest way how to implement the CDC

1. Install CubeMX
2. Create project for your micro.
3. Setup USB peripheral
4. Set in middlewares CDC class
5. Export project.
6. Enjoy