RS485 from what I have read so far seems to offer higher transfer speeds and longer distances (Which I interpret as a more reliable signal if I transmit under the max length / speed thresholds)
Right. It's designed for use in electrically noisy environments as well. But you do need to make the protocol reliable - that may mean a message-oriented protocol with reserved values for start and end of message, and escaping for those characters when they appear in the data, and it will mean 8-bit or 16-bit CRCs on messages, and automatic retries on acknowledge failure.
RS485 also looks easier to implement. CAN seems to be very involved. (And I think I will get better support on here with RS485)
Agreed!
The easy route to implementing RS485 is to use the UART built into the PIC. It is made into RS485 by feeding the output of the USART into a MAX485 differential buffer/driver.
You forgot to mention the RS-485 transmit enable signal. This needs to be activated by firmware when it wants to transmit, and needs to be held active until the last bit of the last byte has been transmitted. This can have implications for firmware; the PIC doesn't have a TSRE (transmit shift register empty) interrupt - at least, the PICs I've seen don't. So you have to provide the transmit enable turn-off using a timer or some similar trick, unless you can afford to wait one or two byte-times inside your transmit byte interrupt handler!
The main requirement of RS485 is proper termination of links.
Only at high data rates. Reflections in the microsecond range are irrelevant if the bit width is hundreds or thousands of microseconds. It's also important for the RS-485 bus to "float" into the idle state; this can be ensured by using receivers with skewed inputs, or pullup/pulldown resistors on the bus lines, and with pullup/pulldown resistors, a termination resistor will reduce the noise immunity during idle periods.
Any protocol that has crash detection inherently becomes slower as traffic increases and therefore more collisions occur. So it is still advisable to implement a poll/select protocol, removing crashes.
Definitely. I would always use a protocol that implements poll-and-response and message-and-acknowledgement, or similar, so bus access is dictated by the Master device.
@adam: It has been a while since I used RS485, but I seem to remember that there are special address settings to broadcast, but I do not remember seeing any way of doing selective multicast - it is everybody or one at a time.
It depends on the protocol you use. Every slave should have a unique address, and you can assign a broadcast address (e.g. 0xFF) and as many multicast addresses as you want (e.g. 0xF0~0xFE). You need to configure the slaves properly; this can be done automatically with individually addressed setup messages, or hard-coded into the slave firmware.
As a final comment: I don;t think it is a good idea to go for CAN if this is your first attempt at a communications project. In this case I do believe RS485 is a better choice.
Agreed.
Getting into this late, but depending on how you power the devices, you can superimpose a signal onto your power supply to signal devices.
Yes, you could try power-line carrier using modems. It's an interesting idea. I wonder how well it would work. I think you would have to optimise the protocol for an unreliable data link!
