CDC Transfer speeds with USB FS on STM32F4

[chintal]

I've setup a USB CDC endpoint on the USB Full Speed peripheral of the STM32F407 clocked at 168 MHz. My code is based on the dual cdc example, with the second cdc interface commented out. The host is linux and the host side software is based on pyserial, and is reading one byte at a time in essentially an infinite loop.

The device side code essentially just does the following in a tight loop:

• if tud_cdc_n_write_available reports enough space, a const buffer of 43 bytes is pushed in using tud_cdc_n_write.
• tud_task is called.

Other than the USB_FS interrupt, I also have the STM32 SysClock interrupt firing every 1ms. I'm pretty sure clock interrupt handler is quite short.

I'm seeing reliable transfer rates from device to host at about 72k bytes / sec. Is this a reasonable throughput?

This is the configuration I'm using:

#define BOARD_TUD_MAX_SPEED          OPT_MODE_FULL_SPEED
#define CFG_TUSB_RHPORT0_MODE     OPT_MODE_DEVICE | BOARD_TUD_MAX_SPEED
#define CFG_TUSB_MCU                           OPT_MCU_STM32F4  
#define CFG_TUSB_OS                               OPT_OS_NONE

#define CFG_TUSB_DEBUG        0

// CDC FIFO size of TX and RX
#define CFG_TUD_CDC_RX_BUFSIZE   512
#define CFG_TUD_CDC_TX_BUFSIZE   512
// CDC Endpoint transfer buffer size, more is faster
#define CFG_TUD_CDC_EP_BUFSIZE   64

I would like to atleast be able to sustain 200 kbytes / sec and comfortably beat 1 Mbaud UART.

I expect USB FS at 12 Mbits/sec should theoretically be able to manage 1 MByte/sec, or atleast sustain 500 kbytes / sec assuming a busy host, even with the CDC protocol overheads. Any suggestions of where to look for the missing bandwidth would be much appreciated.

Additional Information:

1. These speeds do not seem to change significantly even when changing the EP_BUFSIZE, RX_BUFSIZE, and TX_BUFSIZE. I've tried various combinations, upto [4096, 4096, 1024]. As long as EP_BUFSIZE is <= RX_BUFSIZE and TX_BUFSIZE, it works and sustains about the same speed. Once EP_BUFSIZE is < TX_BUFSIZE, it stops working at all. Though it enumerates correctly, no character is received by the host or device. I'm not too concerned about it : I expect to use RX and TX buffers larger than the endpoint buffer anyway. I mention this because it might be symptomatic of something else I might be doing wrong.

2. The host is using the cdc_acm driver:

[ 8782.928615] usb 3-2: new full-speed USB device number 12 using xhci_hcd
[ 8783.085492] usb 3-2: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 1.00
[ 8783.085508] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
....
[ 8783.116677] cdc_acm 3-2:1.0: ttyACM0: USB ACM device

3. Wireshark shows 192 byte packet sizes being sent from the device, of which 64 bytes is protocol overhead (0x00 - 0x3F) and 128 bytes is the payload (0x40 - 0xb0). I don't see any nacked packets, though I'm not convinced I've worked out how to filter for nacked packets on wireshark.

4. A filter on wireshark for usb.src == "3.12.2" (device 12 on bus 3) seems to be more or less stable at about 550 packets / sec - which is in line with the about 70 kbyte / sec transfer speeds I am seeing.

5. There also appear to be no packets shorter than 192 bytes, so I don't expect any bandwidth is being used up in zero packets or otherwise truncated packets.

6. I was testing originally with the 0.16 tinyusb release. I have upgraded to the recent 0.17 release and see no noticeable improvement in performance.

[HiFiPhile]

The host is linux and the host side software is based on pyserial, and is reading one byte at a time in essentially an infinite loop.

I believe most overheads come from your host. Even with a STM32L0 @ 32MHz I achieved about 700kB/s when the host is optimized.

[chintal]

I believe most overheads come from your host. Even with a STM32L0 @ 32MHz I achieved about 700kB/s when the host is optimized.

Could you suggest an optimized host-side client or library, if there is one?

[chintal]

You are correct. Simply using cat does improve the situation significantly :

cat /dev/ttyACM0 > /dev/null

While I can't immediately verify the transfer is going through correctly, it is able to transmit nearly 7500 packets/sec, and most of the packets are the correct size. This should be over 900 kbytes/sec. Now I only need to find a better optimized way to handle usb cdc data.

Thanks!

[HiFiPhile]

With pyserial you can read a larger chunk like 64 bytes with a timeout like 10ms, in this way there will be much less API call and keeping responsivity.

[chintal]

I've tried a better 'optimised' pyserial approach. Here are some anecdotal benchmarks on my hardware for anyone looking in the future.

This is the code handling the actual usb communication. Each of these functions is run in its own thread. read_buffer is a collections.deque instance of 1MByte size. My device does no reading except during startup. So though the _write_to_serial function is implemented, in these results it is never being used and no data flows through it.

    def _read_from_serial(self):
        while not self._stop_threads.is_set():
            if self.ser.in_waiting > 0:
                data = self.ser.read(self.ser.in_waiting)
                with self.read_lock:
                    self.read_buffer.extend(data)
                self.bytes_received += len(data)  # Accumulate received bytes
            sleep(0.01)  # Slight delay to avoid excessive CPU usage

    def _write_to_serial(self):
        while not self._stop_threads.is_set():
            if self.write_buffer:
                with self.write_lock:
                    data = bytearray()
                    while self.write_buffer:
                        data.append(self.write_buffer.popleft())
                    self.ser.write(data)
                self.bytes_transmitted += len(data)  # Accumulate transmitted bytes
            sleep(0.01)

Sleep In Read	Sleep in Write	CPU Usage	Read Speed
[x]	[x]	10%	2.8 Mbit/sec
[ ]	[x]	100%	7.3 Mbit/sec
[ ]	[ ]	100%	3.7 Mbit/sec