Choosing a BUS / CAN I2C(TWI) or SPI

Working on a basic dual drive autonomous bot.
The Motor Controller has it's own MCU generating the PWM and reading the odometry sensors. It makes adjustments
to stay on the course if it detects wheel slip and such and sends status messages to the main controller. Currently, the two controllers pass messages back and forth over the USART.
I'm starting to think about the next phase, and am toying with the idea of adding another MCU to the mix to handle the sensors.
This of course brings up the question of how to have the main controller talk to both the motor controller and the sensor board.
Since USART is point to point (not a bus configuration, no addressing), the master could be configured in a star configuration and implement a software USART to each of the sub-processors. It would be relatively easy and inexpensive but wasteful of I/O pins and would (probably) only practically scale to 4 or 5 sub-processors.
It seems I have three choices. SPI, I2C (TWI) or CAN.
My knowledge of any of them is limited, but my research indicates the following.
SPI - Ideal for single slave, single master configuration. Each additional slave device requires an additional i/o pin to set the "slave select" (beyond three devices, I suppose one could put in an octal or hex decoder to get around that). It's a full duplex communication stream and supports fairly high speeds. It's hardware interface is more than I2C/TWI, but needs less software support (I think). Further, many processors have hardware support.
Some info is here: http://www.embedded.com/story/OEG20020124S0116
I2C - Definitely a bus architecture, but seems designed to have one main Master talk to a variety of slave devices. Several times I've seen mentioned the fact that there can be several "Masters" who contend for the bus, but haven't seen a lot of detail on how that's accomplished. It has light hardware requirements and certain processors are able to handle the interface in hardware. The communication channel is half duplex up to about 400 Kbps
Some info is here: http://www.embedded.com/story/OEG20010718S0073
CAN - This seems to be the big guy on the block. Basically, an Ethernet type interface for a MCU up to 1 Mbps. It appears that an interface chip is required for each MCU to access the bus or the CAN controller is an MCU feature since the protocol software is fairly heavy duty and would overload the processor. Fully capable of just about anything you want to do, but seems to be the most expensive and elaborate solution. Of course, it is also the most feature rich and future proofed. The upper level protocol definitions such as CANopen make this more appealing for a small project like this.
Some info is here: http://www.mjschofield.com http://www.esacademy.com/faq/docs/canopen /
So, the question is what wisdom can the group offer on the different alternatives?
Thanks, Kevin
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@glenevin.com says...

IIC and SPI are really meant for interchip communications in the same module, CAN for intermodule communications. Indeed ther are several CAN protocol chips that (can) use SPI for there on-board communications. Of course they can all be bent to other uses.

