The best method to transmit continuous data from the STM32 to a PC at high speed

[KSOdin2]

I am currently using the STM32 to sample a waveform with an ADC, perform the FFT and transmit the data to a computer. 2 ADC's are used, and the buffer fills up every 1.26 ms. The result of 12 FFT bins is transmitted to the PC, which is around 1400 bits. The data needs to be transmitted before the next buffer fills up; this is why UART is set to high rates of 7M/bits. The board being used is the NucleoH7A3ZI-Q

I have tried several communication methods, but all seem to not work for different reasons. These are:

1. UART at 7M/bits per second via the STLink. Though this works, I can see the data printed via virtual com port and PUtty. However, the serials link is set to 115200 K/bits, so after a while, a group of transmitted data is lost as the STlink is overflowed.
2. UART at 7M/bits per second via a high-speed serial cable. Same as over the STLINK, this high-speed cable can take in 7M but only outputs the data at 1Mb/s when you look at the virtual com port in the device manager. So again, there is data loss.
3. USB via Communication device class (Virtual port com). This worked well as the data was transmitted at full speed (12M/bs), but when I looked at the device manager, the port was set to 128200 and could not be increased.

My questions are:

Has anyone had an experience with a problem like this and can give some guidance? Or is there any good documentation or examples on the problem?

Is there something I've been doing wrong when attempting via my current methods of UART and USB?

Thanks for any advice.

[Tesla DeLorean]

>>Is there something I've been doing wrong when attempting via my current methods of UART and USB?

Fire-hosing ASCII human readable / comma delimited stuff via the serial port, into a terminal, probably not how it's done.

The serial interface has very little integrity checking, and retry or flow control.

Other things use packetized data, and user space applications to ingest, process and log data. The application needs to be able to sink data at high rates and continuously.

USB is inherently half-duplex, most of the ST implementations don't support the 480 Mbps modes.

12 Mbps is what like 600-800 KBps in a CDC/VCP context.

Thing that spill data at high speed, predominantly one way, like Video Cameras have their own class / drivers.

https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/transfer-data-to-isochronous-endpoints

[KSOdin2]

Yes, the ASCII version (the way I am doing it) is inefficient, and I will update this to reduce the number of bits being sent, reducing the baud rate.

The video class is interesting. On CubeIDE, there is no option for it through middleware. BUt, when you look at the repository, there is a folder called VIDEO in the STM32_USB_Device_Library folder. So this could be another approach.

Thank you

[AScha.3]

>USB via Communication device class (Virtual port com)

a VCP can transmit about 1MB/s (8 Mbit/s , in my tests), the speed setting as "serial" maybe 19200 is not important.

transfer is on usb at its own speed, best if no other members on bus/port.

[KSOdin2]

Maybe I'm getting too hung up on the device manager saying the port is 100KB/s if you're getting good speed. Just will start looking into sending the data in large batches every few ms instead of ever 1 ms.

Thank you.

[TDK]

USB will not be reliable if you need to shift out data every 1.26ms. Typically the drivers on the computer-side will insert delays of tens of ms due to the OS doing stuff. You can get around 8 Mbps, but only with a larger device-side buffer and good coding.

UART chips typically do not support more than about 2 Mbaud at the hardware level. The STM32 can output higher than this, but it does no good if the receiving chip can't support it. You can also run into clock issues if the baud rate is not an exact divisor of the system clock on both sides.

I would go with USB, with a large enough device buffer. 100ms of buffer is ~90kB which your board has available. You can use less if you don't care about lost data.

[KSOdin2]

Yes, it seems USB has a high data rate the delays you mention make it not viable.

That's an interesting point about the baud rate needing to be an exact divisor of the system on both sides. I've always assumed the issue would be on the STM32 side, as the PC should be much more powerful.

Unfortunately, data loss is the problem at the moment as measurements are being lost. But I will look into USB and a large transmit buffer. Where I send it as a large block of data rather than small intervales.

Thank you

[Nikita91]

I use the FTDI C232HM cable at 12 Mb/s. With DMA the throughput is very good (over 1MB/s).

Do you need to output the result every 1.26ms? Can you pack 4 blocks to output data every ~5ms?

In my opinion ST-LINK is not made for high speeds on its UART. But with an STLINK V3 as on your Nucleo several Mb/s should be possible from end to end.

[KSOdin2]

Yes, I have used that cable too, just for clarity. Does it take in 12M/B/s UART and output the data at 1M/B? I'm still struggling to get my head around how it works.

Yes, maybe sending the data less frequently or grouping them together, like you said every 5 ms might work better. Though would the same issue not still occur as its still the same amount of data being sent?

I'll look into the data sheet of the STLINK V3 as I may be misunderstanding how it all works.

Thank you

[Pavel A.]

Either USB as Tesla advises (Full speed: nominal 12 MBit/s, or High speed - usually requires external PHY) - but not necessarily VCP mode. Use the normal bulk pipe (on Windows supported by WinUSB and does not require custom drivers).

Note also that some STM32s in USB device mode can synchronize the USB clock by the SOF signal from host, so do not require external oscillator.,

Or find a FTDI serial or SPI adaptor with USB high speed connection.