Maker Pro
Maker Pro

Choosing a BUS / CAN I2C(TWI) or SPI

K

Kevin C.

Jan 1, 1970
0
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
 
R

R Adsett

Jan 1, 1970
0
It seems I have three choices. SPI, I2C (TWI) or CAN.
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.

CAN - This seems to be the big guy on the block. Basically, an
Ethernet type
interface for a MCU up to 1 Mbps.
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
 
D

D. Jay Newman

Jan 1, 1970
0
Kevin said:
Working on a basic dual drive autonomous bot.
This of course brings up the question of how to have the
main controller talk to both the motor controller and the
sensor board.

This is always a fun decision.
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.

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.
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

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)
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

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.
CAN - This seems to be the big guy on the block. Basically, an
Ethernet type
interface for a MCU up to 1 Mbps.

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.
So, the question is what wisdom can the group offer on the different
alternatives?

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.
 
B

Blueeyedpop

Jan 1, 1970
0
D. Jay Newman said:
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.
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
 
B

Bob Noonan

Jan 1, 1970
0
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.

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
 
K

Kevin C.

Jan 1, 1970
0
So, the question is what wisdom can the group offer on the different
alternatives?

Thanks,
Kevin

It seems that CAN has some definite advantages:
1) It's a standard
2) Don't have to invent error detection and arbitration
3) It's differential tranmission would be better in a noisy enviorn.

I suppose the real question is if the additional hardware requirements
are worth it?

The only info I've seen on actually implementing CAN involves the
Microchip MPC2510 CAN Controller and MPC2551 CAN Transceiver.

So, two additional chips per node to implement CAN is a significant
factor against implementing CAN. This would be greatly mitigated
if there is a single chip to interface the SPI or UART of the MCU to
CAN, but I haven't found it. Any help there?

Kevin
 
R

R Adsett

Jan 1, 1970
0
The only info I've seen on actually implementing CAN involves the
Microchip MPC2510 CAN Controller and MPC2551 CAN Transceiver.

So, two additional chips per node to implement CAN is a significant
factor against implementing CAN. This would be greatly mitigated
if there is a single chip to interface the SPI or UART of the MCU to
CAN, but I haven't found it. Any help there?
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
 
H

harshit

Jan 1, 1970
0
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?
 
R

R Adsett

Jan 1, 1970
0
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
 
R

R Adsett

Jan 1, 1970
0
isnt MCP2551 8-pin, high-speed CAN transceiver ?
Isn't that what I just said? Note that it doesn't handle the protocol
much less provide ADC or PWM.

Robert
 
Top