Searching \ for '[EE] Multi-master bus for chip to chip communicati' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=multi+master+bus
Search entire site for: 'Multi-master bus for chip to chip communicati'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Multi-master bus for chip to chip communicati'
2009\05\08@144332 by solarwind

picon face
Hey all. For the long distance communication requirements of my
project, I will be using the CAN bus. However, I will also have a
central node which will consist of approximately 5 - 10
microcontrollers on one PCB or a set of PCBs linked together with a
short bus cable (same type as IDE cable in your computer).

What would be the best bus to use in this situation? (For the node
that is, not over long distances) I don't need blazing fast speeds.
The bus needs to be multi master to allow for any microcontroller on
the bus to talk at any point (when the bus isn't busy, that is).

So far, I've looked into a few and the only one I can find is the I2C
bus which has multi master support.

Can anyone recommend anything else?

-- [ solarwind ] -- http://solar-blogg.blogspot.com/

2009\05\08@164227 by Gerhard Fiedler

picon face
solarwind wrote:

> Hey all. For the long distance communication requirements of my
> project, I will be using the CAN bus. However, I will also have a
> central node which will consist of approximately 5 - 10
> microcontrollers on one PCB or a set of PCBs linked together with a
> short bus cable (same type as IDE cable in your computer).
>
> What would be the best bus to use in this situation? (For the node
> that is, not over long distances) I don't need blazing fast speeds.
> The bus needs to be multi master to allow for any microcontroller on
> the bus to talk at any point (when the bus isn't busy, that is).
>
> So far, I've looked into a few and the only one I can find is the I2C
> bus which has multi master support.

Why not CAN for all? I2C multi master is not that simple without good
hardware support (which PICs don't have). And you'll already do all the
work required for CAN, so why not re-use this?

Gerhard

2009\05\08@165425 by Herbert Graf

picon face
On Fri, 2009-05-08 at 14:43 -0400, solarwind wrote:
> Hey all. For the long distance communication requirements of my
> project, I will be using the CAN bus. However, I will also have a
> central node which will consist of approximately 5 - 10
> microcontrollers on one PCB or a set of PCBs linked together with a
> short bus cable (same type as IDE cable in your computer).
>
> What would be the best bus to use in this situation? (For the node
> that is, not over long distances) I don't need blazing fast speeds.
> The bus needs to be multi master to allow for any microcontroller on
> the bus to talk at any point (when the bus isn't busy, that is).
>
> So far, I've looked into a few and the only one I can find is the I2C
> bus which has multi master support.

I2C is specifically designed for that situation. Given that many PICs
have at least some I2C support in hardware I don't see a reason to go
with anything else if the specs of I2C match your requirements.

TTYL

2009\05\08@214249 by solarwind

picon face
Hmm, two very different replies:

On Fri, May 8, 2009 at 4:54 PM, Herbert Graf <spam_OUThkgrafTakeThisOuTspamgmail.com> wrote:
> I2C is specifically designed for that situation. Given that many PICs
> have at least some I2C support in hardware I don't see a reason to go
> with anything else if the specs of I2C match your requirements.

You're saying PICs have good hardware I2C support. Note that I
specifically need multi master support.

On Fri, May 8, 2009 at 4:42 PM, Gerhard Fiedler
<.....listsKILLspamspam@spam@connectionbrazil.com> wrote:
> Why not CAN for all? I2C multi master is not that simple without good
> hardware support (which PICs don't have). And you'll already do all the
> work required for CAN, so why not re-use this?

And you're saying they don't.

I like I2C. But how do I route CAN lines on the PCB? Do I just route
them like normal traces?

2009\05\09@010109 by Herbert Graf

picon face
On Fri, 2009-05-08 at 21:42 -0400, solarwind wrote:
> Hmm, two very different replies:
>
> On Fri, May 8, 2009 at 4:54 PM, Herbert Graf <hkgrafspamKILLspamgmail.com> wrote:
> > I2C is specifically designed for that situation. Given that many PICs
> > have at least some I2C support in hardware I don't see a reason to go
> > with anything else if the specs of I2C match your requirements.
>
> You're saying PICs have good hardware I2C support. Note that I
> specifically need multi master support.

Please read my post again. I said many had some I2C support.

2009\05\09@142025 by Marechiare

picon face
> Hey all. For the long distance communication requirements of my
> project, I will be using the CAN bus. However, I will also have a
> central node which will consist of approximately 5 - 10
> microcontrollers on one PCB or a set of PCBs linked together with a
> short bus cable (same type as IDE cable in your computer).
>
> What would be the best bus to use in this situation? (For the node
> that is, not over long distances) I don't need blazing fast speeds.
> The bus needs to be multi master to allow for any microcontroller on
> the bus to talk at any point (when the bus isn't busy, that is).

Perhaps you need to rethink the architecture, connect all the
microcontrollers individually to some central microcontroller over
serial lines, and let the central microcontroller handle all the
routing. Have a look at land-line phone service architecture for
example. The philosophy of "common bus" is not  necessarily the best
for every project.

2009\05\09@143839 by solarwind

picon face
On Sat, May 9, 2009 at 2:20 PM, Marechiare <.....marechiareKILLspamspam.....gmail.com> wrote:
> Perhaps you need to rethink the architecture, connect all the
> microcontrollers individually to some central microcontroller over
> serial lines, and let the central microcontroller handle all the
> routing. Have a look at land-line phone service architecture for
> example. The philosophy of "common bus" is not  necessarily the best
> for every project.

I agree that that is a far simpler way to handle a multi node network.
That was the first option that I had considered (single master, multi
slave). However, I have a need for a multi master bus. Every single
microcontroller on the bus needs to be able to initiate a message.
Each microcontroller needs to talk to the other. A central node would
be annoying because it would need to manage 20 microcontrollers and
their data. I don't want to stick anything more powerful than a
microcontroller on the bus. They will all be 8 bit in DIP packages.
Probably mostly 16F886 and a few 18F2620.

2009\05\09@161625 by Alan B. Pearce

face picon face
>> Perhaps you need to rethink the architecture,
...
>I agree that that is a far simpler way to handle a multi node network.
>That was the first option that I had considered (single master, multi
>slave). However, I have a need for a multi master bus. Every single
>microcontroller on the bus needs to be able to initiate a message.
>Each microcontroller needs to talk to the other. A central node would
>be annoying because it would need to manage 20 microcontrollers and
>their data. I don't want to stick anything more powerful than a
>microcontroller on the bus. They will all be 8 bit in DIP packages.
>Probably mostly 16F886 and a few 18F2620.

I would come back, again asking if you really need a multimaster system. If
each cluster (I am assuming that there are more than one on the wider
network, although the argument applies if there is only one cluster) has a
master device, then all you need is an interrupt from each slave to the
master.

If using an I2C bus, there is an interrupt method using the bus, but
personally I would use an individual interrupt line from each slave. Then
the master knows which slave interrupted (the one that interrupted),  and
the message format can specify which device, master or slave, is the
destination. If the destination is another slave, then there is very little
overhead for the master to pull the message in, and then send it to the
destination slave. A suitable 18F device would hardly sneeze at having this
as extra workload.

2009\05\09@200821 by Gerhard Fiedler

picon face
solarwind wrote:

> Hmm, two very different replies:
>
> On Fri, May 8, 2009 at 4:54 PM, Herbert Graf <EraseMEhkgrafspam_OUTspamTakeThisOuTgmail.com> wrote:
>> I2C is specifically designed for that situation. Given that many PICs
>> have at least some I2C support in hardware I don't see a reason to
>> go with anything else if the specs of I2C match your requirements.
>
> You're saying PICs have good hardware I2C support. Note that I
> specifically need multi master support.

Herbert said "at least some" -- that's not necessarily the same as
"good". I'd say they have good support for master and limited support
for slave. You can search the list archives and you'll see plenty of
problem descriptions for the I2C hardware in slave and multi-master
implementations.

> On Fri, May 8, 2009 at 4:42 PM, Gerhard Fiedler
> <listsspamspam_OUTconnectionbrazil.com> wrote:
>> Why not CAN for all? I2C multi master is not that simple without good
>> hardware support (which PICs don't have). And you'll already do all
>> the work required for CAN, so why not re-use this?
>
> And you're saying they don't.
>
> I like I2C.

So do I. But in this case, it seems to me that the cost/benefit
trade-off is on the side of the CAN bus: you want to support it on one
device already, so why not use the same code on all?

> But how do I route CAN lines on the PCB? Do I just route them like
> normal traces?

Yes. The wired bus can just continue on the PCB in the form of traces.
Think of traces as flat wires :)

Gerhard

2009\05\09@201350 by solarwind

picon face
On Sat, May 9, 2009 at 8:08 PM, Gerhard Fiedler
<@spam@listsKILLspamspamconnectionbrazil.com> wrote:
> Yes. The wired bus can just continue on the PCB in the form of traces.
> Think of traces as flat wires :)

That can't cross over each other like twisted pairs.

2009\05\10@090306 by olin piclist

face picon face
solarwind wrote:
> I agree that that is a far simpler way to handle a multi node network.
> That was the first option that I had considered (single master, multi
> slave). However, I have a need for a multi master bus. Every single
> microcontroller on the bus needs to be able to initiate a message.
> Each microcontroller needs to talk to the other. A central node would
> be annoying because it would need to manage 20 microcontrollers and
> their data. I don't want to stick anything more powerful than a
> microcontroller on the bus. They will all be 8 bit in DIP packages.
> Probably mostly 16F886 and a few 18F2620.

This sounds like the tail wagging the dog.  You seem to have a bunch of
"requirements" that are really due to how you imagine it should be
implemented.  IIC is not well suited to going off board and being
multi-master, especially with 20 nodes on it.  Explain what this cluster of
microcontrollers is supposed to accomplish and why they all need to talk
peer to peer asynchronously.  There may be a better way to solve the overall
problem.

You already have a CAN bus going to the remote temperature sensors.  You
might as well tie all the micros in the cluster to the same CAN bus and make
them all the same CAN-enabled micro, like a 18F2580.  Then you can probably
merge the job of several of the smaller micros onto one 18F2580 or '4580.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\10@090323 by Marechiare

picon face
>> Perhaps you need to rethink the architecture, connect
>> all the microcontrollers individually to some central
>> microcontroller over serial lines, and let the central
>> microcontroller handle all the routing. Have a look at
>> land-line phone service architecture for example. The
>> philosophy of "common bus" is not  necessarily the
>> best for every project.
>
> I agree that that is a far simpler way to handle a multi
> node network.

It is not necessarily simpler, it depends upon the app.


> A central node would be annoying because it would
> need to manage 20 microcontrollers and their data.

Creating distributed, and reliable, and noise-immune, and
constant-impedance, and etc etc, daisy-chain bus could be "annoying"
as well.


> I don't want to stick anything more powerful than a
> microcontroller on the bus. They will all be 8 bit in DIP packages.
> Probably mostly 16F886 and a few 18F2620.

Well, you could arrange 10 cheap dedicated PICs (each with 2 RS232)
within one PCB. Let them connect to their remote PICs, but within the
PCB they will be arranged into some bus.

2009\05\10@091204 by Gerhard Fiedler

picon face
solarwind wrote:

>> Yes. The wired bus can just continue on the PCB in the form of
>> traces. Think of traces as flat wires :)
>
> That can't cross over each other like twisted pairs.

For the short distances on the PCB, it's not necessary to twist the
pairs. You wouldn't even have a pair to twist with IIC :)

Gerhard

2009\05\10@131746 by Harold Hallikainen

face
flavicon
face
If 485 bus is not appropriate, you can do a simple open drain bus using
uarts with a diode so the uart can only pull the bus low. A pull-up
resistor holds it high when the bus is idle. Then, as before, you can use
various anti-collision methods (Aloha, slotted, mini-slotted, etc.). I've
also used the open drain (or collector) bus for longer distances. There, a
PIC drove an opto coupler that had a transistor as its output. A twisted
pair bus went to all nodes. At each node, it was connected across the opto
transistor. The bus was grounded only at the "receiving station." This was
a monitor system watching the batteries in a series string in an electric
car. It used Aloha where each unit would transmit its data at random
times. If there was a collision, we missed that data, but would probably
get the next. We sent voltage, current, temperature, and "bypass current"
(current shunted around the battery during charging to prevent
overcharging).

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2009\05\10@131749 by Harold Hallikainen

face
flavicon
face
Using a 485 bus, there are a variety of options for device to device
communications without going through a master device. Here are some
possibilities.

1. Use Aloha protocol where each device just transmits when it has
something to send. If the overall traffic is low, most of the time there
will be no collision. If missed data is not critical (the next sample is
fine), only error checking on the receive side is required. No retransmit
is required.

2. A master grants permission to each device to transmit in turn. This
avoids collisions, but fails when the master dies.

3. Slotted network. Each node is granted a time slot when it is allowed to
transmit. Each node has a timer that keeps track of which slot we're on.
Received data (including that destined elsewhere) synchronizes the slot
counter.

4. Mini-Slotted network. A sequence of short time slots (shorter than
required for a message, but long enough for a node to start transmitting),
are allocated, one to each node. As in slotted, each node has a timer and
a mini-slot counter. When the mini-slot counter matches the node number,
this node is allowed to start transmitting and does start transmitting if
it has anything to say. On detecting data, all other nodes stop their
mini-slot timers and hold off advancing the mini-slot counter until
mini-slot time after the last byte is received. Then, they all start
advancing the mini-slot counters again. As with a slot system, each node
synchronizes its mini-slot counter based on received traffic. I've also
called this an "absence of data token passing system." A lack of data
transmission passes the permission to transmit on to the next node. This
is the system I used using Bell 202 modems on voice grade wire and radio
circuits in the DRC190
(louise.hallikainen.org/BroadcastHistory/index.php/HallikainenAndFriends
)

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2009\05\10@140911 by solarwind

picon face
On Sat, May 9, 2009 at 4:34 PM, Harold Hallikainen
<KILLspamharoldKILLspamspamhallikainen.org> wrote:
{Quote hidden}

Thanks a lot for the detailed info. But all this is probably too
complicated for me at this stage. I'll stick with CAN and I2C for now.
But when I get more knowledge on the subject, I'll definitely refer to
your post. Thanks!

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...