I was trying to get higher communications speeds for my STUART program, which ended by making my own USB UART dongle with some MCU. During the work I've found few interesting facts which seems to be worth of sharing (I didn't find them in the forum).
My F3 drive ST2000DL003 can show the available baudrates by trying to set an invalid one by /TB1 command. My drive will print this list:
When I tried to set anything faster than 460800bps with my own USB/UART dongle, there were characters missing or misinterpreted. A little bit frustrated I've tried to measure the real speeds and got this table (the slowest speeds were not tested) .. also the real value is probably +-15 bps (MCU is slow
baudrate real speed
The choices are funny because you have three of them, but the real speed the same. And if you try to set for example 1.25 Mbps and you have dongle which can really go exactly 1.25 Mbps, the drive will expect 1.2Mbps and the difference may cause wrong characters to be received (it is like 4% difference, which _may_ be tolerant, but the transmission speed is pretty fast too). The choice like 921600 is so completely different from the real speed even the F3 prompt will be damaged.
A side topic: We can actually see what are the most probable internal bus speeds of the SoC as the lowest integer multiplicator for 857150 bps is 7 => 6MHz, for 462093 it is 277 (prime!) => 128MHz, 1199985 is most likely 6MHz too (with 5 multiplicator). It seems between "460800" and "625000" the firmware will switch to another PLL source (it is possible the bus speed is the least common multiple of 6 and 128 => 384MHz), which wasn't very well accounted for during the /TB list creation. Be aware of this fact when you trying to use that higher speeds.
Another interesting fact: the drive cannot keep up with faster speeds (even at 462093) so the characters will dissapear in some longer commands (the drive seems to not send any XON/XOFF flow control .. maybe only in ESLIP, dunno). Missing a single character in "/FD" can do miracles
. To make any automatic program reliable, you need to send one character, wait for echo and then to send another. The input buffer of the drive seems to be around 8 bytes.
The problem is if you use USB dongle, you will get pretty high latencies as the USB stack will send only 1 packet per 1 (micro)frame. Your program will have to wait for 1ms (in USB 1.1) or 125us (in USB 2.0). I have one PL2303 based dongle which sends one packet every 2ms. This is wasting of the time the HDD is faster than that and at 1.2Mbps you are wasting up to 100 characters by waiting a frame for every response. The lowest latency should be possible with some hardware uart port (like raspberry pi), where you don't need to wait for usb (micro)frames. I haven't yet tested this theory, but I'm planning to (with rockpro64 board).
P.S. switching back (/TB) from 1.2Mbps may crash the drive.
I hope this info will help somebody