CH340 USB-UART Speed tests ?

[PCB.Wiz]

FT230X is the best so far. Perfect performance at up to 3 Mbps.

Those are similar to CP2102N tests I did.
That can Txmit up to 4MBd, (no RX) with no added stop bits, and can manage duplex-echo to 2Mbd, or is OK > 2MBd if you enable HW handshake in the terminals.
With handshake on, the data rate peaks at sustained average 200.083 k Bytes/sec (each way) at 2MBd echo duplex, and falls slightly above that to  Average: 180.2405 k Bytes/sec (each way) at 4Mbd (no errors with HS)
Guess the shuffling of the handshake lines, consumes some bandwidth that could have been used for data & I think USB has a `slot-miss effect`, you can bump into if packets are not unloaded fast enough.?

[oPossum]

CP2104 did well. No data loss, but a bit slow at high bit rates.

Code: [Select]

1300640 bits per second (43.4 % of 3000000 bps)
130064 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
8062 milliseconds elapsed time

1083680 bits per second (54.2 % of 2000000 bps)
108368 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
9676 milliseconds elapsed time

934390 bits per second (62.3 % of 1500000 bps)
93439 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
11222 milliseconds elapsed time

827930 bits per second (82.8 % of 1000000 bps)
82793 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
12665 milliseconds elapsed time

675540 bits per second (90.1 % of 750000 bps)
67554 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
15522 milliseconds elapsed time

454510 bits per second (90.9 % of 500000 bps)
45451 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
23070 milliseconds elapsed time

250000 bits per second (100 % of 250000 bps)
25000 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
41943 milliseconds elapsed time

230740 bits per second (100.2 % of 230400 bps)
23074 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
45444 milliseconds elapsed time

115370 bits per second (100.2 % of 115200 bps)
11537 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
90888 milliseconds elapsed time


[PCB.Wiz]

CP2104 did well. No data loss, but a bit slow at high bit rates.

If you have one, the CP2102N uses a faster MCU (2x?) platform than the CP2104. Be interesting to see like-tests results on that ?
Has anyone seen prices or samples of PL2303G series ?
The best FS-USB-UARTS (not HS-USB, where the FTDI parts excell) I've tested are Exar XR21Bxxx series, but they are quite niche parts, not much stocked and not cheap.

[Siwastaja]

I tested many USB UARTs, some more expensive and claiming large FIFOs, only to find out that they all start corrupting data when around 1Mbps is exceeded. Not by much, but they might skip a byte every five to fifteen seconds, if full bandwidth is consumed.

I don't have an idea whether the problem was with the chips themselves, or broken linux drivers, but anyway that's what happened - they were all unusable beyond about 460800bps or 921600bps.

So I have trust issues when it comes to these adapters ran at high bitrates.

[oPossum]

CP2102 (old version).
No data loss, a little faster than the CP2104

Code: [Select]

1495820 bits per second (49.9 % of 3000000 bps)
149582 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
7010 milliseconds elapsed time

1495610 bits per second (74.8 % of 2000000 bps)
149561 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
7011 milliseconds elapsed time

1495180 bits per second (99.7 % of 1500000 bps)
149518 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
7013 milliseconds elapsed time

918590 bits per second (91.9 % of 1000000 bps)
91859 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
11415 milliseconds elapsed time

918510 bits per second (122.5 % of 750000 bps)
91851 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
11416 milliseconds elapsed time

497450 bits per second (99.5 % of 500000 bps)
49745 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
21079 milliseconds elapsed time

248920 bits per second (99.6 % of 250000 bps)
24892 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
42125 milliseconds elapsed time

229880 bits per second (99.8 % of 230400 bps)
22988 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
45613 milliseconds elapsed time

114990 bits per second (99.8 % of 115200 bps)
11499 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
91187 milliseconds elapsed time


[oPossum]

CP2104 did well. No data loss, but a bit slow at high bit rates.

If you have one, the CP2102N uses a faster MCU (2x?) platform than the CP2104. Be interesting to see like-tests results on that ?

