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.
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.
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.
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).
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.