Building the worlds jankiest serial to USB cable from scavenged parts(github.com)
github.com
Building the worlds jankiest serial to USB cable from scavenged parts
https://github.com/francisrstokes/githublog/blob/main/2023/3/1/building-a-jank-uart-cable-from-scavenged-parts.md
10 comments
You're absolutely right, I don't know why I had attributed the name to the full duplex nature. And of course, there is also USART, where you can have a separate clock line, which allows you to omit the start and stop bits too. At that point, you're essentially turning your UART into a single connection SPI bus.
I miss USART.
Actually synchronous in this context has nothing to do with clock. It refers to the fact that the data does not come at regular intervals (synchronous), but asynchronously.
(A)Synchronous is a term of art. It precisely means what the GP said. Data can also not come at regular intervals for a synchronous setup.
I'm not sure why I expected more, but I was a little disappointed.
Soldering some wires onto an FTDI chip in a pinch is great, but the chip is doing all of the work really. I was hoping to learn I could make a serial to USB with _less than_ an FTDI chip.
That said, respect for the effort of taking the photos and writing it up, and it was worth a read to learn about those naughty Scots bricking peoples devices with bad drivers.
Soldering some wires onto an FTDI chip in a pinch is great, but the chip is doing all of the work really. I was hoping to learn I could make a serial to USB with _less than_ an FTDI chip.
That said, respect for the effort of taking the photos and writing it up, and it was worth a read to learn about those naughty Scots bricking peoples devices with bad drivers.
>expected more
It's the field - very wide range of ability. Some are stoked about making LEDs blink and others are busy dumping and reverse engineering ROMs. Just depends on one's own journey stage. In my case article is above my level...haven't dealt with UART before
It's the field - very wide range of ability. Some are stoked about making LEDs blink and others are busy dumping and reverse engineering ROMs. Just depends on one's own journey stage. In my case article is above my level...haven't dealt with UART before
Agreed, its a nice accessible article for beginners. I can see someone who has really only played with Arduinos and Adufruit modules looking at this and getting some inspiration to try out some of the techniques he mentions.
For example, you'd be suprised how many practicing EEs I've met who aren't aware drag soldering is a thing. (Which is a fantastic technique btw, saves so much time and gets you much nicer joints than individually soldering )
For example, you'd be suprised how many practicing EEs I've met who aren't aware drag soldering is a thing. (Which is a fantastic technique btw, saves so much time and gets you much nicer joints than individually soldering )
USB is hard... you need a chip to deal with it. "Back in my day", you could bitbang stuff with a parallel port, but those days are gone.
I would've picked a more lazy approach, just pull the atmega chip from an arduino (to not cause issues), and use the rx and tx pins on the (now empty) arduino board, since they're both connected to ftdi chip already, and no de/soldering is needed.
I would've picked a more lazy approach, just pull the atmega chip from an arduino (to not cause issues), and use the rx and tx pins on the (now empty) arduino board, since they're both connected to ftdi chip already, and no de/soldering is needed.
You can actually bit-bang low speed USB on Arduino [0]. There is even a bootloader [1] for ATtiny visible to host as HID USB device. It is obviously not compatible with Arduino, but those tiny boards look too cute to ignore [2]. Also, you can use USB port both for downloading firmware and your application.
[0] https://github.com/obdev/v-usb
[1] https://github.com/micronucleus/micronucleus
[2] https://cpldcpu.wordpress.com/2014/04/25/the-nanite-85/
[0] https://github.com/obdev/v-usb
[1] https://github.com/micronucleus/micronucleus
[2] https://cpldcpu.wordpress.com/2014/04/25/the-nanite-85/
Totally fair point. One of the videos I'm going to get around to making on my channel at some stage is a UART transceiver on an FPGA. Definitely not the "easier in a pinch" I was originally going for, but hey, if you've got the hardware hanging around!
I didn't mean for that to come across as a criticism, I was disappointed because I was hoping to learn something new, but I'm not the target for that post; I have a degree in Electronic Engineering and a couple of decades of tinkering.
I'll be interested in some FPGA content; I built my dissertation project on FPGA and would love to see some modern, affordable FPGA boards/circuits with useful I/O to actually build something like this. I'm sure they exist, I've just never looked.
Thanks for the interesting read and I'll keep an eye on your repo!
I'll be interested in some FPGA content; I built my dissertation project on FPGA and would love to see some modern, affordable FPGA boards/circuits with useful I/O to actually build something like this. I'm sure they exist, I've just never looked.
Thanks for the interesting read and I'll keep an eye on your repo!
No need to junk a perfectly good Arduino for that. Just load a trivial sketch that disables the Arduino's TX pin and just access the serial link through the D0 (RX0) and D1 (TX0) pins. Reversed of course; what's RX to the Arduino is TX to the serial chip.
This is the most use that board has and would have gotten in the last 10+ years. I like to think it laying down its FTDI chip for a greater cause was an honour for it.
My go-to serial adapter is an esp8266 dev board with EN connected to GND to stop the chip itself from booting. The TX and RX pins are then conveniently printed on the board - I just have to remember that, in this case, TX goes to TX and RX to RX, because it shows what's usually the chip's side of the dialog.
You don't even have to load a sketch to the Arduino. Just connect the RESET pin to GND. That will keep the Atmega IC on stop state and the TX/RX pins are free for what ever you need them to use for.
Maybe it’s covered and I just missed it, but why disassemble the Arduino when it has perfectly serviceable serial ports?
I mean, unless for fun, which is a valid reason in the context.
I mean, unless for fun, which is a valid reason in the context.
On top of that, it's enough to assert the microcontroller's reset to then freely use the RX/TX pins from the FTDI as if it wasn't there.
Just plain insanity.
As for cp2104 usb to ttl serial, full adapters using that chip cost $2 a pop on AliExpress.
As the prices are like that, I ordered a few of every available usb-serial chip at some point. I'll be fine for a long time.
Just plain insanity.
As for cp2104 usb to ttl serial, full adapters using that chip cost $2 a pop on AliExpress.
As the prices are like that, I ordered a few of every available usb-serial chip at some point. I'll be fine for a long time.
Yeah I was really questioning the point of removing it from a board where it has all the connections it needs in order to then make all those connections again! It’s a very nice write up but I was just left wondering “whyyy?”
Indeed - I know I could have also popped out the DIP micro on the board and used it directly, but I choose not to for two reasons:
1. Its so much bulkier, and I wanted something that was the same form factor as my old unit 2. It seemed way more fun to do things this way, and I was pretty sure I could do the whole operation in less than an hour
1. Its so much bulkier, and I wanted something that was the same form factor as my old unit 2. It seemed way more fun to do things this way, and I was pretty sure I could do the whole operation in less than an hour
Clearly you should have compromised and hacksaw'ed out the usb jack + ftdi region of the board, thus satisfying both your desire to have something jankey and compact. You would even get free activity LEDs!
Or you know, pop the Atmega out
He's not using the Arduino Uno for anything useful, its just a test jig to check the cable works. He says at the start of the article that he needs a USB-UART converter to work with another project.
I'm assuming that project doesn't have its own USB-UART like an Uno.
I'm assuming that project doesn't have its own USB-UART like an Uno.
As the comments above mentioned he could have left the FTDI chip on the arduino board and just used it that way. Moving it to the breakout board didn’t do anything but save some space
Something I'm sure every tech person has mused about now and then: In the case of an apocalypse or cataclysm, how much of our current digital data would we be able to scavenge?
My favorite "arduino-apocalypse" is CollapseOS: https://hn.algolia.com/?query=collapseos
[deleted]
A small STM32 and libopencm3's USB stack would be a more flexible choice. You could for example set your own name, PID/VID, etc.
With some clever setup of descriptors, you could even have multiple UART serials to one USB connection.
With some clever setup of descriptors, you could even have multiple UART serials to one USB connection.
I think the point was to make something in a pinch with what was already available versus making the most flexible choice.
That being said I use, I'm not the author, https://github.com/Noltari/pico-uart-bridge to turn a Raspberry Pi Pico into a USB to dual UART adapter. It appears as a CDC-ACM device so is supported under Linux and Windows without any 3rd party drivers. I replaced my MacBook Pro with a Thinkpad years ago so I have no idea what the situation is on macOS.
That being said I use, I'm not the author, https://github.com/Noltari/pico-uart-bridge to turn a Raspberry Pi Pico into a USB to dual UART adapter. It appears as a CDC-ACM device so is supported under Linux and Windows without any 3rd party drivers. I replaced my MacBook Pro with a Thinkpad years ago so I have no idea what the situation is on macOS.
Or a $4 RP2040 board.
tldr; for those who didn't bother to look for "an explanation" of why the wires were soldered directly to the pins of the IC instead of THE BREAK-OUT BOARD...
> Now, you're probably thinking to yourself: "Why would you not just solder to the nice, big, widely spaced holes for the pin headers?", which is a fair question. I suppose this the one place I opted for a little less jank. You see, differential pairs actually require the length of wires and signal traces on a PCB to be carefully controlled. In theory, if the plus wire was a little longer than the minus wire, the two signals would arrive at the chip at very slightly different times. That would mess up the signal integrity, and maybe even prevent the device from working. All of that said, I'm almost certain that this wasn't required at all.This could end up being worse from a signal-integrity point-of-view, as now both of those traces have a stub (of different lengths!), which will comb-filter the signal.
If you wanted to be fancy, it would have been better to lift those two pins, or to cut the traces.
All this is completely unnecessary given the speeds involved (12Mbit/s) and possible skew or stub lengths, which they acknowledge.
If you wanted to be fancy, it would have been better to lift those two pins, or to cut the traces.
All this is completely unnecessary given the speeds involved (12Mbit/s) and possible skew or stub lengths, which they acknowledge.
Why did they solder the USB cable wires directly to the chip pins instead of the corrisponding hole on the breakout board???
He explains that in the post.
Still, this part stuck with me so I feel a need to comment:
The high level overview is that "serial", or UART (Universal Asynchronous Receive and Transmit) is a protocol for exchanging data between two systems over two independent wires, with each side able to transmit and receive simultaneously, without those two lines necessarily being synchronised (hence "Asynchronous" in the name).
I would argue that "asynchronous" here means that UART traffic is not explicitly clocked; there is no CLK signal to go along with the TX and RX lines for the data. This is of course because both sender and receiver have to already know and agree about the communication speed ("baud rate", which is actually just bits/second at this level) or they will get garbage.
This is in contrast to synchronous serial protocols like I2C and SPI which both have a clock signal.