>The allowable baud rate error of CH343 UART receiving signal is less than 2%, the baud rate error of UART transmitting signal is lessthan 1.5%.
They're still bad. Presumably due to the builtin clock (probably RC, not XTAL). There might also be no supersampling.
(A good implementation will be close to 10% tolerance)
>I have not had any problems with the newer CH343.
Most people will indeed not have issues, thanks to short wires and good (as in better than this uart chip) implementations in the other end.
But when interacting with bitbanged uarts (cheap microcontrollers w/o uart hardware) or otherwise clocks divided from video clocks (typical with retrocomputers), bad tolerance will be a problem.
Of course, for some UART bundled in an arduino-style devboard, a ch340 or variant will likely be more than good enough. For an USB to TTL adapter, however, I'd insist on something better, such as cp2104. No reason to compromise when they go for around $2.
I have never seen a UART receiver that has 10% tolerance on the input baud-rate. I don't think it's even possible from a mathematical perspective, at least if you want an error-free transmission.
A standard UART byte consists of (start-bit + 8 bits + parity bit + stop bit), totaling 11 bits for each data byte.
If you were sampling at the ideal location (right in the middle of each bit), then you'd have a maximum of 50% phase-error before you slipped a bit boundary (assuming an infinitely fast rise-time). That means you can accumulate no more than 4.5% phase-error per bit (50% accumulated error / 11 bits).
That corresponds with a 4.5% total frequency mismatch between the transmitter and the receiver. Assuming worst-case corner cases, that's 2.25% maximum allowable error from each. Note that this is the theoretical best-case, assuming your sampling clock is infinitely fast. In practice, (baud-rate x 16) is a common sampling rate - which quantizes your phase-error and gives you even less margin.
And that's why you tend to see UART baud tolerance that's around 1-2%.
It is an interesting problem, and it has of course had some analysis done to it over the years. I particularly like Analog Device's take[0].
Note that the standard UART byte (8N1) has 10 bits (1 start + 8 data + 1 stop). Use of parity is not at all common. To accumulate 50% you need to be 5% off per-bit.
This is the naive approach, with a single sample in the middle of the bit. Super-sampling and clever clock recovery tricks can get you much better tolerance. An example such as the +4.58/-4.54 on the whole message even older atmega8[1] achieve. They are not even chips designed to be dedicated to UART. This is pretty good, while still working bit by bit.
A strong implementation can go considerably further by super-sampling the whole message, and sampling past the expected end. By super sampling the whole message and an extra bit, you can get to that 10%, or tolerance of clock being off by a whole bit.
ch340 and variants likely do not supersample at all, in addition to using a poor (not xtal oscillator) clock source, and that's why they do that poorly.
>The allowable baud rate error of CH343 UART receiving signal is less than 2%, the baud rate error of UART transmitting signal is lessthan 1.5%.
They're still bad. Presumably due to the builtin clock (probably RC, not XTAL). There might also be no supersampling.
(A good implementation will be close to 10% tolerance)
>I have not had any problems with the newer CH343.
Most people will indeed not have issues, thanks to short wires and good (as in better than this uart chip) implementations in the other end.
But when interacting with bitbanged uarts (cheap microcontrollers w/o uart hardware) or otherwise clocks divided from video clocks (typical with retrocomputers), bad tolerance will be a problem.
Of course, for some UART bundled in an arduino-style devboard, a ch340 or variant will likely be more than good enough. For an USB to TTL adapter, however, I'd insist on something better, such as cp2104. No reason to compromise when they go for around $2.