Searching \ for '[PIC] Multi pic single line communication' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'Multi pic single line communication'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Multi pic single line communication'
2006\07\07@040559 by Goran Hosinsky

picon face
Are there any standard ways for several pic's to communicate
with each other over one line?

The obvious way would be for the pic to listen to the line to
see if it is in use and then, if the line is free, send, but
protocols can vary I do not want to re-inwent the wheel.

I am thinking of pic's in different parts of the house. For
the moment just two or three of them, and they could each
use a separate  line, but my experience is that such projects
might grow with time and I do not want to limit myself for the
future. Cables are a multi core ones that I put into the walls
when we built the house. Speed of communications is no issue.

Goran

2006\07\07@051810 by Bob Axtell

face picon face
Goran Hosinsky wrote:
> Are there any standard ways for several pic's to communicate
> with each other over one line?
>
> The obvious way would be for the pic to listen to the line to
> see if it is in use and then, if the line is free, send, but
> protocols can vary I do not want to re-inwent the wheel.
>
> I am thinking of pic's in different parts of the house. For
> the moment just two or three of them, and they could each
> use a separate  line, but my experience is that such projects
> might grow with time and I do not want to limit myself for the
> future. Cables are a multi core ones that I put into the walls
> when we built the house. Speed of communications is no issue.
>
> Goran
>  
The way to do it is with an RS485 chip at each PIC instrument. A master
talks, and
everybody else listens, then when addressed, they seize the pair while
the Master
listens. I did a system like that for casinos, it operated over CAT3 at
4800b for
a LONG distance (3000 feet). Generally speaking, only one master
requests replies;
otherwise the seperate PICs would collide with each other. The "master"
might even
be a PC with a serial port converted to RS485. You can attach as many as
64 transceivers
onto a single bus.

RS485 (sometimes called RS422) is a differential pair system, with
terminating resistors
at the ends of the pair. The PAIR is twisted pair CAT3, solid wire
twisted about 2
turns per inch (same as telephone cable). It compensates for minor
ground differences
and works very, very well. You must use "transceivers" designed for this
service, standard
ICs won't cut the mustard.  The  system has a nominal impedance of 100
ohms, so uses
100 ohm terminating resistors. The transceivers can deliver as much as
200mA into the
bus.

--Bob

2006\07\07@070628 by olin piclist

face picon face
Goran Hosinsky wrote:
> Are there any standard ways for several pic's to communicate
> with each other over one line?

That depends on whatever "line" means.

> I am thinking of pic's in different parts of the house.

There is CAN, ethernet, and RS-485, but each require a transmission line
with at least two wires.

> For
> the moment just two or three of them, and they could each
> use a separate  line,

There's that meaningless term "line" again.  Try giving real specs.

> Cables are a multi core ones that I put into the walls
> when we built the house.

Again, try giving some real specs.  Is it CAT5, 50 ohm coax, twisted pair
telephone wire, strings going to paper cups in each room, something else?

> Speed of communications is no issue.

Look up CAN and 18F2580.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\07\07@072350 by Jan-Erik Soderholm

face picon face
Goran Hosinsky wrote :

> Are there any standard ways for several pic's to communicate
> with each other over one line?
>
> The obvious way would be for the pic to listen to the line to
> see if it is in use and then, if the line is free, send, but
> protocols can vary I do not want to re-inwent the wheel.

I've not built anything but read a lot about it, and (as others have
said) CAN does a lot of the low level communication. In particular
I like that you are communicating between "functions" rather then
between "nodes", so to speak. That makes it very easy to add
nodes/functions to the CAN-net.

Regards,
Jan-Erik.



2006\07\07@091310 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

>> Are there any standard ways for several pic's to communicate with each
>> other over one line?
>
> That depends on whatever "line" means.
>
>> I am thinking of pic's in different parts of the house.
>
> There is CAN, ethernet, and RS-485, but each require a transmission line
> with at least two wires.

If you go slow enough and design the drivers robust enough, you may be able
to use mains neutral (or the safety ground) as a common ground and really
use only one additional wire (to avoid the ambiguous term "line" :).

BTW, among the protocols Olin listed, Ethernet and RS-485 include the
physical layer, whereas CAN doesn't. There's a commonly used ISO physical
layer, but you can also hook up your own line (or wire :) driver to a PIC's
two CAN pins.

> Look up CAN and 18F2580.

Definitely. The hardware CAN protocol modules take care of so much that you
have to do in firmware with e.g. RS-485.

Gerhard

2006\07\07@120506 by Russell McMahon

face
flavicon
face
> Are there any standard ways for several pic's to communicate
> with each other over one line?

