baudrate serial USB

Please someone can tell me the max baudrate that i can reach with the serial connection by usb? My board is the maple mini baite clone.

I run 115,200 but I suspect your terminal hardware (PC) may have issues depending on age, OS, USB port specs., adaptersm hubs, etc.

Instead of asking, just try … if you can only get 9600 BAUD, it is time to replace the PC.

Ray

I posted some tests ages ago. I cant recall where they are in the forum, you could try googling the site e.g. use. site:www.stm32duino.com in the query.

From what I recall, the speed is limited by how many newlines you send.

If you send single chars followed by a newline, the speed is probably only 115200, or perhaps lower.

But if you send longer strings, e.g. 32 or 64 chars long, the speed is much much higher.

I am not sure why newlines made a difference. It could be something in the libmaple USB handling, but could equally be something in the hosts USB driver or the hosts terminal program.

I didnt dig any deeper, as I found it is plenty fast enough for me to record data from an accelerometer and send in realtime to a PC, so I could do vibration analysis on laser cutter gantry

The onboard USB is a Serial CDC device, actually it is not serial, it seems by your computer as serial but there are no real baudrates. The data are transfered as fast as USB code/interface/CPU permits (it depends heavily by number of bytes in each call). I remembered some timing tests we made some months ago, the speed with transmit packages of about 50 bytes was like uart at 5Mbauds.

http://www.stm32duino.com/viewtopic.php … =10#p12059

Yes, with USB the “baudrate” does not matter. The max theoretical speed is 12MBit with full speed USB. So I would expect 5MBit might be doable, it depends on the MMini CPU load.
Baudrate matters when you have got an “USB to serial dongle” in between. But that dongle is not used when communicating with Maple Mini via USB serial.

PC USB <———-USB=12MBit———–>Maple Mini USB (depends on MM processing speed)

PC USB <——USB=12MBit——|USB to Serial dongle|——-Serial 9k6..115k2..3MBit—–>Maple Mini UART

Hm, I am using hand-shacked transmission (maple mini sends a block of data and waits for ACK from PC) and I could never go over ~160kbps.
Am I missing something?
Of course, in this situation the PC latency has huge influence, but this is the maximum average speed what I could get with an i5 2.25GHz Win10 machine.

stevestrong wrote:Hm, I am using hand-shacked transmission (maple mini sends a block of data and waits for ACK from PC) and I could never go over ~160kbps.
Am I missing something?
Of course, in this situation the PC latency has huge influence, but this is the maximum average speed what I could get with an i5 2.25GHz Win10 machine.

“handshaking” is a two-way street … even if the PC has no latency there is still a significant amount of work to be done at the uC level.
Ray, I am surely aware of this latency, too. BTW, how “much” (long) work are we actually talking about here (on uC side)?
Just wondered if anyone else could get better results.

stevestrong wrote:“handshaking” is a two-way street … even if the PC has no latency there is still a significant amount of work to be done at the uC level.
Ray, I am surely aware of this latency, too. BTW, how “much” (long) work are we actually talking about here (on uC side)?
Just wondered if anyone else could get better results.

stevestrong wrote:Hm, I am using hand-shacked transmission (maple mini sends a block of data and waits for ACK from PC) and I could never go over ~160kbps.
Am I missing something?
Of course, in this situation the PC latency has huge influence, but this is the maximum average speed what I could get with an i5 2.25GHz Win10 machine.

1.72Mbps … not bad at all.
I use handshake exactly because otherwise I can sometimes lose bytes, or receive non-sense data when too many bytes are underway … is this USB overflow?
I would be interested in .enableBlockingTx() for F103.

Yes, what you’ve seen is a USB overflow.
For the enableBlockingTx() under F103, I presume it could be implemented.
From what I’ve seen in the code, the following code should probably simply wait instead of returning without sending data depending of blocking flag.

/* This function is non-blocking.
*
* It copies data from a usercode buffer into the USB peripheral TX
* buffer, and returns the number of bytes copied. */
uint32 usb_cdcacm_tx(const uint8* buf, uint32 len) {
/* Last transmission hasn't finished, so abort. */
if (usb_cdcacm_is_transmitting()) {
return 0;
}