4 ms·
UART at TTL levels, it's dead-simple and ubiquitous. Everybody should own a USB-to-UART dongle, as it'll be useful more often than not. I recommend the ones ba
by snvzz 4y ago
UART at TTL levels, it's dead-simple and ubiquitous. Everybody should own a USB-to-UART dongle, as it'll be useful more often than not.
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.
- sebcat 4y agoIf you're into electronics, having a couple of MCP2200 in your drawer is also handy. Gives you some GPIOs as well.
- denysvitali 4y agoWhat's more interesting is that you can use two USB-TTL converters and debug / connect to another machine (or for example see the Linux kernel logs).
- snvzz 4y agoOutputting text on a serial port that's directly available as io ports or mmio is of course trivial. 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.
- Nursie 4y agoThey tend to show up as ttys and be easily usable to get a linux login console after the kernel has booted. You're not going to be using them to interact with (say) the u-boot bootloader on an embedded board, but if your machine has disappeared off the network and you're pretty sure the kernel is at least booting, you can sometimes use one of these to figure out wtf has gone wrong.
- snvzz 4y agoYes, even if USB attached, a serial port is definitely useful to get a console when network does not work. What I meant is that it will likely not help debugging when there's kernel or hardware issues.
- johnwalkr 4y agoThat’s true but it’s a step up in your game from attaching a keyboard and monitor at first. You can also do this over Bluetooth pretty easily.
- matja 4y agoJust poking some registers to send an Ethernet frame kind of hand-waves all of the ACPI table lookup, AML parsing, PCIe root/bridge init, etc, so in that regard "mov dx,0x3f8 ; out dx,al" is more simple and reliable - USB needs all of the same PCI/PCIe stack also so is of course a nightmare :)
- Gordonjcp 4y agoNow what you do is, you get four of 'em, two wired back-to-back and two with their RX pins wired to the RX and TX pins of the first pair. Now you can connect two machines via serial, and sniff traffic with two serial ports on the third.
- snvzz 4y ago>sniff traffic 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).
- Nursie 4y agoThey are very useful. 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...
- tecleandor 4y agoAlso, I remember the "FTDI-gate" with the ch340, where FTDI updated their driver to break ch340 clones (that are nearly ubiquitous and sometimes indistinguishable). Can't remember how that ended.
- snvzz 4y agoWhile ch340 are a dirt cheap solution (the chip is cheap, and it is a single chip solution thanks to the internal oscillator), it is not a FTDI clone. 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.
- poizan42 4y agoThey claimed they were targeting counterfeit FTDI chips. But in reality they have no way of telling the difference between a counterfeit and a clone in software - after all the only difference is what is written on the IC package/what the seller claims it to be.
- blueflow 4y ago> But in reality they have no way of telling the difference between a counterfeit and a clone in software USB devices have a vendor/product ID that is used for driver selection. The ones for the FTDI and ch340 are different: https://the-sz.com/products/usbid/index.php?v=&p=&n=FTDI https://the-sz.com/products/usbid/index.php?v=&p=&n=FTDI https://the-sz.com/products/usbid/index.php?v=&p=&n=ch340 https://the-sz.com/products/usbid/index.php?v=&p=&n=ch340
- poizan42 4y agoCH430 is not an FTDI clone as far as I can tell, so i'm not sure how this is relevant? 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.
- aa-jv 4y agoAll self-respecting nerds should have a Bus Pirate, you mean: http://dangerousprototypes.com/docs/Bus_Pirate_v4_design_overview 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 https://www.crowdsupply.com/securinghw/tigard EDIT2: Bollocks. Doesn't ship to Europe. Ah well, here's another option: https://hydrabus.com/?v=fa868488740a https://hydrabus.com/?v=fa868488740a Oh, well, may as well add Option 3 as well, since this is an interesting subject: https://www.crowdsupply.com/1bitsquared/glasgow https://www.crowdsupply.com/1bitsquared/glasgow
- blueflow 4y agoI have two of these configurable adapters, too. But i don't use them anymore. I don't have the control programs installed on every machine, i don't remember their settings... in the end of the day i always use the cheap ch340 one because its stateless, because it doesn't have any persistent settings. I grab one from the box and don't get surprises.
- snvzz 4y agoI own a bus pirate. 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.
- auxym 4y agoI like this one personally: https://makerdiary.com/products/pitaya-link 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).
- dfox 4y agoToday you are probably better off owning RPi-pico and just bitbanging (or in the rare case when it is needed the PPI comes in handy) the whatever bus you want to interface to in microPython.
- johnwalkr 4y agoAnd do get 2, for 3.3v and 5v signals.
- heffer 4y agoI have not had any problems with the newer CH343. See this tweet by WCH Technical Director Patrick Yang: https://twitter.com/Patrick_RISCV/status/1516015859877093376 https://twitter.com/Patrick_RISCV/status/1516015859877093376 WeAct Studio makes a beautiful compact CH343P adapter that comes with USB-C.
- snvzz 4y agoFrom the datasheet: >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.
- nrclark 4y agoI 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%.