STM32 VCP Throughput

[Pack34]

A VCP works by simulating a serial port between the PC and the ARM chip. As for throughput of this link, is it limited by the virtualized baud rate or is it capable of handling the full USB 1.0 spec of 12 MBit/s?

I'm working with some older code that I'm attempting to revise. There's odd glitches on the USB (drops out) and I'm considering switching to a VCP if the throughput doesn't take a hit.

I could be completely missing it, but I'm not seeing anything in the firmware that's limiting the COM to a specific baud.

[JPortici]

The data is always being sent/received at the highest speed possible, regardless of the "baud rate", which by the way isn't or shouldn't be defined at all on the usb driver

[Jeroen3]

VCP is a byte stream. For maximum throughput you should go block based, such as mass storage.
Most of the time a VCP implementation is limited because data is handled char-by-char. (on the host side)

[Harvs]

Keep in mind that the 12Mbps is the bit rate, and you loose quite a bit with USB FS framing.  I spend a bit of time optimising a Mass Storage device on STM32 the other day and couldn't get much more than about 700kBs through it, which I've since learnt is typical.

[MosherIV]

Hi

It has been over 2 years since I last worked on STM32 and the STM libraries.

Be aware that the ST library for USB has bugs which hang or loose bytes when the USB data layer is really busy.

[Pack34]

Hi

It has been over 2 years since I last worked on STM32 and the STM libraries.

Be aware that the ST library for USB has bugs which hang or loose bytes when the USB data layer is really busy.

Can you define "really busy"? This could be exactly what I'm seeing.

Were you able to find a workaround for that or just deal with the "blip" as gracefully as possible?

[MosherIV]

If I remember correctly, the ST provided USB driver interfaces to the VCP driver, the USB driver is suppose to empty the USB buffer into the buffer in the VCP driver but there is a problem with the state machine of the USB driver so that bytes could be missed or over written in the VCP buffer.

[Scrts]

Any issues with the HID solution then? What's available throughput in HID case?

[varghese]

You cannot achieve 12Mbps , reasons
1. 12Mbps is bit rate not the actual data transfer rate , actual data transfers along with overhead bits . like CRS stuffs
2. so called 12Mbps is shared with other devices..
3. USB transfers packet by packet , so keep the packet size as high as possible for every IN/OUT transaction , but remember this will introduce heavy latency ..
4. USB 1.0 /USB 2.0 full speed Single packet transfer time is 1ms ,USB Scheduler /OS side Windows/Linux  will have 1ms scheduler , but you cannot possibly able to get 1000transfers /Sec ,I did some research on this , most probably you could get 600 to 800 transfer per sec.. again it depends on USB host , which is out of our hand ..
3."USB 2.0High speed generates" 1/8 ms ,practically somewhere between 5000 to 6000 packets per sec is possible ..

my advice is , while designing any USB based device ,consider these timings , hardware buffers .. or else software guys  will cry ..

[hans]

On the USB level there is no concept of serial baud rate. Transfers of data go via endpoints that are read and written by the host. The device should serve these endpoints via the protocol as quick as it can, so they are available to the host again (on device you hand them back to hardware usually). In terms of speed probably 700-900kB/s peak is normal for a 12Mbit/s connection, assuming you can process the buffers quick enough. If you do more processing, it's slower. In addition, if you only transfer 1-byte long USB frames, you will likely only reach 10-20kB/s, because overhead.

After you received the data, it's a choice of what you want to do with it. If you process in software, the baudrate value is completely meaningless. Many VCP can be opened with any baud, it doesn't matter.
If you have a hardware peripheral connected (e.g. a real UART), then you probably will want to buffer the data for that UART additionally, and should stall the USB endpoint at the point you cannot continue writing data to that buffer. If the endpoint is stalled the host cannot write data to it, and effectively will limit the data throughput for the USB device

[MosherIV]

hans post has started to remind me what the issue with VCP is.

The end point code that ST provide is interrupt driven. When the data comes over USB, the packet trigger the ISR to run.
The ISR will check if there is room on the VCP driver buffer to transfer the data into the VCP buffer.

One of the problems is that there is only 1 buffer for Tx and Rx in the VCP driver.
It is possible that the VCP driver thinks it is transmitting when a USB packet comes in and the USB end point ISR will corrupt the VCP buffer.

I put some extra guards in to protect the VCP buffer, so that it can only transmit or receive but not both.
I did not want to add seperate Tx and Rx buffers because that would mean more changes in the USB end point code and it is bad enough as it was 

[Pack34]

hans post has started to remind me what the issue with VCP is.

The end point code that ST provide is interrupt driven. When the data comes over USB, the packet trigger the ISR to run.
The ISR will check if there is room on the VCP driver buffer to transfer the data into the VCP buffer.

One of the problems is that there is only 1 buffer for Tx and Rx in the VCP driver.[\b]
It is possible that the VCP driver thinks it is transmitting when a USB packet comes in and the USB end point ISR will corrupt the VCP buffer.

I put some extra guards in to protect the VCP buffer, so that it can only transmit or receive but not both.
I did not want to add seperate Tx and Rx buffers because that would mean more changes in the USB end point code and it is bad enough as it was 

Now that's a hearty tid-bit of information I did not know! That seems like a very logical reason for the intermittent issues that I've been seeing.

The general Tx/Rx process on the device is that every acquisition cycle, it will send a DMA request, and while it's waiting it will poll status information from the device. I could definitely see the event when a DMA reply could be happening at the same time as a standard request.

Unfortunately, this could be something I have no control over, but I could absolutely put together a sample application with a better cadence by polling information, DMA, wait, then the next batch. And then be sure that there's proper timing constraints for the scheduler.

I'm glad I chirped up and asked!