CH340 USB-UART Speed tests ? - Page 1
Forum section: electronics / general

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 03, 2019, 10:57:40 pm
content: I'm curious if anyone has done speed tests on CH340 ?Search finds a few threads here using CH340, but none mention actual throughput measurements / scope shots etcData mentions 460800、921600、1500000、2000000 baud speeds, but what continual Send and Receive speeds can the CH340 sustain ?

author: oPossum
author_rank: Super Contributor
timestamp: July 03, 2019, 11:01:04 pm
content: I routinely use them at 1.0 and 1.5 Mbps for 'printf debugging'. No problems with that application. I haven't tried to determine max throughput or possible data loss at high bps.

author: GromBeestje
author_rank: Frequent Contributor
timestamp: July 04, 2019, 04:54:42 pm
content: I haven't actually tested this, but I have reasons to believe the CH340 can communicate at arbitrary speeds. The reason why I believe this to be true it is possible to the a CH340 to connect to an AVR microcontroller over debugWire. This doesn't show it can run fast, but it shows it can run at non-standard speeds.

author: thm_w
author_rank: Super Contributor
timestamp: July 04, 2019, 09:39:25 pm
content: First two screenshots are output of the adapter. Third screenshot is on the CH340 pins. So there must be some series resistors on this random TTL adapter, slowing the rise time significantly.Won't let me go anywhere between 2 and 2.5, drops to the lower speed.I had to set the scope to 2.75 to get it to decode properly, but it is able to read back its own data OK at any rate.

author: oPossum
author_rank: Super Contributor
timestamp: July 04, 2019, 09:51:26 pm
content: Most USB to UART converters can work at bit rates of 3,000,000 / N where N is an integer. Some have limited support for other bit rates using a fractional divider.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 04, 2019, 10:26:11 pm
content: Quote from: oPossum on July 04, 2019, 09:51:26 pmThat virtual baud starting clock varies.eg FT2232H/FT232H/CP2102N have a virtual baud value of 24MHz, so those can give 24M/N, with some caveats on lowest values of N.

author: oPossum
author_rank: Super Contributor
timestamp: July 04, 2019, 10:40:13 pm
content: That is because they are using a fractional divider. The 3M / N rule usually avoids having to use the fractional divider, so you get no additional jitter.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 04, 2019, 10:43:41 pm
content: Quote from: thm_w on July 04, 2019, 09:39:25 pmThanks, nice plots.What baud settings were those generated at ? eg 1500000,8,n,1 ?observations :Even 1.5Mbd seem to have extra stop bits, and a lot more stop bits insert at the higher speeds. The higher speeds do not seem to match the data specs ?Do you have shots of bursts ? 64 bytes, often gaps can appear in larger data streams.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 04, 2019, 10:46:01 pm
content: Quote from: oPossum on July 04, 2019, 10:40:13 pmErr, no.... There is no jitter on a FT232H, even at 12Mbd.Likewise, CP2102N starts from 48MHz sysCLK, and divides by 2, then divides by N, no fractional jitter. EXAR parts are the only ones I've tested that have fractional-baud-jitter.

author: oPossum
author_rank: Super Contributor
timestamp: July 04, 2019, 10:51:44 pm
content: Then they are not using typical 16x sampling at those bit rates. That can create similar problems as clock jitter.

author: thm_w
author_rank: Super Contributor
timestamp: July 04, 2019, 11:21:09 pm
content: Quote from: PCB.Wiz on July 04, 2019, 10:43:41 pmYeah 1500000,8,n,1.The stop bit time at 2M is 2us so 4 bit times. Not sure why its so long like that. Tried a few different programs and seems to have the same result.Sending 100 bytes I don't see any gaps.At 2.5Mbps its actually running at 3Mbps (330ns bit time), thats why the numbers were off. So 3 is the highest available.

