The beautiful simplicity of the serial port (posted 2020-02-02)
Today, I got a new USB-to-serial adapter. When trying to figure out how to connect a DEC VT420 terminal to a Mac, I learned that as of version 10.9, MacOS has a built-in driver for the FTDI USB-to-serial chip. So I ordered a "USB-console cable" from Amazon. This is a cable that looks a lot like a Cisco console cable but with a USB connector at one end. As the name suggests, you can connect it directly to the console port of a Cisco router. And with the right RJ-45-to-DB-25 / DB-9 adapters, you can connect it to anything with a serial port.
Back in the day before USB took the world by storm, we had all kinds of different ports on our computers to connect to all kinds of different peripherals. To me, the serial port was the most interesting of those. Behind it was a modem that connected to the rest of the world, and in the early days, you directly talked to that modem by sending key presses over the serial port.
Async = simple
All communication that leaves a computer is serial these days. But these are complex synchronous serial protocols that require a good deal of software. The serial port as we know it, on the other hand, uses asynchronous serial communication. That means that each character is transmitted individually. The serial port does this by first sending a start bit, which is a voltage that indicates "zero", followed by the data bits, and then a stop bit which is the voltage that indicates "one". The line then stays at the "one" voltage until the sender wants to transmit the next character.
The cool part about this is that it doesn't need complex timing mechanisms. In serial communication, there's always the issue of keeping the sender and receiver in sync: did I just receive 93 zero bits or 94? Suppose the sender transmits at 1200 bits per second. That's a bit every 833 microseconds. But what if the receiver is running too fast, and checks for a new bit every 800 microseconds? That means that when the sender has sent 24 bits, the receiver has received 25. But because we restart the clock at every start bit and then only transmit about eight bits, this isn't an issue here. Of course the downside of this is a rather large 25% overhead for a start and a stop bit for each character. As each character is sent individually, the line can simply remain idle between characters, waiting for the whole process to start over when the next start bit arrives.
Flow control
Like I wrote last week, "back in the day, we used RTS/CTS flow control". That was necessary once modems implemented error correction and data compression. This meant that there was no longer a direct relationship between how fast data flowed between the computer and the modem and between the two modems at both ends of the connection. Deviating from the RS-232 standard, modems would use the CTS (clear to send) pin to indicate that it was ready to receive data, and vice versa, the computer would use RTS (originally request to send, later modified to RTR, ready to receive) to let the modem know it was ready to receive data. This is what is known as RTS/CTS or hardware flow control.
However, dial-up modems are completely obsolete now—in parts of the world that I'm familiar with, at least. And with them, RTS/CTS flow control. I did some experimentation with different devices, and enabling hardware flow control either did nothing, or made it impossible to communicate. So: don't use RTS/CTS hardware flow control unless you're positive you need it.
Yost serial device wiring standard
Originally, RS-232 uses a DB-25 connector, later shrunk to what I call DB-9 but is apparently called DE-9, which was the standard serial port on PCs. Modems (DCE = data communicatons equipment) receive on the pins that computers and terminals (DTE = data terminal equipment) send on, and vice versa. So if you want to connect two DTEs, you need a crossover or null modem cable. This easily makes for six different types of cables.
To solve this, back in 1987 Dave Yost came up with the idea to make the whole system modular, by having connectors with DB-25 or DB-9 on one end and RJ-45 on the other hand, and then simply connect the appropriate connectors with an 8-wire RJ-45 cable. The neat part is that the cable is always a crossover cable, so there's no longer separate straight through and null modem cables.
In a Cisco console kit, you'll find the DB-25 male (to DCE) and female (to DTE) connectors, as well as DB-9 female (to DTE) one. I needed another DB-25 female one, so I got a connector that lets you modify the pinouts yourself. Turns out that it uses the color coding described in Dave Yost's wiring document. Nice.
I tried my new console cable with each of these adapters, and they all worked. And of course it directly plugs into a Cisco console or aux port.
Software
I've been using Zterm for a very long time to talk to Cisco routers, but it turns out that there's an even more straightforward way to do this: with GNU Screen. Screen is installed on MacOS out of the box, and is mainly used as a character-based "window manager". But for our purposes here we can use it to talk to a serial interface by typing the following in a terminal window:
screen /dev/cu.usbserial-A9IWGQ7P 9600
9600 is the serial port speed and A9IWGQ7P is the serial number of my USB console cable, find the name of yours with:
ls /dev/cu.usbserial*
Once you're in screen, the first thing you need to know is how to get out again: by typing control-a and then k. You can also type control-a :info to get some info on the state of the serial port.
