The RS-232 protocol [video]
youtube.com
youtube.com
RS-232 and RS-485 are just so reliable. The higher voltage of +/-12V makes it more resilient to noise, and the protocols are just simple. It isn't the fastest around, but it can still be pretty fast depending on how the protocols are implemented.
Well... as long as everyone has their configuration correctly hand-configured. As the video states, RS-232 doesn't have any way to transmit a clock. So if one end is talking 9600 baud and another wants to talk at, say, 56000 baud, then... no it doesn't just work.
Your experiences with USB sound incredibly frustrating. But RS232 can also be crap in its own unique ways.
But to be fair, I do still rather like working on well behaved RS232/422/485 equipment, where you plug it in, set it to 9600 baud 8N1, and you just start seeing a stream of easily parsed text scrolling down your terminal :)
You are right on about the joy of it being 9600 8N1 on the first try.
Having both a null modem and a gender bender end-to-end was common.
These aren’t dead technologies by any stretch, not that you were implying that.
Real techs knew them as "gender changers" which was different enough to be recognizable as only a technical term for cable connectors.
I’ll bet you’re not a native English speaker. Nothing wrong with that, btw.
Seems pretty spot-on to me.
Sorry if you don't see the pejorative connotations in the other term. We avoided it because we didn't wish to offend people.
You remind me of one of the tech leads I have the occasional displeasure of interacting with. He'll blow in with some new work for us to do, and a stack of reasons to do it. The topmost in the stack he'll provide, and the rest of the stack he keeps hidden. The problem with his stack of reasons are twofold:
1) It takes no less than five and -typically- fifteen minutes to get through the stack.
2) Only the reason at the base of the stack is non-bogus. All of the others are calibrated to sound _great_ to folks who don't work on the thing (and talk to customers who use the thing) day in and day out.
Next time, start with the reason at the bottom of your stack when you're talking to technical folks like us. ;)
Laplink cables had DB-9 and DB-25 on both ends with the crossover built-in.
There were some male to male cables that had crossover while others didn’t. Then there were null modem adapter dongles for straight through cables. They were either male-female or male-male depending.
Reminds me about older Ethernet: before Auto-MDI/MDIX on most NICs and switches, crossover RJ-45 cables were needed.
Issues like one device got a slightly different baud rate, enough to make it either not work at all or having a lot of transmission errors?
I have, and I'm sure a lot of other people have their own horror stories.
Having a clock signal, like in I2C, solves that.
Oh and that "oops, just connected 12V RS-232 to a 3.3V device," and see the magic smoke getting away...
The voltage thing is real (and real stupid IME) but we never ran into clock issues that would skew baud rates one way or another.
I2C is terrible in so many ways. (Don't send it off-board. Just don't. Ever. Trust me on this one. I don't care what you read about the bus capacitance spec, do. not. do. this.) Sending out a clock on a 400pF on-card bus isn't too bad, but when you have a kilometer-long cable... yeah, we'd rather not send a clock down that, thank you. Hence the use of self-clocked or pray-we-have-similar-clock-frequencies protocols.
3.3V or 5V devices aren't RS-232 and people need to be careful about that. They're just UARTs with regular old logic levels. RS-232 or 422 or 485 are Serious Business levels to go out and do battle with the mean Real World and the only place they should ever land is at a dedicated transceiver. Full stop.
The root of the problem is that I2C has serious EMC immunity issues. It's well known and appreciated that its drive is weak and open-drain. The bus buffers and especially differential drivers can and do help there. (And will get you past a meter.) What's less well recognized is that a single glitch pulse on SCK knocks all the internal state machines out of whack and requires a bus reset to fix them. Hope you're doing that when your bus is idle or when you're getting anomalies! Most people don't. The Nexus 4 phones sure didn't; this is why their light sensors went dead or crazy or both after a while of uptime.
All of that gets easier to handle if there's a nice, big, low-impedance ground plane nearby, which is why you don't see so much trouble when it stays on the PCB.
Maybe or maybe not. I ran 12V RS-232 levels into a 5V Atmel 8515 for a year or two 24/7 without issues, and tens of thousands, maybe more, have too. And that's a CMOS part.
(This was for a paytv interface sitting between an iso7816 slot and an x86 based emulator. The Atmel 8515 did the inversion in software).
The RS-232 on the PC side would have no issues with interpreting +5 as logic0 and 0V as logic1.
Some would setup a Max232 or Max233, but it wasn't necessary.
Others would use an MC1489 to at least convert the -12V and +12V into 5V and 0V by doing an input and then output into the chip, but again, it was out of caution and not actually necessary.
You can overcome the baud challenges with scripts that loop through common baud rates until alpha numeric characters are found.
It's also nice that the same few windows applications have been in use for 20 years or so (I specifically worked with RS232 to TCP/IP).
As I recall, there was a 1990s Macintosh where the serial port used a proprietary connector (of course) with fewer pins, so Apple decided to double up and use one pin for both Data Terminal Ready (DTR) and Clear to Send (CTS). (Or we had cables that connected two pins?)
Many modems would hang up if you dropped DTR. Enabling this is a good practice to prevent the modem from accidentally staying connected after you're done.
Enabling hardware flow control is also a good practice. If the Mac can tell the sender to wait for a moment, that's better than dropping data.
Perhaps you can see where this is going. If you enable both of these, everything appears to work fine for a while. That is, until the Mac falls behind (scrolling a lot in a terminal window, for example) and needs to actually use hardware flow control. Then, rather than pausing the flow of data, it hangs up the modem.
And your first thought when a modem hangs up out of nowhere is that it's a modem issue: noise on the phone line, a bad modem implementation, an incompatibility between two different modems, etc. So you waste time looking at those as causes.
The solution was to either disable hardware flow control or to configure the modem to ignore DTR and use +++ ATH to hang up instead. Disabling hardware flow control makes PPP (etc.) perform horribly because packets get corrupted and re-sent. And this is another deceptive problem because the modem speed appears to have plummeted but actually the modem is working fine.
Hmmh, I rather have a love/hate relationship with it. It depends on context, I suppose. In an earlier era, Unix servers (and non-Unix Minis before that) and other equipment (some network routers and switches to this day) offered their system console via RS232. 9600baud 8n1 was common, but not universal. The developers in charge of our enterprise file server were impatient and hard coded the console to 115200baud (because that was the maximum speed PCs generally supported at that time), which not all "console servers" were able to cope with ...
Then was the question, how is it wired? DTE or DCE, i.e. do I need a null-cable? Flow control? And if it's not a DB9 or DB25 connector, but a RJ11 all bets are off and you need to find the manufacturer's cable.
Here’s looking at you, Cisco, for using an RJ45 serial connector on devices covered in RJ45 Ethernet jacks.
Just needed RX, TX and GND for our purposes.
Ran at 115k2 too.
USB is also a serial protocol on the wire ;-) But there are so many layer of complexity on the top that make it indeed a nightmare in many situation.
I worked with a control system using USB, where the connection to the controller had to last for weeks. Regularly, the device stopped working (usually entirely disappearing from the device list) and I had to add support on the software to transparently allow the device to return (and people had to unplug and replug the board when receiving the "device disappeared" alert). Same stuff on RS-232 just worked without a single issue...
Your example is exactly the type of stuff I had in mind. We had the same issue with a camera. We also wanted to power cycle part of the system, since the camera was water cooled to turn it off, but this was basically impossible with the USB communication without farming out the camera communication to an entire other OS process/program such that the communication could be restarted. That manufacturer, for whatever reason, only implemented streaming the images over Camera Link but didn't implement their settings over Camera Link. And I swear to god, another USB camera in the same system wouldn't work through a hub and only worked reliably when directly attached to a specific USB port on the computer. Mindblowingly frustrating.
No software drivers needed either.
Long story short (it was 30 years ago so I also can’t remember the precise diagnosis) there was corruption on the line in that sometimes when you typed a space it would come out as something random. Few other characters were corrupted as often, if at all. It was almost always spaces that were showing up as random other characters.
My observation was that space was encoded as 00000 — all low, the printed character most susceptible to line noise — and that something wasn’t grounded. Smarter people took my observation, figured out what was wrong, and soon all was fixed. It felt like, for the first time, I understood the system with a depth I’d not had before. It was cool.
Oh, and playing DOOM for the first time over RS232, too. Another precious memory indeed!
The only explanation I could think of was a faulty ground connection. The scope was grounded through the wall socket same as the CNC and thus had the same ground potential. My laptop on the other hand was running on battery and only shared ground with the CNC through RS232 pin 5 (signal ground). However it seems this pin was not correctly connected on the CNC side and thus I was unable to transmit any data. Experimenting a bit I tried to connect ground to the connector shield instead and everything worked perfectly.
Took me a long time to figure that one out haha
I have used my laptop on battery, with a USB-to-RS232 adapter, to control a telescope remotely and it worked fine IIRC.
> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.
Tl;dr I think 'Ben Eater is back' is an interestintg post in its own right, possibly more interesting than this particular video considering the typical [video] reception.
(Longer-term higher-complexity suggestion: could YouTube links have the channel name somehow, like we now have /<name> for GitHub, Twitter, et al.?)
A concrete suggestion:
> Ben Eater's back: RS-232 protocol [video]
Or to be more subtle, just append '(2022)' (and confuse people who aren't familiar or aware of the absence):
> Ben Eater: RS-232 protocol (2022) [video]
There's another aspect too: everyone misses a lot of interesting and/or important stories. Even the few who are paid to stare at HN all day. There's too much coming through at all hours. It doesn't make sense to try to avoid that, because it's impossible.
I'm sure this is a highly unsatisfactory answer!
You're under no obligation to satisfy me! I was just offering my point of view in hopes that you find it informative, so that you can take it into account in the future when you're thinking about how to change the way that HN works.
"The negative voltage requirement of RS-232 is why some ATX power supplies still provide a negative voltage reference on one of the pins. The power supply manufacturers want to provide it in case the end user has a motherboard that uses on board RS-232 (some industrial motherboards still use it). usually the available current for the negative voltage reference is pretty small though (around 1 amp or less)"
Edit: Apparently called 'Integrated charge pumps'
(If you are interested into x86 breadboard stuff, please check The 8088 Project Book - which is a great intro befor jumping into more advanced stuff).
BTW I have a PoC of using C with Ben Eater computer - https://github.com/marcin-chwedczuk/ben-eater-6502-ansi-c I do not have time to dig deeper into it yet, but looks promising. The only problem with 8-bit processor is that they use first page of memory to pass extra variables because stack is too small (256 values in total, yup).
Just for some background: in college I took an introductory digital logic class and loved it, but then I moved over to a humanities degree and lost a lot of that information. Then I started programming again, but mostly as a "self-taught" web developer-- not to undercut my high school and college work (I was on a HS programming team that was competitive), but most of what I use in my day to do day life are things I picked up from having to do increasingly difficult projects/tasks as a programmer interspersed with ocasional seasons of motivations where I'd pick up new techniques (functional programming, server management, front end web rendering frameworks, etc).
Ben Eater's long series on building a computer out of 65c02 and then his longer series on building a microprocessor from TTL logic chips hit an incredibly sweet spot for me.
I'd spent some time trying to teach my kids how to do basic electronics (building things like 555 timers or little robots with pi's for controllers, so I have some familiarity with the topic.
I suppose if I had the time and were motivated, I could have gotten some textbooks and learned the same material. However, his material was setup in a way that made it very easy to grasp as a passive consumer of the video. It feels like it covered the topic as deeply as I was interested and answered a lot of questions as it went along.
So, as a person who has enough familiarity with the concepts to find it interesting but no pressing need to master the material deeply, I highly recommend his work.
I would be curious to see an evaluation of the collective cost of USB + Bluetooth over the decades since their inception.
I've seen the guts of USB drivers a long time ago, I could not describe the horror.
RS-232 is still used for connecting to some embedded chipsets. Best example would be modems/4G modules. You can pick either RS-232 or USB, however sometimes on that little microcontroller you're using it won't have USB. If you don't need a huge amount of throughput then the serial port is fine.
RS-485 as others have mentioned is great. Often you can't run new cables for cat/fibre so you're stuck with stealing some copper off an old system that has been decommissioned. You'd be surprised how far you can run a RS-485 system at low speed and maintain high reliability.
Is this just for control of the modem or for data transfer too? How are 4G bitrates supported by this protocol?
https://en.wikipedia.org/wiki/Qualcomm_MSM_Interface
I think non SoC high performance modems use USB.
Regarding older or less integrated modems that do use the 232 interface, this may be illuminating:
https://fahrplan.events.ccc.de/congress/2011/Fahrplan/attach...
To clarify I was referring to the modules that the average person can get their hands on. If you rip open the module (or look at the FCC paperwork) you'll likely see a Qualcomm chipset underneath. It's just a level of abstraction really.
You picked up the drawback: speed. You can't pump 4G speeds over a serial port. Depending on what you're doing through, the 'slow' speeds you get over a serial port are more than enough to serve your purpose. The 4G part is about connectivity and not speed in many cases. Locally we're seeing 3G shutdown and it won't be around for much longer.
Obviously better solutions exist for low data usage over cellular - have a look at NB-IoT or LTE-M.
> This video explores the electrical and timing characteristics of the RS-232 protocol.
I mean, it's close enough and it works
Interesting that the bit-level protocol is still very widely used today, even if the signalling is now more likely to be 5v or 3v3 TTL signalling bridged to USB.
When RS-232 came along, they deliberately specified a very wide band of allowed voltages so that in many cases manufacturers could just cable the current loop device in parallel with a resistor and be compliant.
Don't quote me though, I don't remember where I read this.
[1] So... yeah, it's basically solving the same problem as differential signaling but at a different scale.
It's a telco thing. Polarized signaling goes back to the original Edison stock ticker. Polar relays were once used on Teletype circuits.
This helps to compensate for unavoidable differences in absolute ground potential between remote locations.
The data signal is basically just square waves since it's ones & zeros, but hook a speaker up properly and that's the unforgotten audio sound of dial-up internet.
It was way back in RS-232B when the Mark and Space were reversed.
And the standard called for robust performance with all circuits not affected by any miswiring up to +/- 25 VDC on any pin at any time. Must not requie powering down before connecting/disconnecting.
DCE really meant Data Communication Equipment, i.e. primarily Bell-approved acoustic telephone modems (to be operated back then no faster than 300 baud when using their monopolized land lines).
So a DTE was Data Terminal Equipment which means a regular "dumb" terminal which is just a keyboard and CRT display with an RS-232 input/output having the D-sub (male) pinout according to the DTE pinout scheme. A PC is a lot more powerful but with a terminal app or the correct tty i/o your keyboard, display, and motherboard 9-pin D-sub (if available) will do it better than ever.
In the video, he's connecting only the transmit pair from his terminal, not shown would be the handshake lines which are, as seen, actually "optional". Not really but with lots of hardware if the recieving DCE end were not able to signal Data Carrier Detect (DCD), Data Set Ready (DSR), and Clear to Send (CTS) on the proper handshake lines back to the DTE terminal, there was going to be no data coming out of the terminal from pin 2 for you.
I would expect in the software of his RS-232 adapter, that he has continuously enabled the handshake lines needed by the PC to recognize that his external device is ready to recieve. So he therefore needs no extra conductors between the devices to accomplish that handshake purpose.
The DTE terminal would ideally signal power on and buffer ready on the DTR and RTS pins or the modem would speak not.
On the DTE the outputs are Data on pin 2 and logic on DTR and RTS. The inputs are Data on pin 3 and logic on DSR, DCD, and CTS.
On the DCE the outputs are Data on pin 3 and logic on DSR, DCD, and CTS. The inputs are Data on pin 2 and logic on DTR and RTS.
The default concept was supposed to be a cable with straight connections between pins 1, 2, 3, 4, 5, 6, 7, 8, and 20 of a male and female D-sub 25 connector at each end. On the hardware, the DCE modem had the female D-sub and the DTE terminal had the male D-sub, so it was just a straight cable. Multiple cables could be used as extension cords. Good for hundreds of feet with careful wiring considerations. In the abscence of handshakes only two conductors needed for one-way communication.
On the first PCs there were two D-sub 25 pin connectors on the back, the female was a (ribbon cable) bus parallel port for the printer, and the male was an RS-232 serial COM port for use to connect to a telephone modem.
When the mouse came along they were RS-232, most people did not have a modem yet (why would you want to connect to someone else's computer anway?), so there was an available port. Connector was downsized to 9-pin with partial pin renumbering.
Actually you could always connect two PC's together and bypass the handshake settings in software if your buffers were adequate, you only needed 3 conductors; a ground with 2 & 3 crossed over. There is also the optional XON/XOFF software handshake otherwise which is signaled within the data stream instead of needing excess conductors in the cable. Or you put a local jumper between some handshake pins at one or both ends of the cable to force the handshake logic if you didn't truly need the extra logic conductors between your target devices.
On any one connector, there should be a couple handshake pins (other than communication pins 2 and 3) where, in the abscense of intentional hardware signal changes, these pins remain at a constant positive or negative voltage. So either voltage is available at either end of the cable for local jumpering in order to fake a handshake if necessary to coerce data flow in one or both directions. Small (sometimes unique) rats nest of wiring inside of one or both ends of "proprietary" RS-232 cables under the hood is normal, to get by with fewer conductors since most serial devices are not modems any more and have lesser logic needs.
For one-way communication he's wise to use only two conductors between devices and skip the confusing "null-modem" fake-handshake approach I have seen so much of. Fortunately modern (1990!) RS-232 software allows you to enable various handshake lines at the terminal.
Here's some example wiring workarounds showing that almost anything goes:
https://www.perle.com/support_services/cabling/documents/db2...
At slow baud rates like 300 or less if available, your data can be visualized in real-time without an ocilloscope. With bypass of the hardware handshakes enabled in your communication software, ideally connect a bipolar LED (having an appropriate current-dropping resistor in series) between only male pins 2 & 5 of the PC's D-sub 9-pin connector. Although an ordinary (unipolar) LED can be good too, then alternatively reversed in polarity, showing only the marks or the spaces either way. This could just be popped into the breadboard in the video. As you press a key when terminal i/o is to that COM port it's almost like Morse code on the LED. These are the same two pins he is using to connect from his COM port to his breadboard.