author: langwadt
author_rank: Super Contributor
timestamp: July 04, 2019, 11:31:37 pm
content: Quote from: PCB.Wiz on July 04, 2019, 10:43:41 pmstop bits and idle is the same, so it just not filling the transmitter as fast as it possible

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 04, 2019, 11:52:57 pm
content: Quote from: thm_w on July 04, 2019, 11:21:09 pmAhh, thanks, 3MBd makes more sense from 48MHz USB clocks, than 2.82MBdQuote from: thm_w on July 04, 2019, 11:21:09 pmStretched stop bits are common, when the core MCU cannot deliver the bytes fast enough, but it is less common to struggle at the byte rate, and not show any gaps at USB packet boundaries.Even 1.5Mbd is adding extra stop bits (looks like 2 more?) , maybe the sub 1MBd can run with fewer added stop bits ?Their claimed 921600 is harder to extract from 48MHz if we assume /16 of their MCUs, seems to imply 48M/4/13, or

author: oPossum
author_rank: Super Contributor
timestamp: July 05, 2019, 12:57:50 am
content: My bit rates notes from evaluation of the CH340C. A few notable exceptions to the 3M/N rule are 2.0M, 1.2M and 923k (~115.2 *. You have to ask for exactly 921,600 to get closest to it.Code:CH340CRequested bps Actual bps---------------------------------6,000,000 Error opening port4,000,000 Error opening port3,000,000 3,000,0002,400,000 2,000,0002,000,000 2,000,0001,714,286 1,500,0001,500,000 1,500,0001,333,333 1,200,0001,200,000 1,200,0001,090,090 1,000,0001,000,000 1,000,000923,077 860,000921,601 860,000921,600 923,077921,599 860,000857,143 860,000800,000 750,000750,000 750,000705,882 666,667666,667 666,667631,579 600,000600,000 600,000571,429 545,455545,455 545,455521,739 500,000500,000 500,000

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 05, 2019, 01:34:20 am
content: Quote from: oPossum on July 05, 2019, 12:57:50 amThanks, interesting the 921,600 is such a special case test, they test for == and then do something different.( Bemusing if you asked for 923,077, it bumps to 857143, but if you ask for 921,600, you get 923,077 !)The formula here is (loosely based on their MCUs ) SysCLK of 96MHz and /16 from there - or a 6MHz virtual baud clock value (except for 921,600, when that is 12MHz)Code:N=0;;N=N+1;96M/16/N (or 48M/8/N)600000030000002000000150000012000001000000857142.857750000666666.666600000545454.545500000Special case : 96M/8/13 or 48M/4/13 = 923076.92 looks like their MCUs may have a not documented /8 or /4 choice.

author: westfw
author_rank: Super Contributor
timestamp: July 05, 2019, 07:25:42 am
content: QuoteBuncha spoiled kids. Like anything over 115200bps isn't "absurdly fast" for an Async UART connection..."when I was young, we were absurdly happy to use the 300bps acoustic coupler terminals instead of the 110bps ASR33s, and those 2400bps "local" CRTs were heaven! And Get Off Of My Lawn!"-A more interesting question is how a given adapter behaves in a ping-pong prompt/response scenario (like the Arduino STK500v1 "upload" protocol.) As PCB.Wiz implied, packetization issues are more likely to be a bottleneck at "reasonable" speeds than raw character throughput.

author: oPossum
author_rank: Super Contributor
timestamp: July 05, 2019, 08:55:25 am
content: I wrote some code to test throughput and reliability.Some results for CH340G.Runs close to full speed at 500,000 and below.Data corruption at 1,500,000 and above.Code:462470 bits per second (15.4157 % of 3000000 bps)46247 bytes per second1048576 total written1048576 total confirmed1032192 total read (98 %)1032132 total error bytes22319 milliseconds elapsed time463150 bits per second (23.1575 % of 2000000 bps)46315 bytes per second1048576 total written1048576 total confirmed1032192 total read (98 %)1031388 total error bytes22286 milliseconds elapsed time461580 bits per second (30.772 % of 1500000 bps)46158 bytes per second1048576 total written1048576 total confirmed1032192 total read (98 %)440608 total error bytes22362 milliseconds elapsed time640000 bits per second (64 % of 1000000 bps)64000 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes16384 milliseconds elapsed time640000 bits per second (85.3 % of 750000 bps)64000 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes16384 milliseconds elapsed time479980 bits per second (96 % of 500000 bps)47998 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes21846 milliseconds elapsed time250010 bits per second (100 % of 250000 bps)25001 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes41941 milliseconds elapsed time230780 bits per second (100.2 % of 230400 bps)23078 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes45436 milliseconds elapsed time115390 bits per second (100.2 % of 115200 bps)11539 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes90870 milliseconds elapsed time

author: magic
author_rank: Super Contributor
timestamp: July 05, 2019, 09:04:38 am
content: Quote from: oPossum on July 05, 2019, 12:57:50 amIs this from Windows?A glance at the Linux driver suggests the chip has much higher resolution, like PL2303.The latter supports pretty much any rate below 6M with 2% granularity or so. I have successfully used it to push data at oddball bitrates like 1.66M into an MCU running at unusual clock.As for corruption, it's probably not corruption but simple loss of a few bytes here and there, but your program reports errors because it isn't sophisticated enough to detect loss.For starters, use two adapters, preferably connected to different USB controllers (not just ports, usually two ports are connected to each 1.1 host controller).If it doesn't help, enable hardware flow control. This will give you lossless transmission even in loopback, but at lower throughput.For reliable high speed UART, flow control is a must unless you are absolutely sure that your receiver has sufficient buffering and low enough latency not to lose bytes.

author: oPossum
author_rank: Super Contributor
timestamp: July 05, 2019, 09:17:37 am
content: Same test with FT232RLWorks very well at 1,000,000 bps and lowerCode:1059560 bits per second (35.3187 % of 3000000 bps)105956 bytes per second1048576 total written1015808 total read (96 %)999680 total error bytes9587 milliseconds elapsed time906460 bits per second (45.323 % of 2000000 bps)90646 bytes per second1048576 total written1032192 total read (98 %)1024000 total error bytes11387 milliseconds elapsed time791610 bits per second (52.774 % of 1500000 bps)79161 bytes per second1048576 total written1032192 total read (98 %)976384 total error bytes13039 milliseconds elapsed time998070 bits per second (99.8 % of 1000000 bps)99807 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes10506 milliseconds elapsed time749030 bits per second (99.9 % of 750000 bps)74903 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes13999 milliseconds elapsed time499580 bits per second (99.9 % of 500000 bps)49958 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes20989 milliseconds elapsed time249890 bits per second (100 % of 250000 bps)24989 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes41960 milliseconds elapsed time230670 bits per second (100 % of 230400 bps)23067 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes45456 milliseconds elapsed time115360 bits per second (100 % of 115200 bps)11536 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes90891 milliseconds elapsed time

author: oPossum
author_rank: Super Contributor
timestamp: July 05, 2019, 09:24:39 am
content: Quote from: magic on July 05, 2019, 09:04:38 amYesQuoteYep, I agree, probably supports more than what is available with the Windows driver.QuoteI doesn't try to determine the nature of the loss/corruption. That may be added later.QuoteThat is already on the list of things to try.

author: magic
author_rank: Super Contributor
timestamp: July 05, 2019, 09:32:01 am
content: Quote from: oPossum on July 05, 2019, 09:24:39 amMaybe or maybe not, just because Linux doesn't deliberately reject bitrates other than 2M or 1.5M doesn't mean the chip wouldn't do something stupid if you try to use them.I would give it a quick test and report back but I don't have any CH340.Another interesting thing to check is disconnect RX so that the chip isn't busy receiving and see how much data it can push into TX. IIRC, PL2303 could transmit well over 2Mb/s and bitrates above 3Mb/s made pretty much no difference to throughput.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 05, 2019, 09:37:52 am
content: Quote from: oPossum on July 05, 2019, 08:55:25 amIs this a loop-back test ? (TX links to RX) - that's a useful self-pacing test point.Somewhat tougher, is to connect a FT232H/FT2232H to Rx side (ensures 8.n.1 incoming stream, no gaps), and then TX two ports at once for true full duplex...

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 05, 2019, 09:45:44 am
content: Quote from: magic on July 05, 2019, 09:32:01 amYes, 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 thenearest valid baud speed, when asked for any baud rate.Quote from: magic on July 05, 2019, 09:32:01 amThat's shown above on the scope, the extra added stop bits mean the sustainedaveragespeed does not change 2M to 3M.Quote from: magic on July 05, 2019, 09:04:38 amThere is a PL2303GS showing, but very new. I'd like to get my hands on some of those...

author: oPossum
author_rank: Super Contributor
timestamp: July 05, 2019, 09:46:50 am
content: FT230X is the best so far. Perfect performance at up to 3 Mbps.Code:2983990 bits per second (99.5 % of 3000000 bps)298399 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes3514 milliseconds elapsed time1992350 bits per second (99.6 % of 2000000 bps)199235 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes5263 milliseconds elapsed time1495400 bits per second (99.7 % of 1500000 bps)149540 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes7012 milliseconds elapsed time998070 bits per second (99.8 % of 1000000 bps)99807 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes10506 milliseconds elapsed time748920 bits per second (99.9 % of 750000 bps)74892 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes14001 milliseconds elapsed time499510 bits per second (99.9 % of 500000 bps)49951 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes20992 milliseconds elapsed time249860 bits per second (99.9 % of 250000 bps)24986 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes41966 milliseconds elapsed time230640 bits per second (100.1 % of 230400 bps)23064 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes45462 milliseconds elapsed time115340 bits per second (100.1 % of 115200 bps)11534 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes90904 milliseconds elapsed time

author: oPossum
author_rank: Super Contributor
timestamp: July 05, 2019, 09:49:19 am
content: Quote from: PCB.Wiz on July 05, 2019, 09:37:52 amYes, just a simple loop back on a single chip for now.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 05, 2019, 10:04:36 am
content: Quote from: oPossum on July 05, 2019, 09:46:50 amThose 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.?

author: oPossum
author_rank: Super Contributor
timestamp: July 05, 2019, 10:10:33 am
content: CP2104 did well. No data loss, but a bit slow at high bit rates.Code:1300640 bits per second (43.4 % of 3000000 bps)130064 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes8062 milliseconds elapsed time1083680 bits per second (54.2 % of 2000000 bps)108368 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes9676 milliseconds elapsed time934390 bits per second (62.3 % of 1500000 bps)93439 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes11222 milliseconds elapsed time827930 bits per second (82.8 % of 1000000 bps)82793 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes12665 milliseconds elapsed time675540 bits per second (90.1 % of 750000 bps)67554 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes15522 milliseconds elapsed time454510 bits per second (90.9 % of 500000 bps)45451 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes23070 milliseconds elapsed time250000 bits per second (100 % of 250000 bps)25000 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes41943 milliseconds elapsed time230740 bits per second (100.2 % of 230400 bps)23074 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes45444 milliseconds elapsed time115370 bits per second (100.2 % of 115200 bps)11537 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes90888 milliseconds elapsed time

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 05, 2019, 10:15:43 am
content: Quote from: oPossum on July 05, 2019, 10:10:33 amIf 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 05, 2019, 10:25:33 am
content: I testedmanyUSB 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.

author: oPossum
author_rank: Super Contributor
timestamp: July 05, 2019, 10:29:45 am
content: CP2102 (old version).No data loss, a little faster than the CP2104Code:1495820 bits per second (49.9 % of 3000000 bps)149582 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes7010 milliseconds elapsed time1495610 bits per second (74.8 % of 2000000 bps)149561 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes7011 milliseconds elapsed time1495180 bits per second (99.7 % of 1500000 bps)149518 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes7013 milliseconds elapsed time918590 bits per second (91.9 % of 1000000 bps)91859 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes11415 milliseconds elapsed time918510 bits per second (122.5 % of 750000 bps)91851 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes11416 milliseconds elapsed time497450 bits per second (99.5 % of 500000 bps)49745 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes21079 milliseconds elapsed time248920 bits per second (99.6 % of 250000 bps)24892 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes42125 milliseconds elapsed time229880 bits per second (99.8 % of 230400 bps)22988 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes45613 milliseconds elapsed time114990 bits per second (99.8 % of 115200 bps)11499 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes91187 milliseconds elapsed time

author: oPossum
author_rank: Super Contributor
timestamp: July 05, 2019, 10:31:29 am
content: Quote from: PCB.Wiz on July 05, 2019, 10:15:43 amI don't have the new N version. Read about some bugs in them. Don't recall what the problem was.

author: oPossum
author_rank: Super Contributor
timestamp: July 05, 2019, 10:51:21 am
content: Fake FT232RL. Works better than the genuine FT232RL!Code:1042820 bits per second (34.7607 % of 3000000 bps)104282 bytes per second1048576 total written1032192 total read (98 %)1023132 total error bytes9898 milliseconds elapsed time1944680 bits per second (97.2 % of 2000000 bps)194468 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes5392 milliseconds elapsed time1485650 bits per second (99 % of 1500000 bps)148565 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes7058 milliseconds elapsed time993720 bits per second (99.4 % of 1000000 bps)99372 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes10552 milliseconds elapsed time748550 bits per second (99.8 % of 750000 bps)74855 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes14008 milliseconds elapsed time497820 bits per second (99.6 % of 500000 bps)49782 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes21063 milliseconds elapsed time249000 bits per second (99.6 % of 250000 bps)24900 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes42111 milliseconds elapsed time229760 bits per second (99.7 % of 230400 bps)22976 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes45637 milliseconds elapsed time114950 bits per second (99.7 % of 115200 bps)11495 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes91215 milliseconds elapsed time

author: magic
author_rank: Super Contributor
timestamp: July 05, 2019, 11:36:01 am
content: Quote from: PCB.Wiz on July 05, 2019, 09:45:44 amPL2303 drivers will do it too but the chip supports anything with 2% or better resolution, see Linux pl2303.c fileIt probably does involve some jitter, unless they use a PLL with bizarre ratios. Anyway, I found it good enough in practice.Quote from: PCB.Wiz on July 05, 2019, 09:45:44 amWake 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 05, 2019, 12:32:52 pm
content: Quote from: Siwastaja on July 05, 2019, 10:25:33 amThere 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 05, 2019, 08:41:39 pm
content: Quote from: Siwastaja on July 05, 2019, 10:25:33 amCertainly 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)