I don't have the new N version. Read about some bugs in them. Don't recall what the problem was.

[oPossum]

Fake FT232RL. Works better than the genuine FT232RL!

Code: [Select]

1042820 bits per second (34.7607 % of 3000000 bps)
104282 bytes per second
1048576 total written
1032192 total read       (98 %)
1023132 total error bytes
9898 milliseconds elapsed time

1944680 bits per second (97.2 % of 2000000 bps)
194468 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
5392 milliseconds elapsed time

1485650 bits per second (99 % of 1500000 bps)
148565 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
7058 milliseconds elapsed time

993720 bits per second (99.4 % of 1000000 bps)
99372 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
10552 milliseconds elapsed time

748550 bits per second (99.8 % of 750000 bps)
74855 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
14008 milliseconds elapsed time

497820 bits per second (99.6 % of 500000 bps)
49782 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
21063 milliseconds elapsed time

249000 bits per second (99.6 % of 250000 bps)
24900 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
42111 milliseconds elapsed time

229760 bits per second (99.7 % of 230400 bps)
22976 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
45637 milliseconds elapsed time

114950 bits per second (99.7 % of 115200 bps)
11495 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
91215 milliseconds elapsed time


[magic]

Yes, based on the MCU's the company makes, the granularity is as per the table I posted above. ie The hardware does not support more. (but that list is already more than the data claims)
Most of the better USB-UART parts will round to the nearest valid baud speed, when asked for any baud rate.

PL2303 drivers will do it too but the chip supports anything with 2% or better resolution, see Linux pl2303.c file
It probably does involve some jitter, unless they use a PLL with bizarre ratios. Anyway, I found it good enough in practice.

There is a PL2303GS showing, but very new. I'd like to get my hands on some of those...

Wake me up when any Prolific chip is available from legitimate distributors. For hobby projects I use fakes from China.

PL2303GS doesn't seem much different from PL2303HXD, just a bit smaller package and more buffer space. There is PL2303SA in SO8 for space constrained applications, only TX/RX of course.

[NorthGuy]

I don't have an idea whether the problem was with the chips themselves, or broken linux drivers, but anyway that's what happened - they were all unusable beyond about 460800bps or 921600bps.

So I have trust issues when it comes to these adapters ran at high bitrates.

There must be significant difference depending on the direction. PC to UART is likely to have much better performance and no data loss. With UART to PC, if sender transmits back-to-back bytes, you need to go to much lower speeds to avoid data loss. Things are likely to get worse if you go full duplex.

[PCB.Wiz]

I tested many USB UARTs, some more expensive and claiming large FIFOs, only to find out that they all start corrupting data when around 1Mbps is exceeded. Not by much, but they might skip a byte every five to fifteen seconds, if full bandwidth is consumed.

I don't have an idea whether the problem was with the chips themselves, or broken linux drivers, but anyway that's what happened - they were all unusable beyond about 460800bps or 921600bps.

So I have trust issues when it comes to these adapters ran at high bitrates.

Certainly a good idea to be wary.  'Trust, but verify'

Was that one way, or both ways  (echo or duplex) ?
Tests above show echo on some older USB-UARTS does start to fail above 1MBd, but newer ones are better.
The FT232H is better still and the FT2232H even better, it managed 12MBd echo,8,n,1, no dropped chars. 6.000MHz streaming 0x55 (but you do pay more of course)

[oPossum]

A couple CP2102N tests by a friend.

Code: [Select]

855420 bits per second (28.514 % of 3000000 bps)
85542 bytes per second
1048576 total written
835584 total read       (79 %)
831680 total error bytes
9768 milliseconds elapsed time

997120 bits per second (99.712 % of 1000000 bps)
99712 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
10516 milliseconds elapsed time


[PCB.Wiz]

A couple CP2102N tests by a friend.

Code: [Select]

