$0.2:

CAN is both an electrical specification and a bus protocol. It requires
special silicon to support it fully (i.e. you have to buy someone's chips
- perhaps Microchip's). The CAN bus is not very well protected against
transients. This means that it will eventually blow up in my experience,
taking out one or more devices. Since you have to use CAN capable drivers
of the kind you designed into the devices, you will have to buy them, say,
five years from now. Also CAN is not differential and it does not like
ground potentials and lots of noise (like running CAN cable parallel with
a mains extension cord for 10 meters or so).

RS485 is an electrical specification (without specifying a protocol) for a
differential line used to send and receive serial bits. You can send RS232
or something else over RS485. RS485 drivers are second sourced by almost
everyone and you can make your own in a pinch. RS485 is used in very badly
polluted industrial environments and it works well. There is no limit on
the protocol you can use on it, nor on the speed (you can do 115kBauds if
the distance is short enough with suitable drivers). It can use CAT5
(normally for ethernet) cabling as is. It is relatively imprevious to
ground potentials and serious noise (like 10 meters of RS485 running
parallel with 10 meters of mains cable - as above).

As protocol I would suggest one of the Modbus protocols (pick one, either
ascii or binary - ascii is easier to debug). Modbus simply sends a string
of bytes normally over a serial line at a standard speed. This can travel
well over RS485/cat5 cabling with some additional matching resistors. You
do not have to call it Modbus, or imitate it perfectly.

The cat5 cabling can also be 'misused' to send telephone, video, and sound
unlike most other cabling, at least over shorter distances.

Others will say they like CAN more. I would suggest you spend some time
reading up on CAN. CAN is a clever protocol but the proprietary silicon
requirement makes it less interesting for me.

Peter

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu