I'm plotting out some projects and the things that need to be done in order to make them work. And I realized that there's some very simple starting point steps to wiring and managing things necessary to make things building-block style.
So, the fundamentals: Data can flow in a few ways. You can have a simplex connection, where one device just broadcasts and the other just listens. You can have a half-duplex connection, where only one device can speak. Or you can have a full-duplex connection, where two devices can talk at the same time. You may also want to have multiple nodes on a single network to simplify your wiring, and when you have a bunch of nodes on the same network and they all try to talk, problems occur.
Now, there's a few ways to send data that have fairly arbitrary support on a wide variety of devices. You can use a parallel port or a serial port. The thing is, if you use a parallel port, you need at least 8 wires, probably more. Whereas with a serial port, you can get away with maybe one or two wires.
Now, when you start looking at microcontrollers, pretty much all of the good ones will have at least one UART or USART (USART means it can be operated in synchronous mode as well as asynchronous mode). Most of the time, this is at a TTL voltage level, so you can connect a "driver" to it. The kind of driver and how many pins you want to use is dependent upon what sort of protocol and signaling strategy you want to use.
We can start sometime before 1969, when the RS-232 standard was cooked up for you to hook up a electromechanical teletype to a modem. The recommended plug ended up being a 25 pin D-sub cable with a whole bunch of connectors that nobody really used (but were occasionally found to be useful). Eventually real electronic terminals came along and computers started needing bunches of them... and eventually we saw microcomputers with a 25 pin RS-232 cable for modem and terminal usage.
RS-232 was really obnoxious, especially in the earlier days when you needed some number of pins that another device wouldn't need. This still happens, actually, it's just that most hardware you'd encounter at home doesn't have any problems whatsoever. And the 25 pin cable was huge. So eventually they stopped using most of the signal lines and made a 9 pin connector in the days of the IBM PC AT. You can get away with even less. Pretty much each way needs one wire, plus ground. So, either two or three. If you add two more lines (RTS and CTS) you can get hardware flow control.
You also see pseudo-RS-232, where you use the same signal lines, but instead of using fairly high positive and negative voltages, you just use TTL signal levels.
Now, along the way, Apple got some bright ideas about design... actually, they've pretty much always had the idea that things must be done '''right''', regardless of what everybody else wants to be doing. Which is why Macs used SCSI instead of IDE for a long time. And is also why the Mac (And later Apple II computers) have RS-422 instead of RS-232.
Now, RS-422 has some nice properties, because it came after RS-232 hit the scene and people started to see what it did wrong. One of the biggest ones being that it's a differential bus, so you can send a signal by putting a positive voltage on one side and an equivalent negative voltage on the other line, which makes it more resistant to interference if you take those two wires and twist them around each other. This means you can run it over a much longer distance and you can run it faster. So, Apple put the only pins that mattered in a cute little 8 pin connector and picked drivers so you can use it in RS-232 or RS-422 mode with a simple adapter... which not all RS-422 drivers will allow.
RS-422 also lets you have a much easier time doing multi-drop networks, so you could put several devices on the same network, with a master and several slave devices. This is handy for those of us who want to do large projects because you can just hook up 2 twisted pairs to each node and all of them will receive data. The "Master" sends data on the first pair and receives responses on the second pair.. and then the "Slave" listens for the data on the first pair and responds on the second pair. And you can actually have several other devices listening to the pairs -- the specification says that each sender needs to be able to drive ten listeners. This is called "multi-drop".
If you are using RS-422 as a long-distance point-to-point link, you can do full-duplex between two nodes. The standard doesn't specify that drivers be able to turn on and off the transmitter. If you have two circuits trying to drive the link at the same time, one or both of them is going to short out. Eventually RS-485 came along. The electrical characteristics are just about the same, so most hardware that can deal with RS-422 can also deal with RS-485 and all RS-485 hardware can deal with RS-422. RS-485 drivers require you to be able to take the driver part offline and that shorting out if two try to drive the bus won't fry the drivers. So this way, you could have ten nodes and each one could alternatively transmit and receive. This is called "multi-point". There's a modification of RS-485 you can do to add a second pair (like you'd use for RS-422) so that you can have two conversations going on at the same time.
Actually, I lied about the "ten" part. Most modern RS-422/RS-485 receivers will take up less than one unit of power, so you can fit even more nodes on the same piece of wire.
There's one more way to transmit stuff that I haven't mentioned, and it's pretty much confined to MIDI. MIDI requires a current loop design so that each device is electrically isolated from the next using optioisolators. This way, it can work on a poorly wired temporary stage where you can literally shock yourself to death with the level of grounding issues encountered.
The thing about RS-485 is that it says absolutely nothing about what you actually send over the wire. So people build standards atop RS-485. DMX512 is a specific message format and baud rate. LocalTalk, which was how the earliest macs networked, uses RS-485 and a network format. A lot of home control and factory automation systems use this too. In any case, you need to put a protocol atop it so that everybody knows how to talk in order.
Now, if you are building a factory automation system and have a bunch of gear that all has serial ports, you will probably spend an absurd amount of time trying to get things work, because of the various wiring and protocol issues. Everybody has their own interpretation about how RS-232, RS-422, and RS-485 ought to work and in no case is a protocol specified.
On the other hand, I'm connecting a bunch of stuff that won't fit inside of a single chassis together, so I can specify a protocol myself and stick to it. I tend to think RS-485 is a pretty nifty idea. The chips are cheap and easy to find and you just need a single twisted pair and a ground wire.... which pretty much means two pairs out of a phone or Ethernet cable.
But you still need to make stuff talk to each other properly. The big thing to remember about RS-485 is that you can't have more than one device transmitting at a given point in time. RS-485 drivers need to have an automatic shutdown to handle that case, because otherwise it'll fry the chip. With the automatic shutdown, it just means that the bus shuts down. I've got a plan but I'm not talking about them it I'm done! :D