Connect with us

What bus should I use? I2C, SPI or something else?

Discussion in 'Electronic Design' started by [email protected], Oct 17, 2006.

Scroll to continue with content
  1. Guest

    I'm currently looking to design a number of devices that link together
    and require small amounts of data to be transfered between them
    quickly. These are the three possible configurations. The = symbol
    represents the data lines connecting the different devices.

    +---+ +---+=======+---+
    | A |========| B | | C |
    +---+ +---+=======+---+

    | D |
    +---+ +---+===+---+====+---+
    | A |========| B | | C |
    +---+ +---+===+---+====+---+
    | E |

    +---+ +---+ +---+
    | B |========| A |=======| C |
    +---+ +---+ +---+

    Redundant wiring runs between B and C in the first two so that if a
    single cable breaks the system continues to operate. D and E are
    optional devices that sit along the bus. Approximate cable lengths are
    no more than 1.5 metres, with total cable run from end to end being up
    to 3 metres but no more. Power and ground would all be included in the
    cable runs, I can use any form of cable provided its not too big.

    My core objective is allowing the master in device A to be able to
    connect to the other devices reliably at a fast speed in any of the
    above configurations. Differences in support components, termination
    if required, etc are not a problem as they boards will be customised
    for their purpose and position on the bus.

    In addition I would like to know if one of the cable routes fail. I'm
    not sure how to detect a cable fault, especially if multiple cable runs
    exist between boards. Any suggestions?

  2. Tim Wescott

    Tim Wescott Guest

    Use asynchronous serial over RS-485, or use CAN. In either case change
    your topology to (where a single line is a twisted-pair bus):

    | |
    | |
    .----. || .----.
    | |---------o----|o----------| |
    | |--------o|----o-----------| |
    '----' || '----'
    | |
    | |
    (created by AACircuit v1.28.6 beta 04/19/05

    If you really want the dual redundancy you'll need to put it in --
    there's a lot more devices with one UART than two for RS-485, and CAN
    devices aren't so thick on the ground that you can jump up and down and
    insist on dual ports -- but there may be ones out there.

    The advantage of this scheme is that you can choose to add in devices
    'C' and 'D' at production time without changing code, and without
    putting in more opportunities for single-point failures beyond their


    Tim Wescott
    Wescott Design Services

    Posting from Google? See

    "Applied Control Theory for Embedded Systems" came out in April.
    See details at
  3. Ben Jackson

    Ben Jackson Guest

    CAN comes to mind, but since you mention SPI in your subject I'll rule
    that out for you. SPI is not addressable -- you need individual slave
    selects for each device, and it's not two-wire -- in/out/clk are separate.
    I2C is addressable and uses one data + one clk, but it's not really
    "ruggedized" like CAN, and the maximum length is much shorter.
  4. Eeyore

    Eeyore Guest

    Run it slowly and it could be very long indeed.

  5. Guest

    I've not heard of CAN. I was mainly looking at I2C as it seemed the
    most sensible, I hadn't read too much on SPI.. I didn't realise it
    didn't support addressing, which rules it out.

    One of the reasons I2C and SPI came it mind is they are natively
    supported by the PIC processors I'm intending to use. Obviously using
    RS485 would be quite possible, but it requires driver chip on each
    module. Having said that I'm guessing I'd need some protection on the
    PIC pins incase of shorts etc?

    Something I forgot to mention. I'm intending on running this from a
    lithium ion battery, so I'd get about 3.7volts to power the components.
    Can RS485 be driven from that?

    While I know RS485 is designed for stability, could I2C be stable in
    that environment running at 400Khz? Or would I have to drop it to
    100Khz, in whichcase I guess async serial over RS485 would be faster at
    115.2Kbit. I guess it comes down to will it work, and would the
    component count/cost of RS485 be much higher?

  6. Rich Grise

    Rich Grise Guest

    I don't know that much about I2C, except that it's a logic level and I
    wouldn't recommend going from one board to another, unless they're right
    next-door on a bus or something.

    For some reason, the acronym "LVDS" comes to mind - I think it means "low
    voltage differential signaling" - I see no reason why you couldn't slap
    some differential transciever/receiver pairs on your I/Os and run I2C
    through it or whatever you want - I really don't think 0-3.7V qualifies
    as RS485; you'd have to check on that, maybe by google.

    Good Luck!
  7. DJ Delorie

    DJ Delorie Guest

    I2C is two-wire, bidirectional, and multiplexed. One wire is clock
    (driven by the master) and the other is data. The data protocol
    starts with an address, allowing multiple slaves to be on the same
    bus. Note that any device can be the master, so both clock and data
    are bidirectional (OC drives with pullup). The intention is to be an
    on-board bus, running at 100kHz or 400kHz.
    Since I2C is bidirectional, I don't think LVDS will work with it, as
    LVDS is unidirectional.
  8. Ben Jackson

    Ben Jackson Guest

    There are PICs with CAN support.
  9. Eeyore

    Eeyore Guest

    You can use any 2 old ( open drain ) port poins to make an I2C interface. I
    use my own routines. You're not tied to any specific CPU then,

  10. Ben Jackson

    Ben Jackson Guest

    If he's worried about bus speed he probably doesn't want to bit-bang it.
  11. LVDS isn't unidirectional.

    ---Matthew Hicks
  12. DJ Delorie

    DJ Delorie Guest

    Hmmm... all the "what is LVDS" pages I've seen so far depict it with a
    single transmitter and a single receiver per channel. Do you have a
    pointer to something showing how it works bidirectionally?
  13. Rich Grise

    Rich Grise Guest

    Take the diagram, and ensure that your drivers are open-collector, then
    just run another T/R the other way - they can share the wires, since
    they're open collector, as long as your S/W knows who's supposed to be
    talking and who's supposed to be listening.

    | | X
    diff. TX, O/C [R] [R] X diff. RX
    |\ | | X |\
    | \-------+---+---|---X----+-------| \
    -----| > | | X | | >--------
    | /-------|---+---+---X--+-|-------| /
    |/ | | X | | |/
    | | X | |
    | | X | |
    diff. RX | | X | | diff. TX, O/C
    /| | | | | /|
    / |------+ | | +-----/ |
    -----< | | | < |-------------
    \ |----------+ +-------\ |
    \| \|

    Good Luck!
  14. DJ Delorie

    DJ Delorie Guest

    Ok, but I still think it would be hard to use that for an I2C
    interface, since the I2C chips are going to have one pin per channel,
    not two.
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