Searching \ for '[PIC]: Simple PIC-to-PIC communications options?' 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/microchip/devices.htm?key=pic
Search entire site for: 'Simple PIC-to-PIC communications options?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Simple PIC-to-PIC communications options?'
2005\05\19@152534 by PicDude

flavicon
face
Hi all,

Looking for a simple way to have multiple PICs communicate with each other
over distances of up to a couple hundred feet (which conservatively includes
the vertical lengths up to the ceiling).  Currently I'd say about 10 rooms,
but expandability to say 16 rooms would be nice.  Data speed is low (each
message will only be a few bytes long, and messages should not exceed 1 per
minute).  But to reduce wiring, I'd like to use a bus type system, rather
than a star-type configuration with a central room acting as a hub.  With the
bus type system, I will designate one PIC as the master and the rest as
slaves.

>From what I understand of SPI, I will need a separate slave-select line for
each slave, so that adds more wires.  My understanding of I2C is that it is
truly a bus system -- just 2 wires can be shared among all PICs.  Add power
and ground, and I can use plain jane 4-conductor telephone wire for this --
nice! Another benefit is that I would like to use PIC16F872's all around, and
these have I2C built in.

The issue though, is that I2C has a limited distance, though I understand that
at lower speeds, I can get more distance.  But how much?  I have yet to learn
the specifics of I2C, including the various speeds available, but at a high
level, would a couple hundred feet reliably be possible for my snail-like
data-rate?

One option to solve this, is to add on one of Philip's I2C bus extenders such
as the P82B715 ($3.38 ea from Digikey, and available in picdude-friendly SOIC
packaging).  Would this extender be necessary for my app?

I've also looked at 1-wire, which is appealing, but implementation looks more
time-consuming, since the PIC does not have 1-wire support built in.  Sure, I
can code it in, but simplicity is an appealing factor for this one-off
project.

Cheers,
-Neil.





2005\05\19@153635 by William Bross

picon face
How about using the UART and an 8 pin half duplex RS485 connection.  
Just 2 wires from room to room and one extra port pin for direction
control.  Good to about 4K feet.  Implement a simple comm protocol and
some addressing and you are all set.

Bill

PicDude wrote:

{Quote hidden}

2005\05\19@154533 by Shawn Tan Ser Ngiap

flavicon
face
I wonder if something like this would help... It's low speed... and the
current is driven from an external source, not the PIC.. You can do the flow
control in software..
http://jap.hu/electronic/pbus.html

> Looking for a simple way to have multiple PICs communicate with each other
> over distances of up to a couple hundred feet (which conservatively
> includes the vertical lengths up to the ceiling).  Currently I'd say about

--
with metta,
Shawn Tan

2005\05\19@154654 by olin_piclist

face picon face
PicDude wrote:
> Looking for a simple way to have multiple PICs communicate with each
> other over distances of up to a couple hundred feet
> ...
> Data speed is low (each message will only be a few
> bytes long, and messages should not exceed 1 per minute).

SPI and IIC are not good choices because they have single ended signals and
their impedences are designed for staying on a single board and not being
exposed to environmental noise.

A few years ago I think the answer would have been RS-485, but today CAN is
the better answer.  CAN is differential, and you get the lowest protocol
levels implemented in hardware right in the microcontroller.  I think it's
exactly what you're looking for.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\05\19@154910 by William Bross

picon face
Neil,
I just checked the F872 and it doesn't have a UART. ( I've never used a
part that didn't have a UART since I begrudgingly deserted the old 5x
stuff years ago!)  I'd bump up to the F873A and use the UART unless you
have a closet full of F872s.  Monkeying around with any of the three
ways you mentioned might get a bit tedious at those distances.  RS485 is
easy, noise immune and cheaper.
Bill

PicDude wrote:

{Quote hidden}

2005\05\19@160326 by PicDude

flavicon
face
Hmmm... good thought.  I had always thought that RS485 was similar to RS232 in
terms of being a 2-node link.  I've just checked and found it really is a bus
structure, so I'll go do some research on it.

BTW, what do you mean by "8-pin"?  Are you referring to the interface chip
(such as ST485)?

Cheers,
-Neil.


On Thursday 19 May 2005 02:36 pm, William Bross scribbled:
> How about using the UART and an 8 pin half duplex RS485 connection.
> Just 2 wires from room to room and one extra port pin for direction
> control.  Good to about 4K feet.  Implement a simple comm protocol and
> some addressing and you are all set.
>
> Bill


2005\05\19@162142 by PicDude

