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
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
