RS485 Networking for intelligent house by Frank A. Vorstenbosch
The practical differences of 232 vs 485 are:
The architectural difference between RS-232 and RS-485 is that 232 is a bi-directional point to point link, whereas 485 is a single channel bus. RS-232 can also carry additional signals used for flow control and modem control.Doesn't RS485 typically use a 9 bit address byte protocol for multidrop communications?Electrically, each 232 signal uses a single wire with symmetric voltages about a common ground wire. 485 uses two wires to carry the single signal differentially. Both wires use 0 to 5 volts, with the two wires being driven opposite. The purpose of this is to provide noise immunity, because much of the common mode signal can be rejected by the receiver.
{ed: Although it is not a part of the specifications, in most cases...} Both 232 and 485 use the same asynchronous encoding of individual bytes. This is the familiar start bit, followed by data bits (usually 8), followed by stop bits (usually 1 nowadays). Both the transmitter and receiver have to agree on the bit rate in advance. All timing within a byte is relative to the leading edge of the start bit. The PIC USART module was deliberately designed to support this encoding in its asynchronous (UART) mode. The low level PIC code is the same for both 232 and 485 because it is transmitting and receiving bytes via the UART (or a software UART).
The big difference to the software is that only one device on a 485 bus can transmit at a time, whereas there are separate dedicated transmit and receive channels for the single device at the other end of a 232 link. There must also be external hardware that enables driving the bus when transmitting. This hardware is usually controlled from a separate PIC pin, but there are also some "automatic" schemes.
The RS-485 standard (well sortof, "RS" actually stands for "recommended standard") defines how to transmit and receive bytes to/from the bus electrically. Issues like flow control, collision avoidance, and data reliability are left completely as an exercise to the implementer. In a pure RS-485 system, these have to be dealt with in the protocol. As you can imagine, there are lots of ways of dealing with this, and the right choice depends on the particular system. The solution often envolves wrapping data into packets, each with a checksum, and some kind of ACK/retry scheme. So far I've dealt with collision avoidance by having a single master with all other bus devices being slaves that only talk when asked to by the master. Note that this can still give the appearance to upper levels of slaves initiating data transfer if the master polls each slave often enough (this is also how USB works, by the way).
Each RS-485 system is different, and therefore probably requires a different protocol. You inquiry to the PIC list has prompted me to put some RS-485 information on my PIC development resources web page. This includes an excerpt of the protocol specification for one real-world system, provided as an example.
see also: