The IEE-485 standard is the approved version of the RS-485 standard. Both of these terms are used interchangeably when referring to the two-wire bus topology defined by this standard. Communication happens over a pair of wires referred to as A and B or D+ and D-. For maximum performance a twisted pair cable is used between nodes. At each transceiver, the D+ line is pulled high using a 470 ohm or greater resistor depending on the voltage of the bus. Th D- line is pulled low with another resistor of the same value (in wattmon, I use 470 ohms). At the source and end of the line, a 100 ohm resistor needs to be connected between the D+ and D- lines - this is called a terminator.
The communication is managed by an RS-484 transceiver device. I use the SP3078 since it operates at 3.3V but for 5V operation a MAX485 will work fine too. These 8 pin devices have a D+ pin, and a D- pin which would be connected to the resistors as described above. In addition, there is an RO pin, which would be connected to your MCUs RX pin, a DI (data in) pin which connects to your MCUs TX pin, and a DE and RE pair of lains which enables the transmit mode on the transceiver. These can be tied together are one is Inverted, allowing the same logic signal from an MCU Pin to toggle their state properly.
When you need to send data, enable TX mode by pulling high or low (depending on the transceiver) the TXEN pin, wait a very short while, and then simply send your data out the TX pin as with standard serial communication. The great thing about RS-485 is that you can daisy chain devices together, and sending data from one device to every other connected device is automatic. However, this also creates room for collisions and data loss. If a device transmits while another one is already transmitting this can create real trouble in communication. There are different ways to tackle this, and I have researched the various protocols extensively before deciding on Modbus, which is a master-slave protocol. Using master-slave type communication ensures that no device will ever transmit unless it first receives a request from the master device, in this case the wattmon box.
Other protocols of interest were uLan, which uses a 9 bit data stream, with the ninth bit set for commands. This has the great advantage that the microcontroller does not need to receive every byte and parse it, but can listen for a specific pattern and only process relevant packets of data. I decided against it because I wanted to go with an industry standard that I could easily interface with and also because 8 bit data streams are easier to work with in small embedded hardware. Another option was a token passing system, and a time sliced communication method. The choice made will depend very much on the application. In wattmon, I wanted the ability to add multiple devices to the same bus, and at the same time I didn't need these devices to every initiate communication with the wattmon master. Ever device is polled automatically through a poller task ensuring hassle free communication.