Connect with us

Choosing a BUS / CAN I2C(TWI) or SPI

Discussion in 'General Electronics' started by Kevin C., Oct 27, 2003.

  1. Kevin C.

    Kevin C. Guest

    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
     
  2. R Adsett

    R Adsett Guest

    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
     
  3. 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.
     
  4. Blueeyedpop

    Blueeyedpop Guest

    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
     
  5. Bob Noonan

    Bob Noonan Guest

    I2C - Definitely a bus architecture, but seems designed to have one
    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
     
  6. Kevin C.

    Kevin C. Guest

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

    R Adsett Guest

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

    harshit Guest

    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?
     
  9. R Adsett

    R Adsett Guest

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

    harshit Guest

    isnt MCP2551 8-pin, high-speed CAN transceiver ?
     
  11. R Adsett

    R Adsett Guest

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

    Robert
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-