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.
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.
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
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 )
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.
[0] https://github.com/obdev/v-usb
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 mean, unless for fun, which is a valid reason in the context.
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.
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
I'm assuming that project doesn't have its own USB-UART like an Uno.
With some clever setup of descriptors, you could even have multiple UART serials to one USB connection.
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.
> 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.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.