> Speed of communications is no issue.

If speed is REALLY not an issue then an extremely cheap and simple
solution is possible.

Use a single line [[[ :-) ]]] with all PIC's monitoring it. Level can
be 5v referenced to ground, or true RS232 levels with drivers or
whatever. A sender simply drives the line and all other PICs see the
signal. If you monitor while sending then collision detection is
detectable if distances are modest. The simplest 'rudest' method is to
have transmit pins coupled to the output line via diodes with anodes
to line and a pullup resistor on the 'line' (wired OR)(really a large
AND gate). When any one transmit pin goes low the line is driven via
the respective diode. If a single station always controls traffic no
collisions need occur.

Operating at around 300 baud with even 5V swing ground referenced very
respectable ranges are achievable (kilometres). Ground potential
differences and noise need to allowed for.

The same scheme can be used with RS422/485 drivers as already
mentioned.


       RM


2006\07\07@123400 by Gerhard Fiedler

picon face
Russell McMahon wrote:

{Quote hidden}

Or even better with CAN -- takes care of collision detection,
re-transmission, message framing, error checking, addressing... basically
most of the low-level stuff you'd have to do "by hand" with async serial.

Unless you can't afford the extra cost of PICs with CAN interface (and
possibly a CAN interface for the PC for testing purposes), IMO there's no
good reason to use async serial.

Gerhard

2006\07\07@134808 by dale-piclist

flavicon
face
In article <spam_OUT44AE15E4.2060607TakeThisOuTspamya.com> Goran wrote:
> Are there any standard ways for several pic's to communicate
> with each other over one line?
>
> The obvious way would be for the pic to listen to the line to
> see if it is in use and then, if the line is free, send, but
> protocols can vary I do not want to re-inwent the wheel.
>
> I am thinking of pic's in different parts of the house. For
> the moment just two or three of them, and they could each
> use a separate  line, but my experience is that such projects
> might grow with time and I do not want to limit myself for the
> future. Cables are a multi core ones that I put into the walls
> when we built the house. Speed of communications is no issue.

I am new to the PIC scene and have had the same thoughts.  Since
others have asked for more details, here are some of my requirements
(wish list items).

1. Requires only 1 PIC digital I/O pin at each node.
2. Can be implemented in small PICS, e.g. pic12f683
3. Peer-to-peer.  In other words, multi-master with each device
   capable of serving as master or slave.
4. Requires minimal external logic, preferably none.
5. Suitable for intraboard communication as well as in a LAN with
   distances of up to ~100 meters.
6. Can use a single twisted pair of existing in-house wiring,
   e.g. CAT 3 or CAT 5.

I started out thinking I'd use the 1-wire bus, but the timing
requirements are pretty tight, particularly on the slave nodes,
and I'd prefer to avoid a single master implementation.

I'm surprised I haven't found a standard way to do this.

Dale Farnsworth

2006\07\07@144803 by Goran Hosinsky

picon face
Thanks Russel, this scheme looks really simple and easy to
understand and implement. I have looked at the data
sheets for the 18F2580 but, even if the communications
protocol results simple, the whole PIC seems to be rather
daunting, I am still a beginner and learning the basics
of the 12f629 and the 16f628.
Goran


Russell McMahon wrote:
{Quote hidden}

2006\07\07@163138 by Gerhard Fiedler

picon face
dale-piclist@farnsworth.org wrote:

> (wish list items).
>
>  1. Requires only 1 PIC digital I/O pin at each node.
>  2. Can be implemented in small PICS, e.g. pic12f683

These two exclude most traditional communications hardware support like
I2C, UART or CAN. I think the one-pin requirement makes things more
difficult, especially for multi-master applications.

>  3. Peer-to-peer.  In other words, multi-master with each device
>     capable of serving as master or slave.

Check out LIN -- there are a very few micros (IIRC one PIC) that have
hardware protocol support, but it can be bit-banged. It's made for what you
seem to want, but it's still a one master protocol. I'm not sure, but I
think if you find the Dallas 1-wire bus timing requirements too tight, a
multi-master protocol without any hardware support will be difficult to
come up with.

>  4. Requires minimal external logic, preferably none.

Most communication protocols don't require much external logic, but most
require external drivers -- at least with your requirements. Unless you go
/really/ slow. You didn't state desired transmission speed, average node
data rate and number of nodes.

>  5. Suitable for intraboard communication as well as in a LAN with
>     distances of up to ~100 meters.

Pretty much everything that communicates in LANs up to 100 m is also
suitable for intraboard communication, but is usually overkill for that.
Separating the protocol part from the line interface makes that more
useful. For example RS-485, CAN and LIN buses can be run intraboard with
simple wired-or circuits instead of the line drivers.