flavicon
face
On Thursday 19 May 2005 02:47 pm, Olin Lathrop scribbled:
> SPI and IIC are not good choices because they have single ended signals and
> their impedences are designed for staying on a single board and not being
> exposed to environmental noise.

Yep -- noise will be a problem here.  But wouldn't the drivers (such as the
Philips part I mentioned) correct this?


> A few years ago I think the answer would have been RS-485, but today CAN is
> the better answer.  CAN is differential, and you get the lowest protocol
> levels implemented in hardware right in the microcontroller.  I think it's
> exactly what you're looking for.

But differential means I would need 2 wires for each direction, or 6 wires
total including power and ground, right?  I never thought about CAN for this,
but I'll go have a look in to it.

Cheers,
-Neil.


2005\05\19@162528 by PicDude

flavicon
face
I'm not sure I see the benefits in this, over say standard RS485.  I'd still
need some sort of line driver for it, right?

Cheers,
-Neil.


On Thursday 19 May 2005 02:45 pm, Shawn Tan Ser Ngiap scribbled:
> I wonder if something like this would help... It's low speed... and the
> current is driven from an external source, not the PIC.. You can do the
> flow control in software..
> http://jap.hu/electronic/pbus.html


2005\05\19@164646 by Wouter van Ooijen

face picon face
> Looking for a simple way to have multiple PICs communicate
> with each other
> over distances of up to a couple hundred feet (which
> conservatively includes
> the vertical lengths up to the ceiling).

I have designed such a thing using a daisy chain: each node restores the
voltage levels. For me cost was a big issue, so I used HCTTL, but you
could also use RS232. In my case it is used in greenhouses, a chain can
contain ~ 100 nodes, with a few meteres between each node. The whole
systems was designed to chain chains, so it could address a grid. The
protocol includes broadcast bootloading. A node was one HCTTL chip + a
16F819. Note: no crystal or resonator.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\05\20@002404 by Matthew Miller

flavicon
face
Hi,

On Thu, May 19, 2005 at 02:26:31PM -0500, PicDude wrote:
>
> The issue though, is that I2C has a limited distance, though I understand that
> at lower speeds, I can get more distance.  But how much?  I have yet to learn
> the specifics of I2C, including the various speeds available, but at a high
> level, would a couple hundred feet reliably be possible for my snail-like
> data-rate?

