I recommend the ones based cp2104 chip. They are cheap ($2 in ebay or aliexpress), reliable and have good support across OSs.
I suggest to avoid ch340. They have low clock accuracy (likely to do with using internal RC osc instead of an external XTAL), which causes corruption and/or dropped character issues both sending and receiving.
http://dangerousprototypes.com/docs/Bus_Pirate_v4_design_ove...
.. or something similar. I've heard rumours of a better device than the Bus Pirate out there, but I live by my Bus Pirate and I'll die by it too. ;)
EDIT: Here it is, the Tigard:
https://www.crowdsupply.com/securinghw/tigard
EDIT2: Bollocks. Doesn't ship to Europe. Ah well, here's another option:
https://hydrabus.com/?v=fa868488740a
Oh, well, may as well add Option 3 as well, since this is an interesting subject:
Today, I'd instead recommend a serial adapter based on FT232H or variants. Good UART speed, hardware handshake if needed, and a bunch of GPIOs.
https://makerdiary.com/products/pitaya-link
It's both a USB-UART bridge and a debug/programming adapter for ARM microcontrollers, for 11$.
Based on a microcontroller itself, with open firmware and some extra exposed pins so it's hackable if you wish (but it works fine ootb).
For serial, I end up using dedicated adapters. Terminal for text, custom python script for binary protocols.
For I2C, I have some USB dongles which appear as /dev/i2c-* devices. Use bash + i2c-tools to debug, then switch to python for more complex stuff.
For unusual protocols, I can use Arduino(clone) directly. Sometimes this needs a trivial interactive handler, like '2' to toggle CS2 line and 'x' to shift in 5 bits.
The problem with BusPirate is that you are not going to integrate it into your device, so whatever scripts you write to it will need to be rewritten for "real" thing. And its interactive mode is pretty limited and you grow out of it very quickly.
I used one (an old nokia cable that had been hacked apart) a few years back to get a serial console on my WD Sharespace, so I could figure out how I was going to get debian running on there, interact with the bootloader etc. It was a fun project.
Start with the multimeter, probe for some pins that look like they might be around the right voltages. Next, if you have shell access, cat some data down the port and see if what you think is the TX pin starts to look more alive, then attach your dongle to the likely-looking pins and away you go...
WeAct Studio makes a beautiful compact CH343P adapter that comes with USB-C.
>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.
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%.
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.
1. (p144) https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-2486-...
Can't remember how that ended.
It presents its own interface to the computer and uses its own drivers.
What FTDI did was specifically targeted against fake FTDI chips. Note that this is no less horrible; FTDI has no business intentionally bricking anybody's chips.
USB devices have a vendor/product ID that is used for driver selection. The ones for the FTDI and ch340 are different:
If you want existing drivers to "just work" with your clone device[1] then you need to return a vendor and product id it already recognizes. Lying to a computer does not make you a counterfeiter (and copying responses verbatim for interoperability purposes is pretty strongly protected, see e.g. Sega v. Accolade)
[1]: After all the whole point of making an FTDI clone instead of just implementing the standard USB communications device class was to get Windows support before Windows 10 introduced support for serial via CDC out-of-the-box.
Unless I'm missing something important, there's no such mechanism for usb-ttl dongles.
I'd much sooner trust netconsole than the whole usb stack, as sending an UDP packet while bypassing the whole network stack is surprisingly trivial. Just poke some registers. No interrupts needed.
What I meant is that it will likely not help debugging when there's kernel or hardware issues.
Now you can connect two machines via serial, and sniff traffic with two serial ports on the third.
You can just wire up a $10 logic analyzer, that way you can even deal with changing speeds and partial messages (e.g. reset during TX).