RS232 vs RS485
Dr_Acula
Posts: 5,484
I've been pondering the merits of both these protocols - please forgive the long ramble below, as I think it might lead to a new propeller project. And it is a project that I don't think is easy using other microprocessors.
Some quick background. TTL logic levels 0V to 3V. Fine for short runs. But you can't short wires, you can't feed 12V up a wire, and if you swap a Tx and Rx wire you are likely to zap a chip.
So - convert to RS232. Now the signal is robust, can go further and is largely idiot proof.
The simplest RS232 cable is three wires - Tx, Rx and Gnd.
The simplest RS485 is also 3 wires, A, B and Gnd (maybe you can leave out Gnd, but real world circuits seem to all have it)
How does RS232 convert to RS485? Perhaps the best way to understand this is to consider the ultra simple 'party line' network. TTL levels, resting is low, line is pulled low at one point with a 10k resistor, all tx lines go to the party line via a 914 diode, all Rx lines listen to the party line.
RS485 has much in common with the party line approach. The 10k resistor is replaced with three bias resistors. RS485 networks look simple - just daisy chain boards. You can even use cat5 cable and use 2 lines for A and B, and two lines for 'power over ethernet' and it still leaves 4 lines free for a real ethernet.
But there are some 'gotchas' too. If every board has the bias resistors (about 1k total resistance is ballpark) then every board is consuming power. Also, the total line impedance goes down, so the drivers have to work harder and harder. Eventually, there is a maximum number of boards you can add.
You can leave off the bias resistors on some boards. But what if you happen to remove the one board that does have the bias resistors - then the lines float and the whole network goes down.
But the biggest problem is how the Tx and Rx lines work.
RS485 essentially joins the lines together, so when a byte goes out of a board, it echos back to that board. You can solve that in software or hardware. In software you might disable the rx while a byte goes out. But what if some bytes were coming in at that moment? Likely two rx bytes will be corrupted.
Further, what if the rx buffer already has 10 bytes in it that have not been read yet? The corrupted byte/bytes end up in the middle of uncorrupted ones. Software solutions are possible, but they are not simple.
Or you can do it in hardware. Disable the rx when a byte is going out. Disable it for n milliseconds after the byte goes out to be sure. That delay is not constant and will depend on the baud rate. To be sure, you need a time constant longer that the slowest byte the network might ever see. Maybe 1200 baud. But then a lot of time is wasted if the network goes up to a higher rate.
RS485 is good for some networks but not others. The 'perfect' RS485 application is one master and many slaves. The master has the bias resistors, the slaves do not. Master sends out a signal eg a request for data from one specific slave. That node responds - the others all stay quiet. Slaves don't need to worry about the echo as they can easily fix this in software.
Consider a different network - 4 nodes A B C and D. A is exchanging a file with B at the same time C is exchanging a file with D. There is the potential for data clashes, bytes interfering and the only way to really be sure a byte got through is to put it inside a packet. Then if a packet does not go through you need to send a 'resend' message. Then resend resend messages. I built such a network once at 1200 baud and when it got to 10 nodes, suddenly there were so many messages the whole thing shut down.
There have been many solutions - token ring is one. It is interesting to note that 'party line' solutions, like ethernet with 50 ohm cable have been replaced more recently with cat 5 'star' networks. One hub in the centre and all messages must go through the hub.
As an aside, I'll mention 4 wire RS485 (5 wire including ground) where a RS232 tx wire becomes two RS485 wires, and the RS232 Rx becomes another two RS485 wires. This avoids the echo problem, as well as local data clashes on a line.
4 wire RS485 and RS232 can be thought of as being interchangeable, and lead to... consideration of a serial hub.
The Propeller is perfectly suited to running a hub. 8 RS232 D9 plugs or 4 wire RS485 plugs (you can choose either). 8 cogs running independently and handling asynchronous comms. (or maybe use two cogs running Tim Moore's quad RS232 software). You can do baud rate translation. Bytes are buffered locally. The master software polls each buffer in turn, and if there is a byte, sends it out all the other lines. Then polls the next one.
No data clashes, and all bytes go to all other lines.
I am thinking of making such a circuit. An 8 way serial hub with either RS232 or RS485 (4 wire) so you can network propeller boards.
Thoughts and advice would be most appreciated. In particular, I wonder what the best plug would be for a 4 line RS485 connection. use cat5 cable and then add V+ and Gnd for a 6 wire solution?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Some quick background. TTL logic levels 0V to 3V. Fine for short runs. But you can't short wires, you can't feed 12V up a wire, and if you swap a Tx and Rx wire you are likely to zap a chip.
So - convert to RS232. Now the signal is robust, can go further and is largely idiot proof.
The simplest RS232 cable is three wires - Tx, Rx and Gnd.
The simplest RS485 is also 3 wires, A, B and Gnd (maybe you can leave out Gnd, but real world circuits seem to all have it)
How does RS232 convert to RS485? Perhaps the best way to understand this is to consider the ultra simple 'party line' network. TTL levels, resting is low, line is pulled low at one point with a 10k resistor, all tx lines go to the party line via a 914 diode, all Rx lines listen to the party line.
RS485 has much in common with the party line approach. The 10k resistor is replaced with three bias resistors. RS485 networks look simple - just daisy chain boards. You can even use cat5 cable and use 2 lines for A and B, and two lines for 'power over ethernet' and it still leaves 4 lines free for a real ethernet.
But there are some 'gotchas' too. If every board has the bias resistors (about 1k total resistance is ballpark) then every board is consuming power. Also, the total line impedance goes down, so the drivers have to work harder and harder. Eventually, there is a maximum number of boards you can add.
You can leave off the bias resistors on some boards. But what if you happen to remove the one board that does have the bias resistors - then the lines float and the whole network goes down.
But the biggest problem is how the Tx and Rx lines work.
RS485 essentially joins the lines together, so when a byte goes out of a board, it echos back to that board. You can solve that in software or hardware. In software you might disable the rx while a byte goes out. But what if some bytes were coming in at that moment? Likely two rx bytes will be corrupted.
Further, what if the rx buffer already has 10 bytes in it that have not been read yet? The corrupted byte/bytes end up in the middle of uncorrupted ones. Software solutions are possible, but they are not simple.
Or you can do it in hardware. Disable the rx when a byte is going out. Disable it for n milliseconds after the byte goes out to be sure. That delay is not constant and will depend on the baud rate. To be sure, you need a time constant longer that the slowest byte the network might ever see. Maybe 1200 baud. But then a lot of time is wasted if the network goes up to a higher rate.
RS485 is good for some networks but not others. The 'perfect' RS485 application is one master and many slaves. The master has the bias resistors, the slaves do not. Master sends out a signal eg a request for data from one specific slave. That node responds - the others all stay quiet. Slaves don't need to worry about the echo as they can easily fix this in software.
Consider a different network - 4 nodes A B C and D. A is exchanging a file with B at the same time C is exchanging a file with D. There is the potential for data clashes, bytes interfering and the only way to really be sure a byte got through is to put it inside a packet. Then if a packet does not go through you need to send a 'resend' message. Then resend resend messages. I built such a network once at 1200 baud and when it got to 10 nodes, suddenly there were so many messages the whole thing shut down.
There have been many solutions - token ring is one. It is interesting to note that 'party line' solutions, like ethernet with 50 ohm cable have been replaced more recently with cat 5 'star' networks. One hub in the centre and all messages must go through the hub.
As an aside, I'll mention 4 wire RS485 (5 wire including ground) where a RS232 tx wire becomes two RS485 wires, and the RS232 Rx becomes another two RS485 wires. This avoids the echo problem, as well as local data clashes on a line.
4 wire RS485 and RS232 can be thought of as being interchangeable, and lead to... consideration of a serial hub.
The Propeller is perfectly suited to running a hub. 8 RS232 D9 plugs or 4 wire RS485 plugs (you can choose either). 8 cogs running independently and handling asynchronous comms. (or maybe use two cogs running Tim Moore's quad RS232 software). You can do baud rate translation. Bytes are buffered locally. The master software polls each buffer in turn, and if there is a byte, sends it out all the other lines. Then polls the next one.
No data clashes, and all bytes go to all other lines.
I am thinking of making such a circuit. An 8 way serial hub with either RS232 or RS485 (4 wire) so you can network propeller boards.
Thoughts and advice would be most appreciated. In particular, I wonder what the best plug would be for a 4 line RS485 connection. use cat5 cable and then add V+ and Gnd for a 6 wire solution?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Comments
RS422 is the proper name for "4 wire RS485" [noparse]:)[/noparse]
RS422's main limitation is that it is only suitable for point-to-point or master-slave communications, it is not suitable for peer-to-peer networking.
I've considered something similar (to the hub you describe) - the biggest issue is latency caused by having the prop have to process the message/packet.
After a lot of consideration, for my products, I ended up with:
- RS232 or RS485 for point to point
- RS485 for low cost networking
- Ethernet for higher end networking
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system