author: oPossum
author_rank: Super Contributor
timestamp: July 06, 2019, 01:01:47 am
content: A couple CP2102N tests by a friend.Code:855420 bits per second (28.514 % of 3000000 bps)85542 bytes per second1048576 total written835584 total read (79 %)831680 total error bytes9768 milliseconds elapsed time997120 bits per second (99.712 % of 1000000 bps)99712 bytes per second1048576 total written1048576 total read (100 %)0 total error bytes10516 milliseconds elapsed time

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 06, 2019, 03:26:01 am
content: Quote from: oPossum on July 06, 2019, 01:01:47 amFilling 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:Echo Duplex CP2102N :BAUD Setting Sustained speed2000000 ok at 8.n.1, Ctr : 1978.892181818 ok at 8.n.1, Ctr : 2181.812400000 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) = 305984E@ 213 LrS: 98 rS:55555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555555E@ 219 LrS: 95 rS:;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;E@ 220 LrS: 94 rS:<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<// TxLines : 3000 Rx Lines : 3000// Match Checks Pass: 2997 Fail: 3ie looks ok, all the way up to to 242.2k Bytes sec, each way, Duplex. - and fine at 300k bytes/sec one way.

author: sl1pkn07
author_rank: Newbie
timestamp: May 23, 2023, 04:46:04 pm
content: Hello @opossumcan 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 charactersi'm not sure is is a problem with comunication between both devices or just the usb donglegreetings