855420 bits per second (28.514 % of 3000000 bps)
85542 bytes per second
1048576 total written
835584 total read       (79 %)
831680 total error bytes
9768 milliseconds elapsed time

997120 bits per second (99.712 % of 1000000 bps)
99712 bytes per second
1048576 total written
1048576 total read       (100 %)
0 total error bytes
10516 milliseconds elapsed time


Filling in the gaps there, I get this, streaming 0x55 and checking with a frequency counter for added stop bits.
Then test changes to sending strings, in a loop, and short strings have slight gaps which lower the average baud.
Burst are sent at 3Mbd in all those cases, just with modest gaps to give the chip a chance to 'catch up'

Code: [Select]

Echo Duplex CP2102N :
BAUD      Setting      Sustained speed
2000000  ok at 8.n.1,  Ctr : 1978.89
2181818  ok at 8.n.1,  Ctr :  2181.81
2400000  ok at 8.n.1,  Ctr:   2400    OK over 6M chars tested.
2666667  ok at 8.n.2  time ~2.371 Ctr says = 2.42476, predict (24M/9)*(10/11) = 2.424242.   fails, drops chars at 8.n.1,
3000000  Tx 8.n.1 = 3.00174MHz

// CP2102N 3000000,n,8,1 Open ok COM38
// Tx:  38 Rx  38 Sending Len :  65 Times : 2000 FreeBASIC loop, 65 char strings is sparse TX  ( Fails with tLen 127, find the limit ? )
// Sent Chars   =  130000
// TX duration  =  0.5717297801747918
// CharBaudRate =  2273801.444456082   << below 2.4Mbd limit, so is OK, as expected
// Response: (queue.0) =  130000
// Response: (queue.50) =  130000
// TxLines : 2000 Rx Lines : 2000
// Match Checks Pass:  2000 Fail:  0

// Tx:  38 Rx  38 Sending Len :  84 Times : 2000
// Sent Chars   =  168000
// TX duration  =  0.688019918743521
// CharBaudRate =  2441789.771243916  << 84 has moved to just on limit, still this is OK
// Response: (queue.0) =  167616
// Response: (queue.50) =  168000
// TxLines : 2000 Rx Lines : 2000
// Match Checks Pass:  2000 Fail:  0

// Tx:  38 Rx  38 Sending Len :  94 Times : 3000
// Sent Chars   =  282000
// TX duration  =  1.127590310759842
// CharBaudRate =  2500908.329107319    94, climbs to 2.5M average, still just ok loopback.
// Response: (queue.0) =  282000
// Response: (queue.50) =  282000
// TxLines : 3000 Rx Lines : 3000
// Match Checks Pass:  3000 Fail:  0

// Tx:  38 Rx  38 Sending Len :  100 Times : 3000
// Sent Chars   =  300000
// TX duration  =  1.186960075981915
// CharBaudRate =  2527464.959188492   100, a tad more, still ok
// Response: (queue.0) =  300000
// Response: (queue.50) =  300000
// TxLines : 3000 Rx Lines : 3000
// Match Checks Pass:  3000 Fail:  0

// Tx:  38 Rx  38 Sending Len :  102 Times : 3000
// Sent Chars   =  306000
// TX duration  =  1.206364056561142
// CharBaudRate =  2536547.722354085
// Response: (queue.0) =  305984
// Response: (queue.50) =  305984
 E@ 213 LrS: 98 rS:55555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555
 E@ 219 LrS: 95 rS:;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 E@ 220 LrS: 94 rS:<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
// TxLines : 3000 Rx Lines : 3000
// Match Checks Pass:  2997 Fail:  3

ie looks ok, all the way up to  to 242.2k Bytes sec, each way, Duplex. - and fine at 300k bytes/sec one way.

[sl1pkn07]

Hello @opossum

can you share the code for self-test uart dongles? i have mine CP2102 with impossible read things in console at 1500000 bps (Rockchip RK3566 based SoC), just received garbage characters

i'm not sure is is a problem with comunication between both devices or just the usb dongle

greetings