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

[[email protected]]

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?

Mike

 

[Tim Wescott]

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?

Mike

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 www.tech-chat.de)

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

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

 

[Ben Jackson]

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.

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.

 

[Eeyore]

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.

Run it slowly and it could be very long indeed.

Graham

 

[[email protected]]

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?

Michael

 

[Rich Grise]

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?

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!
Rich

 

[DJ Delorie]

I don't know that much about I2C, except that it's a logic level and I

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.

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.

Since I2C is bidirectional, I don't think LVDS will work with it, as
LVDS is unidirectional.

 

[Ben Jackson]

I've not heard of CAN.

One of the reasons I2C and SPI came it mind is they are natively
supported by the PIC processors I'm intending to use.

There are PICs with CAN support.

 

[Eeyore]

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.

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,

Graham

 

[Ben Jackson]

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,

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

 

[Matthew Hicks]

LVDS isn't unidirectional.


---Matthew Hicks

 

[DJ Delorie]

LVDS isn't unidirectional.

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?

 

[Rich Grise]

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?

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.

lessee...
interface
| | 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!
Rich

 

[Matthew Hicks]

There is an example at
http://www.interfacebus.com/Design_Connector_LVDS.html. Most standards
don't use it because it makes the system half-duplex and you might have to
deal with bus arbitration.


---Matthew Hicks

 

[DJ Delorie]

There is an example at
http://www.interfacebus.com/Design_Connector_LVDS.html. Most standards
don't use it because it makes the system half-duplex and you might have to
deal with bus arbitration.

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.