Choosing a BUS / CAN I2C(TWI) or SPI

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

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

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

CANBUS!

check out my 12 motor, 6 processor centipede

Second choice would be using RS-232 to RS-485 converters.

Mike

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

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

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?

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

Isn't that what I just said? Note that it doesn't handle the protocol much less provide ADC or PWM.

Robert