cancel
Showing results for 
Search instead for 
Did you mean: 

Can USB CDC receive more than 256 bytes of data from the host?

No_Name
Associate III

Hi everyone.

I'm trying to send more than 256 bytes of data from the host to the STM32 using USB CDC VCP, and I don't know why VCP won't accept more than 64 bytes of data. My project is already halfway done. If I switch to the USB bulk method, do I have to replace the USB CDC library and rewrite all the code from scratch? And do I have to create my own library to replace USB CDC?

I'm using an STM32F407VET6.

I appreciate all your answers.
Thank you:).

13 REPLIES 13

This is actually advantage, not a limitation. MCU can handle data as soon as it arrives, not waiting for ZLP and not needing memory to store the whole transaction. 

 

No_Name
Associate III

@Pavel A. @TDK @gbm @AScha.3 

Okay, I understand. So, what is meant by VCP or bulk is the communication method on the host side, so the delay depends on the driver used by the host? So on the firmware side, regardless of the communication method used, larger data will still be divided into 64 bytes. It all depends on the host.

I used to think that splitting packets would cause significant delays, but it turns out that's not the case because the data is sent quickly even though it's split into 64 bytes/packet.

Practically you may reach around 300 kB/s data reception with FS CDC VCP on almost any STM32 communicating with a PC using a terminal emulator. You receive packets of up to 64 B (the most common/maximum setting for FS EP size) and how you handle them is up to you.

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice

I used to think that splitting packets would cause significant delays

If the host is a rich OS (Linux/Window/Mac) its host controller (and driver) likely handles this stuff very effectively. The host application should send data in large chunks to avoid delays. If it can queue several chunks asynchronously, even better.

If the host is another STM32 or alike... it should move quickly.