Not really ethernet like. (The CAN Kingdom Spec has a clear if somewhat idiosyncratic explanation http://www.kvaser.se/download/index.htm ). Baisically The CAN Protocol defines a set of message boxes of up to 8 bytes in length. There may be only one transmitter for any message box but many listeners.
Higher Level Protocols (HLPs) are built on top of this basic layer but you can probably get away with something simpler.
Something like: Message Box A: -- Command Speed (Set by Vehicle Controller, read by Motor Controllers     - Byte 1 - Speed for motor 1     - Byte 2 - Speed for motor 2     (Easily expandaile to 16 bits if 8 isn't enough resolution)
Message Box B: -- Sensor Feedback (Set by Sensor Controller, Read by Motor Controllers and Vehicle Controller?)     - Byte 1 - Left Odometer Sensor     - Byte 2 - Right Odomenter Sensor
Message Box C: -- Left Motor Feedback     - Byte 1 - Speed     - Byte 2 - Fault flags
Message Box D: -- Right Motor Feedback     - Byte 1 - Speed     - Byte 2 - Fault flags
And on and on....
Since CAN protocol chips typically have multiple mailboxes you can use one for each mesage box that each controller wishes to receive. A single send queue can be used to send all message boxes a controller wants to send. The micro can then just sit there and read the appropriate mailbox when needed, all the rest of the overhead is handled by the CAN controller.
Of course if you want to add the sophistication of an HLP like CANOpen, CAN Kingdom or Devicenet thats possible too. In your case probably not needed unless you are going to integrate third party modules.
With the amount of information you are passing around you probably have lots of room to add watchdog counters to the messages to increase the reliablilty.
Looks like an ideal application for CAN to me.
Robert
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Kevin C. wrote:

This is always a fun decision.

While it may be only point-to-point, it is possible to use an addressing scheme to deal with multiple sub-processors. This assumes the main processor initiates all communication. Kronos Robotics has coprocessor boards that use technique.

I like SPI. I use it for almost all short-range communication. Since my main processor usally has a bunch of i/o pins, it isn't a problem to have many chip-select pins. Many peripheral chips use SPI (the ADC chips I use and my compass for two). PICs and the Ajile 100/80 understand SPI natively. (OK, some PICs)

To me this isn't much of a problem. I prefer master/slave configurations for robotics. Either the master can query the slaves periodically, or the slaves can assert an i/o pin to indicate that they have something to say.

There was an article in the latest Circuit Cellar about a small version of CAN. It sounded interesting, and should be able to be implemented on any reasonable processor.
I have even seen some CAN-capable PICs, but haven't had the pleasure of experimenting with them yet.

I prefer to call my advice "experience" rather than "wisdom". However, I'd suggest that you choose the architecture and protocol based on the environment of the robot.
In one book the author used RS432 serial communication because it worked better in a noisy environment (he had *big* motors).
I believe CAN can also be made to work well in noisy environments because it is used in cars.
On the other hnad, I've used SPI and TTL-level asynch serial for pretty much all my intra-robot connections and they've all worked well. Of course, this may be because my current robot isn't all that huge. My next robot may need something a bit better. -- D. Jay Newman http://enerd.ws/robots /
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

CANBUS!
check out my 12 motor, 6 processor centipede http://www.bio-bot.com/movies , also my article in the October Nuts N Volts. Buffers, error checking, addressing, conflict resolution at the low level, so you don't have to.
Second choice would be using RS-232 to RS-485 converters.
3rd choice would be SPI. Getting a processor to be a slave can sometimes be a problem.
Mike
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I2C definitely has support for multiple masters. Before starting a master must "listen" for an idle bus for a minimum amount of time (I forget how long). The trouble with multiple masters is that after this step, two or more masters may decide to start a cycle at the same time. This requires arbitration, which works like this: Assume you own the bus and begin transmitting your address. With each bit you must also monitor the line to verify that what is on the line matches what you are trying to drive. If it doesn't match, you've lost arbitration and you need to back off. Pretty simple, basically the last master to drive a 1 on the line will win (if you are driving a 0, the bus must be 0).
For this to work, all masters much be multi-master capable and you must use open-collector or tri-state buffers (you never truly "drive" a 1 on the bus, you just tri-state and let it get pulled up). Most I2C modules that come built into devices are not multi-master capable, so make sure to check that.
Also, there is a newer specification for high-speed I2C (1.2 Mb/s IIRC). Probably next to nobody has implemented this, but I thought I'd mention it in case you are the one going to implement all of the masters/slaves. Check out the Philips Semiconductor web site for the specification.
Hope this info is helpful, Bob
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@glenevin.com says...

I haven't seen any CAN protocol chips with the transceiver built in. I doubt any exist. Initially they were separate because 1 - no transceiver existed 2 - several schemes were defined for the signaling layer Now I think nearly everyone uses the equivalent of on 82c250. The reasons I suspect you won't see an integrated tranceiver is most commercial CAN buses use isolation between the protocol element and the transciever. Add to that, most busses require the trancievers to cope with a short to the power supply and so require rather different withstand ratings. The capability to witstand 24V on the signal lines is not unusual.
BTW for CAN protocol and tranceiver chips you can also look at Philips and Infineon (any several others, including many micros with CAN protocol logic built in).
Robert
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
i think id disagree with the previous posting. go to microchip.com they have CAN transciever chips with ADC , PWM mainly they handle the protocol. Is this what ure lookin for?
says...

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Hmm, I was just there and didn't see any micros with a CAN tranceiver on board. Several with CAN protocol logic but no tranceiver. The only tranceiver they mention is the MCP2551. Most microcontroller companies appear to offer at least one variant with a CAN controller (protocol logic) built in.
Even Microchips's remote CAN I/O chip needs the separate tranceiver.
Robert
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
isnt MCP2551 8-pin, high-speed CAN transceiver ?
says...

mainly
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Isn't that what I just said? Note that it doesn't handle the protocol much less provide ADC or PWM.
Robert
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.