I doubt that I2C will work at those distances. The main problems will be
noise, and the capacitance of the lines (I don't have the I2C spec. handy so
I can't tell you what the max capacitance is.) Don't expect I2C to work for
more that a couple of meters. I have seen it work at upto three meters
before.

Olin's suggestion of using the CAN bus is a good one. I've only read about
it, but it seems to do what you want. Myself, I would use RS-485 since I'm
familiar with it. If you go the RS-485 route, look at the ltc1482
transceiver chip. It seems to be about the only transceiver that has a
carrier detect function; this simplifies things a great deal.

Also, if you're only interested in half-duplex you only need one twisted
pair, but this might not matter much seeing how cheap cat-5 cable is
compared to almost any other type.

Take care, Matthew.

--
"This is not a scientific issue, it's a political issue," he said.
"There isn't a scientific issue about the validity of evolution. The
only issue is whether schoolchildren will learn real science or not."
         -- Adrian Melott

2005\05\20@011251 by Herbert Graf

flavicon
face
On Fri, 2005-05-20 at 00:24 -0400, Matthew Miller wrote:
> Hi,
>
> On Thu, May 19, 2005 at 02:26:31PM -0500, PicDude wrote:
> >
> > The issue though, is that I2C has a limited distance, though I understand that
> > at lower speeds, I can get more distance.  But how much?  I have yet to learn
> > the specifics of I2C, including the various speeds available, but at a high
> > level, would a couple hundred feet reliably be possible for my snail-like
> > data-rate?
>
> I doubt that I2C will work at those distances. The main problems will be
> noise, and the capacitance of the lines (I don't have the I2C spec. handy so
> I can't tell you what the max capacitance is.) Don't expect I2C to work for
> more that a couple of meters. I have seen it work at upto three meters
> before.

I agree I2C may not be the best choice, but it's certainly not limited
to small distances.

My house monitoring network is I2C, and the farthest station is about 20
meters (60 feet). As long as you do things slow enough I2C is definitely
possible to get working.

That said, even going to a "multidrop" rs232 would be far better, with
rs485 and CAN being much preferred options. TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\05\20@032107 by Michael Rigby-Jones

picon face


{Quote hidden}

Philips has an app-note on using I2C over distances of 1km using special
buffers, so it is possible.  However, wether it's worth the bother when
there are other widely used comms standards that work out of the box for
the distances the OP is interested in is debatable.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\05\20@041452 by Alan B. Pearce

face picon face
>> The issue though, is that I2C has a limited distance, though I
>> understand that at lower speeds, I can get more distance.
...
>I doubt that I2C will work at those distances. The main problems
>will be noise, and the capacitance of the lines (I don't have the
>I2C spec. handy so I can't tell you what the max capacitance is.)
>Don't expect I2C to work for more that a couple of meters. I have
>seen it work at upto three meters before.

There is no reason you couldn't run an I2C bus real slow (1KHz clock rate or
slower if you wanted), but I agree that there are various other items about
the spec that would probably make it less than ideal for this application.

>Olin's suggestion of using the CAN bus is a good one. I've only
>read about it, but it seems to do what you want.

That was my immediate thought too when I saw the request. The only potential
problem I see with it is that the message length is limited to 8 bytes per
block, so you need some way of concatenating blocks for a longer message.
However from the OP description I get the impression this would not be a
problem. Also has the advantage that you don't have a master device as such,
and you have priorities and broadcast capabilities.

>Myself, I would use RS-485 since I'm familiar with it. If you go the
>RS-485 route, look at the ltc1482 transceiver chip. It seems to be
>about the only transceiver that has a carrier detect function; this
>simplifies things a great deal.

Only disadvantage I see is that the handshake/priority handling is done in
software, where it is in the interface hardware for CAN, but you can have
longer messages.

2005\05\20@050858 by Fr10

flavicon
face

Dallas 1820 temperature IC use a true two wire protocol

I would also go for the RS485. (Don't know CAN jet)

I was once experimenting with two 16F84
Only two wires between the master and the slave.(GND and 12V)
Slave had a backup battery

While you dont transmit data  - charge the battery!

Otherwise pulse the 12V Line for data transfer (few bytes every minute
should not be a problem)

Francois


2005\05\20@072111 by olin_piclist

face picon face
PicDude wrote:
>> CAN is differential, and you get the lowest
>> protocol levels implemented in hardware right in the microcontroller.
>
> But differential means I would need 2 wires for each direction, or 6
> wires total including power and ground, right?

No.  CAN is a single signal bus.  That signal is implemented as a
differential pair, so it requires two wires.  With ground, that's a minimum
of 3 wires.  If you want to bus around power too, then you need 4 wires.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\05\20@084114 by William Bross

picon face
Yep.  ST485, SN75176 ......  provided it's half duplex so it's only 2
wires.  Develop a simple protocol or just copy one of the dozens already
found on the web.  I've been doing it this way since about 1976 and
still find it one of the cheapest and easiest comm links to establish.

Bill

PicDude wrote:

{Quote hidden}

2005\05\20@112935 by Shawn Tan Ser Ngiap

flavicon
face
On Thursday 19 May 2005 09:26 pm, PicDude wrote:
> I'm not sure I see the benefits in this, over say standard RS485.  I'd
> still need some sort of line driver for it, right?

You can drive the signal line from the power supply in a pull-up fashion..
cause the PIC UART doesn't drive the line directly.. It only sinks, not
source current...

It just needs a diode, and it uses only 1 wire for comms.. which is a drawback
with a fixed DC voltage on that line during "idle" times... So, i don't know
if there are advantages over RS485...

cheers..

--
with metta,
Shawn Tan

2005\05\20@120933 by olin_piclist

face picon face
Shawn Tan Ser Ngiap wrote:
> You can drive the signal line from the power supply in a pull-up
> fashion.. cause the PIC UART doesn't drive the line directly.. It only
> sinks, not source current...

Huh?  Where did you get this from?  I'm pretty sure this is incorrect.

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\05\20@202804 by PicDude

flavicon
face
Hey folks,

Haven't had a chance to real the gobs of docs on the various protocols yet,
but thought I'd pass along a couple nice links I found that
summarizes/compares protocols (beware, links may wrap) ...

http://www.embedded.com/story/OEG20020528S0057

http://www.mikroelektronika.co.yu/english/product/books/picbasicbook/09.htm

Cheers,
-Neil.



On Friday 20 May 2005 07:41 am, William Bross scribbled:
{Quote hidden}

2005\05\21@071642 by Howard Winter

face
flavicon
picon face
I'd go with the suggestion to use CAN - it's designed for just the sort of thing you are talking about, and
it's very reliable and noise-tolerant.  It's not the cheapest way to go - you need a line-driver chip (eg.
MCP2551) and either a PIC that has CAN already (eg. 18F258) or you need a CAN controller chip (eg. MCP2510 -
note the close resemblence in part numbers - they do very different jobs!) at each point in the system.

The thing I noticed that rang a warning bell:  you are planning to use telephone cable, and include the power
supply along it, I think?  You need to check the current-carrying capability you need, and the voltage drop
you are going to get.  Unless the cable run is very short, and you said it wasn't, you will need to feed a
high-ish voltage down the cable and regulate it at each unit.  Power Over Ethernet, for example, uses 48V fed
through Cat5 cabling, but you can probably get away with 12V or so if your units need 5V.  (I hope you weren't
expecting to put 5V in at the Master end and just pick it off at each point!  :-)

Cheers,


Howard Winter
St.Albans, England


2005\05\21@145105 by PicDude

flavicon
face
On Saturday 21 May 2005 06:16 am, Howard Winter scribbled:
> I'd go with the suggestion to use CAN - it's designed for just the sort of
> thing you are talking about, and it's very reliable and noise-tolerant.
> It's not the cheapest way to go - you need a line-driver chip (eg. MCP2551)
> and either a PIC that has CAN already (eg. 18F258) or you need a CAN
> controller chip (eg. MCP2510 - note the close resemblence in part numbers -
> they do very different jobs!) at each point in the system.

The latter is what I'm leaning towards, since I have gob-loads of PIC16F872's
here.  But in my few readings so far, it seems that CAN-SPI will be different
to implement than CAN.  Different, not necessarily difficult.  I've still got
a bunch to read on this though.


> The thing I noticed that rang a warning bell:  you are planning to use
> telephone cable, and include the power supply along it, I think?  You need
> to check the current-carrying capability you need, and the voltage drop you
> are going to get.  Unless the cable run is very short, and you said it
> wasn't, you will need to feed a high-ish voltage down the cable and
> regulate it at each unit.  Power Over Ethernet, for example, uses 48V fed
> through Cat5 cabling, but you can probably get away with 12V or so if your
> units need 5V.  (I hope you weren't expecting to put 5V in at the Master
> end and just pick it off at each point!  :-)

I had done the math on this a while back and figuring that each station will
take 30-50 mA, I can't really send 5V along the lines.,  At first I thought I
didn't care if I had a 0.5V or even 1V drop using LF PICs, but then realized
it would be bad for the communications.  So I'm leaning towards 12V and plain
jane 7805's.

Cheers,
-Neil.



>
> Cheers,
>
>
> Howard Winter
> St.Albans, England


2005\05\23@043229 by Alan B. Pearce

face picon face
>I had done the math on this a while back and figuring that each
>station will take 30-50 mA, I can't really send 5V along the lines.
...
>So I'm leaning towards 12V and plain jane 7805's.

At that rate I would suggest looking at some of the small switching
regulators around. Linear Technology have some small ones which need just an
inductor and capacitor IIRC, but it is a while since I looked at them.

2005\05\23@073255 by Gerhard Fiedler

picon face
PicDude wrote:

> I'm not sure I see the benefits in this, over say standard RS485.  

The advantage over RS485 is that you don't need to handle a driver enable
line, as the drivers for this bus are all always active (it's a wired-and
type bus, or an I2C-like bus, or however you want to call such a
structure).

> I'd still need some sort of line driver for it, right?

Right. In the simple form as described on the page, the "line driver" is a
pull-up resistor on the line and decoupling diodes to pull the line down.

Gerhard

2005\05\23@074747 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

>>> CAN is differential, and you get the lowest protocol levels implemented
>>> in hardware right in the microcontroller.
>>
>> But differential means I would need 2 wires for each direction, or 6
>> wires total including power and ground, right?
>
> No.  CAN is a single signal bus.  That signal is implemented as a
> differential pair, so it requires two wires.  With ground, that's a
> minimum of 3 wires.  If you want to bus around power too, then you need
> 4 wires.

Actually, the signal layer is not part of the CAN specification. The most
common CAN line driver implementation is probably ISO11898-2, which is a
two-wire communication, and that's probably what Olin referred to. The
simplest CAN line driver implementation is an IIC-type bus (yes, that can
be CAN, too :). Anyway, there are CAN line drivers that use only one wire
(or some that can operate in both one-wire and two-wire modes).

So if the reduced noise tolerance you get with only one wire is good enough
for you, you can have a CAN bus plus supply with three wires.

Check out here for starters:
http://www.kvaser.com/can/products/drivers.htm

You also can roll your own CAN line driver, and if the devices don't
require a lot of power, you can drive the power supply line with the CAN
signal (or to say it the other way 'round: derive the power supply from the
CAN signal line). That works in much the same way as the many circuits that
derive power from RS232-type signal lines. With that, you're down to two
wires.

It all depends on the exact specs and how you weigh the various trade-offs.

Gerhard

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