>  6. Can use a single twisted pair of existing in-house wiring,
>     e.g. CAT 3 or CAT 5.

This one is just a matter of drivers, not that much of the protocol you
use. There are a few standard ways to drive such a wiring (Ethernet,
RS-485, the ISO 11898 CAN interface, wired-or).

> I'm surprised I haven't found a standard way to do this.

I think that the requirements you listed are not so simple (1 pin, no
hardware support, multi-master, no tight timing). I also think that it
becomes a bit easier to see what's there if you separate the protocol part
from the line driver part.

Gerhard

2006\07\07@220919 by Russell McMahon

face
flavicon
face
> Russell McMahon wrote:
>> If speed is REALLY not an issue then an extremely cheap and simple
>> solution is possible.

>> Use a single line [[[ :-) ]]] with all PIC's monitoring it. Level
>> can
>> be 5v referenced to ground, or true RS232 levels with drivers or
>> whatever.

>> Operating at around 300 baud with even 5V swing ground referenced
>> very
>> respectable ranges are achievable (kilometres). Ground potential
>> differences and noise need to allowed for.

>> The same scheme can be used with RS422/485 drivers as already
>> mentioned.

Gerhard writ:

{Quote hidden}

Cost, complexity and availability are indeed the issues.
CAN can (not the dance) add an order of magnitude complexity to the
hardware in the process of making the software more robust. It doesn't
necessarily make the software any simpler and requires a substantially
greater amount of learning. For professional or robust high speed
and/or high data volume applications there is no comparison - CAN wins
hands down. But for the task as the user specified it the simple
scheme is a very viable alternative. The ECAN RS232 or even logic
level scheme could be running in trial form on an existing system in a
few hours. CAN can't unless the user is already CAN competent and has
the hardware present as well. A logic level scheme with diode OR costs
cents to implement and parts would almost invariably be available. It
would be unusual to find such a scheme in use commercially (although I
suspect it has been done) but it meets the user's spec 'just fine'.

Something like this (on fly out of head so E&OE) should work well
enough.
While this could be done in a loop (TX&RX must be able to work
simultaneously), having interrupt driven send and receive routines and
driving this with interrupts allows it to work in the background.

This relies on collision detection working based on reading one's own
data as it is received and detecting corruption by tx/rx not matching.
Depending on the hardware used and line length etc this may not be a
reliable method of collision detection (although, as the check is byte
by byte rather than bit by bit then it will work in almost every
case).

This is essentially "Aloha net". If a master station controls
origination and timing of all messages then a high degree of circuit
utilisation and freedom from collision is possible. AFAIR the original
Aloha Net had independent tx and rx channels but this is by no means
essential. Without a master controller circuit utilisation will drop
as competing tasks become more frequent. In such cases the wait when
busy and then retry would benefit from a little thought - eg having
random wait when busy helps.

The following also restarts messages if they are corrupted part way
through.

As Gerhard notes, error checking, retransmission requests etc are
above this simple level and are already dealt with by CAN.

__________

SEND_STUFF:

HAPPY = 1

WHILE message not all sent:

   IF line is busy
       wait a while.
   ELSE

       WHILE HAPPY and message not all sent
                  Send next message byte while listening.
                  Step message pointer
                  IF received byte doesn't match sent byte
                       HAPPY = 0
                  ENDIF
       ENDWHILE

       IF HAPPY = 0
           Reset message string pointer
           HAPPY =1
      ENDIF

 ENDIF

ENDWHILE

__________


       RM

2006\07\08@110541 by Gerhard Fiedler

picon face
Russell McMahon wrote:

{Quote hidden}

Not necessarily (that's why you said "can" :). If you use a PIC and there
is a similar one available with a CAN module that is not an order of
magnitude more complex than the one you were planning to use, then not.
(And CAN is not the only applicable standard; see below.)

> It doesn't necessarily make the software any simpler

Not necessarily, but in most cases. You know that the CAN module takes care
of quite a number of things that in most applications would otherwise have
to be taken care of in firmware.

> and requires a substantially greater amount of learning.

Could be... but even if so, isn't that a principal goal of do-it-yourself?
:)  

OTOH, I can envision an individual who finds it easier to get Microchip's
ECAN module working than to design a suitable message frame and implement a
CRC.

> For professional or robust high speed and/or high data volume
> applications there is no comparison - CAN wins hands down. But for the
> task as the user specified it the simple scheme is a very viable
> alternative.

