Addressable simple serial bus for medium distances using PIC microcontrollers?

Question

I am looking for serial bus, that could have addressable nodes, with maybe max. 30 nodes. I don't need multi-master, and the speed is not an issue. The distance between the nodes could be something like 20 meters. The easier it is to implement with Microchip PIC microcontrollers, the better. I2c seems otherwise nice, but it isn't designed to work at such distances.

I have looked at RS485, CAN, LIN, and so on... Atleast for CAN and LIN there are integrated peripherals in some of the higher series PICs.

What are the advantages and disadvantages of these, and how do they compare to each other?

Answer 1

CAN is definitely the way to go. There are plenty of PICs that have a CAN peripheral built in. The electrical interface and up to the packet layer, including checksum generation and checking, is all built into the hardware. The hardware also handles collision detection and transmission retry. At 20 meters you should be able to run the CAN bus at 1 Mbit/s, but if speed isn't a priority you can run it quite safely at 500 kbits/s.

RS-485 is very old school and makes you do a lot more yourself in firmware. The RS-485 spec only tells you the signalling levels and leaves the rest to you. You can use the UART hardware to at least send and receive whole bytes, but you still need external hardware to explicitly switch each node between transmit and receive, and then firmware that knows when to switch. CAN may seem intimidating when you first read about the peripheral in the datasheet, but after writing all the protocol layers for a robust multi-node communication interface you will have spent a lot more effort than using CAN. With CAN, you send and receive whole packets that contain either a 11 or 29 bit ID and up to 8 data bytes. The hardware takes care of sending and receiving these at the packet level, and you don't have to worry about who is sending when, master versus slave, etc.

Don't listen to people who got stuck in the 1990s and are still using RS-485. There is a better way, and it's been around for a while. You should consider that many major protocols that were RS-485 back in the pleistocene now have newer versions that use CAN. These include automotive and shipboard communication busses.

Answer 2

RS-485 is pretty good. It requires separate driver chips, but using such chips will help shelter the PIC from any electrical nastiness on the bus.

If there's going to be one master, I would suggest that slave devices be coded such that they essentially never talk except in immediate response to a transmission from the master. If the master may request an operation that could take awhile, it should be split into two commands: "Start doing XX", and "Say whether you're done". Designing protocols this way minimizes the complexity of timing interactions between the master and the slaves. The master needs to have timeout logic for the scenario where it tries to talk to a slave but it gets no response, but slaves don't need timeout logic (except perhaps for a master watchdog function). If the master successfully sends something to the slave, but the slave's response gets gobbled up by some random electrical glitch, the master, not hearing the slave's response, will repeat its request; the slave, hearing the retransmission, will resend its response. From the slave's perspective, acknowledgement may be inferred by the master's lack of a retransmission request.