Multiple slaves over 12 Meters, I2C or something else?

[miceuz]

One thing I'm missing in this discussion is the point that CAN bus is a fairly high level protocol. You have lots of stuff already sorted out for you protocol-wise in CAN hardware (addressing, collisions, arbitration, whatnot) - you just use a CAN enabled micro and bam - you are receiving high level messages. Another way would be to use a SPI CAN hardware chip, I've seen Microchip has one to offer. This way you have a micro, SPI CAN translator and CAN hardware transceiver. TI Stellaris Launchpad had an ARM micro with CAN hardware inside, I'm not sure if the new iteration of this board has it. I've written a CAN bus sniffer for Stelaris, didn't post it anywhere yet, ping me if you want it for whatever reason.

While RS485 is just a specification of an electrical level of the network. You have to write (or reuse) all high level protocol by yourself. For single master network Modbus can be attractive - robust, industrial use, there are loads of free libraries.

I2C stands somewhere in the middle, but as others already noted - it's not meant to be used like this. I'd say it's better to do things properly adhering to world wide accepted standards even if it's just a hobby project. This way you learn a) new stuff b) proper engineering 

[nctnico]

Don't let feelings rule your world. Why would NXP make a chip which allows to bridge I2C over 20m at fairly high speeds? Farnell has more than 2000 pieces of the PCA9600 in stock and Digikey over 5000 so it is not a boutique part nobody is using.

[C]

What may at first look good on paper may not work as well in practice. Very often the paper idea will forget about time as it takes time for a message to propagate down the cable.
Using a satellite in a communications link may sound like a real good idea but the really great thing a satellite does it add a big time delay. It takes time to get up to the satellite and still more time to get back down from the satellite and there is nothing you can do to decrease this time delay. The same thing happens on any cable just to a lesser degree.
If the idea is a master telling a node when to talk then you have an added a time delay. The smallest you can make this added delay is to put the master in the middle of the cable. Then you have the added delay for poling all the nodes that need to talk. You spend all day poling all the nodes and how ofter does that node with the switch attached need to say "My switch has changed".
You could save some time and have one node tell the next to talk. You have just saved a bunch of time but now your master is really called a watch dog making sure the rotating talk keeps happening and you still have time delays. IBM token ring did this.
You could do Ethernet like where you just talk when you think the bus is not busy but the nodes at each end have a great time separation so at some point the two will talk and the messages will overlap on the buss and garbage results.
The bus puts things together with the added fun of a time delay being thrown in the process.
Can bus via it's priority based sense on startup has a chance to have two messages start to happen at the same time and one survive the happening. When this fails and it will at times it has bits that will tell the other nodes that the message got clobbered. If you look at Can buss there is a way for a node to say "the message with an ID of ___ got clobbered here" and also a way to say "that last message got clobbered" when even the ID part was damaged.
CAN's message ID with  priority  and short message lengths is great when you need to process events. This does not prevent longer messages from happening it just adds overhead.
Think of this One,
a node receives a Ethernet packet on one of it's interfaces. It could easily chop that Ethernet packet into the smaller packets and send it over can bus. A second node might be transmitting music via can bus packets. You have many nodes with switches and of course you have the important stuff like fire.
Those Ethernet packets can easily push the bus to max. That music could take a large part of the bandwidth on the buss. But if you have the message ID's priority set correctly that fire message would over ride the switch message which could over ride the music message which could over ride the Ethernet packets. It still works.

There are pic's and avr's with built in CAN controllers. But is it worth the high cost of using them? You might save a dollar or two per node at the cost of limited space and processing power for the future. Some nodes could really use the added processing power that an ARM micro adds. Also with ARM you can easily have both CAN and something using a RS485 buss. Actually you could have many of both. So I often wonder at the idea of starting off building something that will be limited at the start just to try to save a few dollars and then spend even more then you saved by adding a crippled add on to add in what the few dollars added at the start already had to start with.

So looking at the OP's over all project. Right now I would probably start with a BeagleBone Black, Just this one board adds the display to a TV or Computer monitor. An Ethernet connection so that all the computers on the network could access it and/or have a web status page. If this Ethernet network connection did not have Ethernet wireless and it's wanted, you have the option to cheaply add this via USB. And saving the best part for last, two Controller Area Network Ports (CAN) & Six UARTs along with a bunch of other interfaces.         
For most or all the rest of the nodes I would use an ARM base as you have so very many choices. The current TI Stellaris Launchpad has 2 CAN controllers and 8 USARTs. ST has it's discover boards and some of them will have CAN controllers.
With these as a starting foundation to develop from Why go to PIC or AVR?   
With ARM if you want to add a small graphics screen you have the power and space to do so. With the small PIC's and AVR's with can controllers you are probably in juggle mode or fancy complicated programming to get it to work. Yes for very simple nodes these could make some sense, but if you need more power then these can offer for a node then they are probably a poor choice to use even in the limited spots.

Miceuz
With all the chips that have a built in CAN controller using a SPI CAN hardware chip would be my very last choice. I would most likely add a second mpu with a can controller before that choice. This is adding an extra layer of complications for what I see as no good reason. It would be much cheaper and you have more to work with with an ARM chip. 

nctnico,
The short answer is that they think they can sell it and break even or make money. It does not have to make sense or any of the many other things you might think, it's just the money.
Some one sold pet rocks and made a killing just because enough someones would buy them. Does this make sense?

For the PCA9600 it's probably a case of it's cheaper to add that expensive chip then to redesign what it's connected to at one or both ends and then add the programing needed. Even in this limited case I would guess that it would not be used in the future unless this case was a really strong case for it continued use.

Just my thoughts

C

[nctnico]

nctnico,
The short answer is that they think they can sell it and break even or make money. It does not have to make sense or any of the many other things you might think, it's just the money.

The flaw in your reasoning is that if a chip doesn't sell Farnell and Digikey won't carry it let alone stock pile large quantities. Besides that we all have I2C over a (long) wire in our home: VGA, DVI and HDMI. Despite all the technical marvels of CAN, ethernet and RS485 I2C is plain, simple, robust (glitch filtering!) and cheap. You don't even need a microcontroller at the endpoint.

[zapta]

OP, your requirements seems to fit the linbus very well. One bus master, N slaves (each can listen to all the others), moderate speed (up to 20K), noisy environment, inexpensive nodes, inexpensive wiring (three wires, 12V + signal) simple protocol, no collisions, guaranteed latency, and good vendor support.

Microchip has transceivers, tools (analyzer/generator), app notes and even integrated packages with transceiver, LDO and microcontroller.

http://ww1.microchip.com/downloads/en/DeviceDoc/41673A.pdf