UART 2M Baud rate experience

UART is a terrible protocol , be carefull while considering it for higher data transfer . There are bottlenecks everywhere hardware /software /driver /buffer .. which includes even if you have a flow control in place . .. I had earlier serious data loss, attempted everything to stop it . changed timeout / added flow control .. overlapped read write to normal ...   now no loss


tested using CH340G    (timeout can be adjusted to get 1000polls/sec) , loop back method (tx/rx  connected)  64byte per transfer   (CTS/RTS connected)

Experiment 1:

9600 - 15 polls /sec - no loss
14400-  23 polls /sec - no loss
19200-  30 polls /sec - no loss
38400-  56 polls /sec - no loss
57600-  88 polls /sec - no loss
115200-  174 polls /sec - no loss
128000-  190 polls /sec - no loss
230400-  334 polls /sec - no loss
460800-  650 polls /sec - no loss
921600-  1120 polls /sec - no loss
1500000-  1593 polls /sec - no loss  (removed CTS/RTS(both software & hardware) & checked ,no effect )
2000000-  30 polls /sec - loss started  ...  it looks like loss is because of TX completion , afterwards RX starts ,since single device used . otherwise if I use 2 devices , I guess it should be fine.

Experiment 2:  2 USB-UART devices 

1500000-  666 polls /sec 
2000000-  loss

64*666x 8bits= 340.992Kbps ( both directions )

Experiment 3:

Added 2 threads , one for reception & other for Transmission .. Reception hanged , may be it requires some sort of synchronous .  even if I add 1ms delay , it looks like I cant achieve more than 660 polls 


Experiment 4: 128 bytes per cycle 

1500000-  804 polls /sec - no loss  - reduced to half

Experiment 5: 512 bytes per cycle 

1500000-  230 polls /sec - no loss  - reduced to half 
8x230=>1840 
1840x64x8=942,080  => comes close to 1Mbps
(provided data readily available from controller, otherwise it would cause further delays )

Experiment 6: 1024 bytes per cycle 

1500000-  117polls /sec - no loss  - reduced to half 
16x117=>1872
1872x64x8=958464  => comes close to 1Mbps





Experiment 7:  cp2012 :1024 byte

1500000-  130polls /sec - actually this buad rate is not suppose to work as per their spec
2000000-  130polls /sec
3000000-  130polls /sec
4000000-  130polls /sec (dont know what the fuck is happening with this chip)
6000000-  130polls /sec (no CRO here)
12000000-  130polls /sec (haa haa thats almost protocol speed)
921600 - 83 polls/sec ( back to normal)


Experiment 8:  cp2012 :512 byte

1500000-  250polls /sec - 
921600 - 156polls/sec


Experiment 9:  cp2012 :64byte

1500000-  990polls /sec -  wow matches to 1ms 

921600 - 565polls/sec
460800-  500polls /sec

990x64x8=506.880kbps





Experiment 10:  FT2232D :64byte 

460800-  104polls /sec , mummy ...I am pretty sure this is something related to FTDI timeout. Stoping this experiment here , because its simply waste .

ft2xx command mode 
3000000- 3615polls/sec  -  FTDI is always the master , you could tweak anything & make  it work 
for your application.   poll is beyond the limit , let me connect it to other port 

now reduced to 2200 

2200x64x8= 1.12Mbps


Experiment 11:  FT2232H :64byte High Speed

command mode 
3000000-4770 polls 
12Mbaud-17,000 polls/sec another port it is 7899 polls /sec , close to theoritical calculation 8000


here too , in Serial mode , still has some timeout issue ..


end of research