Of course -- no contest. I just wanted to point out that by the time you
have designed and implemented the protocol, you possibly could have read
the CAN module specs (or other applicable standards) and made it work.

> The ECAN RS232 ...

Sorry, you lost me here. What is "ECAN RS232"? Isn't RS-232 not really
suited for multi-master operation? And what's "ECAN" (if not Microchip's
ECAN module -- which then I don't understand in this context)?

> ... or even logic level scheme could be running in trial form on an
> existing system in a few hours. CAN can't unless the user is already CAN
> competent and has the hardware present as well.

I'd claim the same few hours for CAN -- of course only if you have a PIC
with a CAN interface. Reading the CAN module spec, grabbing an application
note and example, writing the few lines to set up the module and send out
and receive a few bytes may lead to a successful transmission in a few
hours.

Of course... it's a step away from async serial, the transmission won't
succeed unless you have at least one working receiver on the line to supply
an ACK, you can't use your old and trusted async serial tools... But I
think for whoever wants to work with robust communication among a number of
devices, one of the standard buses makes usually more sense than rolling
your own, for mainly three reasons. One is that there's a lot of thought
put in those standard buses, and while learning how they work, you usually
learn something new -- and often the system ends up better than if you had
rolled your own without knowing the standard. (Even if you decide to roll
your own, it's likely to be influenced by what you learned while learning
how a standard bus works.) Another reason is that it is usually a
(professional) advantage to know the current standards. (This of course may
not be that relevant for a hobbyist.) And the third reason is that there
usually are ready-made hardware/firmware/software implementations of common
standards that allow you to take quite some shortcuts -- once you are past
the initial learning curve of the standard.


> A logic level scheme with diode OR costs cents to implement and parts
> would almost invariably be available.

You seem to be mixing up the physical driver part of the protocol and the
higher levels: CAN (as well as LIN, see below) can very well be run over a
simple wired-or line. Not a very long line, but that's mostly a limitation
of this type of driver/medium and not the protocol. (The typical "CAN
driver" chips are not really "CAN"; they are ISO 11898 -- one of the common
physical specs used with CAN buses.)


> This is essentially "Aloha net". If a master station controls
> origination and timing of all messages then a high degree of circuit
> utilisation and freedom from collision is possible.

There's another, more current standard available for this: LIN
http://www.lin-subbus.de/. In many ways similar to what you describe here
(the master-slave version), and based on trusted async serial :)  It has
enough power behind it to make it probable to become a success (essentially
the same companies that started CAN). I think there are a number of
advantages in implementing a standard (even if only partially) rather than
rolling your own. Available example implementations is one of the
advantages:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1490&filterID=400

> As Gerhard notes, error checking, retransmission requests etc are
> above this simple level and are already dealt with by CAN.

Here's how I see it (and that may not be that different from how you see
it)...

- Roll your own: Can be quick and dirty, or quite elaborate. Once done, you
probably have added APD (Another Proprietary Design :) to the world, and
can have the rewarding feeling of uniqueness.

- Use a standard, with provided hardware/firmware/software support: Can
also be quick and dirty, or quite elaborate. If you have good support
available, can be both quick and elaborate. Once done, you know the
standard better and usually have a quite robust implementation -- if you
chose a suitable standard, of course. Has an  element of investment (into
your knowledge, into future projects).

- Roll your own implementation of a standard: Often only available in the
elaborate version. Can be challenging (e.g. for CAN), but sometimes this
may be an option. (Haven't we all at one time or another implemented a UART
in firmware? :)  Probably the most work-intensive option, but also the most
learn-intensive one -- which can be an advantage. Has an even stronger
element of investment (into your knowledge, into future projects).

- Combine different standards, partial implementations of standards (like
one protocol standard with a different physical standard): Where none of
the available standards seems to do it, this can be an option that combines
a fit with the requirements with the advantages of a standard
implementation.


Of course, if you need something /really/ quick ("like now"), waiting for a
PIC with a CAN bus interface arriving in the mail or reading the LIN spec
and working through an app note with an example implementation may not be
the way to go.

But for a project where you want to hook up a few nodes around your house
and garden, possibly need to take later wishes for enhancements into
account that you may not be fully aware right now ("might grow with time
and I do not want to limit myself for the future"), and have a certain
design and planning phase anyway, this time may not be that much of a
factor -- and neither the time it takes to become familiar with a few
standards that are close to what you want to do, before you decide whether
to roll your own or not. Also the additional expense for e.g. CAN bus
support in the PIC may not be that relevant, or the choice of an almost
ready-to-go "smart peripheral" like the MCP250xx may not be out of the
question.

Gerhard

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