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\25@120609 by PicDude

flavicon
face
So I've decided to go with RS485 for this app.  CAN looked really appealing,
but I chose RS485 since it seems simpler to implement, and should cost less
(though a few extra bucks on each board for CAN isn't really much of an
issue).

Also decided that I will run 8-9V on the lines and regulate that down to 5V on
each board.  Should make for a simple circuit and use up some of the parts I
have laying around.

What I find odd is that the protocol seems really popular, but not much code
example around.  No prob though, cause it does seem really simple.

Thanks for the info/help,
-Neil.



2005\05\25@130509 by Jan-Erik Soderholm

face picon face
PicDude wrote :

> So I've decided to go with RS485 for this app...
> ...
> What I find odd is that the protocol seems really popular,
> but not much code example around...

Probably becuse RS485 isn't a *protocol*, but a specification
of an electrical transmission medium/cabling. You don't write
*specific* software for RS485 (like you can do for e.g. CAN).
You have to add whatever protocol you need on top of RS485.

Jan-Erik.



2005\05\25@133143 by olin_piclist

face picon face
PicDude wrote:
> What I find odd is that the protocol seems really popular, but not much
> code example around.

RS-485 does not specify a protocol, only the electrical interface.
Different implementations are therefore not compatible with each other.
Most implementations tend to be private protocols that suite just the
specific need at hand.

> No prob though, cause it does seem really simple.

You won't be saying that once you try to work out the details.  Your
protocol will have to ensure there are no collisions.  You can't let
collisions happen because there are no guaranteed dominant and recessive bus
states, so the result of a collision may look different to different
receivers.  What happens when a node has something to say, but it can't just
squawk it out?  Do you have a master that queries each node in turn?  How
many nodes does it query?  What happens when a queried node goes down?  Do
you wait for some timeout?  How do you detect new nodes being added?  Will
you leave enough room in your home grown protocol to accomodate future
expansion?

These questions will require some careful thought, and the solution will
most likely not be trivial.  There will be many compromises, and the
resulting firmware will be a lot more complicated than you think.


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

2005\05\25@153353 by PicDude

flavicon
face
On Wednesday 25 May 2005 12:32 pm, Olin Lathrop scribbled:
> ...  What happens when a node has something to say, but it can't
> just squawk it out?  Do you have a master that queries each node in turn?
> How many nodes does it query?  What happens when a queried node goes down?
> Do you wait for some timeout?  How do you detect new nodes being added?
> Will you leave enough room in your home grown protocol to accomodate future
> expansion?


So far, my thoughts for most of this are as follows...
- Master will query each node in sequence asking "do you want to send
anything"?
- Master will wait for a specified time for a response.  No response in
specified time means an error occurred.  I've been toying with the idea of
re-trying once or twice, but haven't determined that yet.  Any error is
indicated at the master station (specifics TBD).
- When the master gets a response, it will be addressed on the bus to the
master, but the data will indicate if it is intended for another station, and
the master will pass it along.
- I'm planning to implement an acknowledgement to the slave that message was
received.
- Master will send out message on the bus, which the appropriate slave will
respond to.
- Master will expect an acknowledgement within a certain time, else error.
- Master will continue with next node.
- I might need a broadcast message, but will not expect an acknowledgement for
that.  If I do, I'll have the master send it to all stations
individually/sequentially.  Latency is not an issue here.

At this point, there will be about 10 stations, but I was planning to allow
for 16.  However, for simplicity, and since traffic will be relatively low,
I'm thinking I'll just send a full byte as the station id/address, and
another with the command, and perhaps a third with some checksum, etc.  That
last part is yet TBD.

The messaging will be very specific to each station, so new nodes will require
a firmware change at the master, since it will need to be setup based on the
type of node.  I don't plan to put anything automatic in for this.

Cheers,
-Neil.


2005\05\25@160122 by Matthew Miller

flavicon
face
On Wed, May 25, 2005 at 11:08:02AM -0500, PicDude wrote:
> So I've decided to go with RS485 for this app.  CAN looked really appealing,
> but I chose RS485 since it seems simpler to implement, and should cost less
> (though a few extra bucks on each board for CAN isn't really much of an
> issue).
>
> Also decided that I will run 8-9V on the lines and regulate that down to 5V on
> each board.  Should make for a simple circuit and use up some of the parts I
> have laying around.
>
> What I find odd is that the protocol seems really popular, but not much code
> example around.  No prob though, cause it does seem really simple.

Check out this page: http://www.vscp.org/ the Very Simple Control Protocol
may be just what your looking for.

Matthew.

--
   That humanity at large will ever be able to dispense with Artificial
Paradises seems very unlikely.  Most men and women lead lives at
the worst so painful, at the best so monotonous, poor and limited
that the urge to escape, the longing to transcend themselves if only
for a few moments, is and has always been one of the principal
appetites of the soul.  -- Aldous Huxley

2005\05\25@160952 by Byron A Jeff

face picon face
On Wed, May 25, 2005 at 02:35:49PM -0500, PicDude wrote:
> On Wednesday 25 May 2005 12:32 pm, Olin Lathrop scribbled:
> > ...  What happens when a node has something to say, but it can't
> > just squawk it out?  Do you have a master that queries each node in turn?
> > How many nodes does it query?  What happens when a queried node goes down?
> > Do you wait for some timeout?  How do you detect new nodes being added?
> > Will you leave enough room in your home grown protocol to accomodate future
> > expansion?
>

Olin is right. It's a tough problem. I had tackled it at one time using a
two level priority scheme. I'd have to go find it though. Also I never got
a chance to implement it.

>
> So far, my thoughts for most of this are as follows...
> - Master will query each node in sequence asking "do you want to send
> anything"?

Fine as long as no new nodes are being added as Olin specified

> - Master will wait for a specified time for a response.  No response in
> specified time means an error occurred.  I've been toying with the idea of
> re-trying once or twice, but haven't determined that yet.  Any error is
> indicated at the master station (specifics TBD).

That should be good enough.

> - When the master gets a response, it will be addressed on the bus to the
> master, but the data will indicate if it is intended for another station, and
> the master will pass it along.

If you're going that route then you may want to implement virtual token
passing instead. Operate with the presumption that all stations will be
well behaved. Then when a station wants to talk and it has the token, it
can speak to any target it wants. When it's finished it passes the token
to the next node.

There's no real point in have double transmissions if nodes need to talk
directly to one another. Primary/secondary based systems work best when all
of the secondaries need to interact with the primary.

> - I'm planning to implement an acknowledgement to the slave that message was
> received.

That will facilitate flow control. But how will you know when the addressed
node is finished sending?

{Quote hidden}

But that doesn't jibe with "about 10 ... planning to allow for 16". Either it's
fixed and you hardcode it, or it's not and you allow new stations to join.

It feels like you picked the primary/secondary model out of thin air. Token
passing is more flexible and also eliminates contention.

BAJ

2005\05\25@163123 by PicDude

flavicon
face
On Wednesday 25 May 2005 03:09 pm, Byron A Jeff scribbled:
> There's no real point in have double transmissions if nodes need to talk
> directly to one another. Primary/secondary based systems work best when all
> of the secondaries need to interact with the primary.

I came up with this since in a significant majority of cases, the master will
need to be informed of the event, and the slave will want to communicate the
message to more than one other slave.  Having each slave send out a message
to more than one other slave seems like a mess as they would be communicating
without the master letting them do so.

I also thought of a scheme where each bit on a couple bytes would represent a
unique node.  In one message, multiple specific nodes could be addressed.  
But this turn out to be another can of worms for the acknowledgements.  All
sorts of odd thoughts of having each station acknowledge after waiting a
specific differing time followed, which resulted in my head spontaneous
combusting. :-)


> > - I'm planning to implement an acknowledgement to the slave that message
> > was received.
>
> That will facilitate flow control. But how will you know when the addressed
> node is finished sending?

FIxed length messages.  So far 3 bytes per message, which includes the
address.


> But that doesn't jibe with "about 10 ... planning to allow for 16". Either
> it's fixed and you hardcode it, or it's not and you allow new stations to
> join.

Allowing for 16 in case needed in the future, and with this scheme, I'll have
some simple flags in the code to indicate which types of messages need to be
send to which stations (depending on the type of station).  I'd need to set
these flags in the code for the new station ID and re-compile.  By planning,
I mean that I will not need to re-write the code using a different message
length, etc -- just set flags and re-compile the firmware.


> It feels like you picked the primary/secondary model out of thin air. Token
> passing is more flexible and also eliminates contention.

There is another term to descibe where it came from, but I'll refrain from
stating it here :-)  Okay, not really -- the need to have a message mostly go
to multiple stations made this scheme somewhat "natural" (at least for me).  
I'll do some thinking about the token method.


Thanks,
-Neil.

2005\05\25@164019 by Jan-Erik Soderholm

face picon face
PicDude wrote :


> I'd need to set these flags in the code for the new
> station ID and re-compile.  By planning, I mean that I
> will not need to re-write the code using a different message
> length, etc -- just set flags and re-compile the firmware.

Or put them in EEPROM, so you can reconfigure on-the-fly
from e.g. a PC.

Jan-Erik.



2005\05\25@185257 by olin_piclist

face picon face
PicDude wrote:
{Quote hidden}

A lot more complicated than you first thought, isn't it?  And there are a
few more details you haven't yet thought about.  Yes, I've done this.

Now, is this *really* simpler than CAN?


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

2005\05\25@185730 by olin_piclist

face picon face
Byron A Jeff wrote:
> It feels like you picked the primary/secondary model out of thin air.
> Token passing is more flexible and also eliminates contention.

True, but it comes with its own set of problems.  If a node goes down and
doesn't pass on the token things get messy, especially in a pure peer to
peer environment.


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

2005\05\25@190520 by olin_piclist

face picon face
PicDude wrote:
> I came up with this since in a significant majority of cases, the
> master will need to be informed of the event, and the slave will want
> to communicate the message to more than one other slave.  Having each
> slave send out a message to more than one other slave seems like a mess
> as they would be communicating without the master letting them do so.

Remember that all nodes must watch the bus all the time.  All slaves
therefore see a message sent by another slave, although the sending slave
never knows for sure they received it...

I think you're starting to glimpse how big this can of worms really is.  As
I said, I've done all this.  In the end it worked reliably and did
everything we wanted it to, but it is something I classify as "advanced".

> I also thought of a scheme where each bit on a couple bytes would
> represent a unique node.  In one message, multiple specific nodes could
> be addressed. But this turn out to be another can of worms for the
> acknowledgements.  All sorts of odd thoughts of having each station
> acknowledge after waiting a specific differing time followed, which
> resulted in my head spontaneous combusting. :-)

More worms.  The big issue you haven't seemed to hit on yet is reliability.
You should assume that the bus has a small but finite error rate.  Checksums
are good at verifying reliable reception at the receiver, but you can't have
reliable communication without talking both directions.  That means there
are ACKs and timeouts.  You have to go thru each possible case of a message
getting garbled, and messages not getting garbled but the ACKs getting lost,
etc.

More worms.


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

2005\05\25@222245 by Byron A Jeff

face picon face
>On Wed, May 25, 2005 at 03:33:20PM -0500, PicDude wrote:
> On Wednesday 25 May 2005 03:09 pm, Byron A Jeff scribbled:
>> There's no real point in have double transmissions if nodes need to talk
>> directly to one another. Primary/secondary based systems work best when
>>all of the secondaries need to interact with the primary.
>
>I came up with this since in a significant majority of cases, the master
>will need to be informed of the event, and the slave will want to
>communicate the message to more than one other slave.  Having each slave
>send out a message to more than one other slave seems like a mess as they
>would be communicating without the master letting them do so.

The fact that communcation is required to nodes other than the master node
suggests not using this modem.

>
> I also thought of a scheme where each bit on a couple bytes would represent
> a unique node.  In one message, multiple specific nodes could be addressed.
> But this turn out to be another can of worms for the acknowledgements.  All
> sorts of odd thoughts of having each station acknowledge after waiting a
> specific differing time followed, which resulted in my head spontaneous
> combusting. :-)

As it should. It would be easier having a ACK line out of band. Can you
afford another wire, some pullup power, and another I/O line?

>> > - I'm planning to implement an acknowledgement to the slave that message
>> > was received.  > > That will facilitate flow control. But how will you
>know when the addressed > node is finished sending?
>
> FIxed length messages.  So far 3 bytes per message, which includes the
> address.

Short messages. But ACKS will really do some damage in terms of time and
bandwidth.

{Quote hidden}

That's fine.

>> It feels like you picked the primary/secondary model out of thin air.
>> Token passing is more flexible and also eliminates contention.

> There is another term to descibe where it came from, but I'll refrain from
> stating it here :-)  Okay, not really -- the need to have a message mostly
> go to multiple stations made this scheme somewhat "natural" (at least for
> me).  I'll do some thinking about the token method.

It seems to me the store and forward is going to make the problem worse,
not better as you'll have to have double send and receipts for each
message for each station.

At least with the token setup you can broadcast once, then poll for
receipts.

BAJ

2005\05\26@005119 by Dave Lag

picon face
All this stuff just seems to be re-inventing the "telcom" protocols used
on ancient hubbed modem multipoint circuits,
poll-answer-ack-nak-stationid etc....
D
....
Olin Lathrop wrote:
{Quote hidden}

lotsa snippage........

2005\05\26@034853 by Alan B. Pearce

face picon face
>The messaging will be very specific to each station, so new nodes
>will require a firmware change at the master, since it will need
>to be setup based on the type of node.

I once did technical support for a small business computer system called
Qantel, which had a polled RS232 network (they ran an open collector driver
with RS232 levels). It had a protocol that went something like this.

Poll by master <ETX><address><ENQ>

answer by slave if no message <EOT>
answer by slave if message available <status><checksum><ETX> where <ETX>,
<EOT>, <ACK>, <NAK> are the corresponding ASCII characters.

if slave replied with a message available then the master would send a poll
requesting the message. The slave would send the message, and the master
would then reply <ACK> or <NAK> depending on the state of the message as
determined by a checksum calculation. A similar loop was used to send a
message from the master to the slave. The status byte was used to determine
if the slave was busy, had a message to send, or there were also a couple of
flag bits that you could set directly from the keyboard. Worked real well.

2005\05\26@103103 by Bill & Pookie

picon face

Programmed a network using RS485 Master/Slaves.  An Apple was the master and
the slaves were several single board computers logging data.  The master
would poll each slave and get current status and if it had a completed log
message to send.  There was no acknowledgment in the protocol.

If the slave had a log message ready, the master would ask the slave for
that particular log message (each log message had a sequential number id
(modulo something) that it had sent in the polled status message.  After the
slave sent the logged message, it would mark that message as sent, but not
destroy the message until it needed that logging space again.

The master would remember what log message it had asked for and keep asking
for that same message id until it got a good copy of it.  Again, no
acknowledgement of messages took place.

The master or any/all slaves could be powered down at any time.  The data
received as the master did it "status" poll of each slave was for
informational use and not critical.  The logs were important but for
statistical use only and not for safety reasons.

All messages were in ASCII characters with numbers being decimal.  The
fields were separated by a "tab" character delineator.  This served two
purposes.  It was easy to see what each message contained and could be
directly imported to a spread sheet.

Each message contained a "to", "from" and "message type" field.  Followed by
the data fields for that type of message, ending with a very simple check
sum of all digits.  All fields separated by a tab character.  There may have
been a special field(one character)used as "start of message", and a
different one before or after the checksum field used as "end of message".
There was also a special id for broadcasting to all slaves.

The slave would look for a "start of message" character/field and read the
"to" field.  I it was not that slaves id, then it would go back  looking for
the "start of message" character.  If it was for that slave then it would
read the whole message and comply if the checksum was ok.

Each slave had a seven segment led display a couple led's and a keypad.
With this, the activity on the line could provide some information for
diagnostics.

Might be a good ideal to use a led to blink when a slave received something
on the line and double blink when it responded.

Bill

////////////

2005\05\27@101315 by Howard Winter

face
flavicon
picon face
On Wed, 25 May 2005 18:57:26 -0400, Olin Lathrop wrote:

> Byron A Jeff wrote:
>...<
> > Token passing is more flexible and also eliminates contention.
>
> True, but it comes with its own set of problems.  If a node goes down and
> doesn't pass on the token things get messy, especially in a pure peer to
> peer environment.

True, but this was solved nearly thirty years ago by Datapoint in developing and implementing ARC (later
"ARCnet"), when Ethernet and Cambridge Ring (the computer-, not spy- network :-) were still research projects.  
It is true peer-to-peer, with physical multiple-star layout but logical sequential token-passing.  It has a
"who's there" process which means that each node learns who is either side of it, and it's triggered either by
a new node appearing or an existing one disappearing.  There is no noticeable slowing down when this happens.  
We were using it in a live environment in the late seventies.  

I remember the day when someone mentioned that they couldn't "see" any of the equipment on the far side of the
site (there was a canal running through the middle of the factory, with a bridge that carried the cables and
pedestrians across) and it turned out someone had cut through a great wad of cables, having been told they
were disused.  One of them, ours, wasn't!  The system carried on happily in two halves, and since the
cross-canal requirement was only used a few times a day, nobody noticed for some time!  As soon as the culprit
cable had been identified and re-made, it all reconfigured itself back as it had been.  It's a shame that
Datapoint kept the technology proprietary for too long, giving the others a chance to get established and
effectively shut it out.

>From another message on this topic:

> it is something I classify as "advanced"

When Olin says this, "Caveat Developer" !  :-)

Cheers,


Howard Winter
St.Albans, England


2005\05\27@103212 by olin_piclist

face picon face
Howard Winter wrote:
> True, but this was solved nearly thirty years ago by Datapoint in
> developing and implementing ARC (later "ARCnet"), when Ethernet and
> Cambridge Ring (the computer-, not spy- network :-) were still research
> projects. It is true peer-to-peer, with physical multiple-star layout
> but logical sequential token-passing.  It has a "who's there" process
> which means that each node learns who is either side of it, and it's
> triggered either by a new node appearing or an existing one
> disappearing.  There is no noticeable slowing down when this happens.
> We were using it in a live environment in the late seventies.

I agree this is all possible.  I was just trying to get Neil to realize that
while RS-485 can be made to do what he wants, there are a lot of sticky
details that are going to make a robust implementation tricky, or at least a
lot more work than he seems to think.

Your approach is a good example of that.  How long did it take how many
people to develop this?  Certainly it could all be done in a PIC using
RS-485, but I would hardly classify that as the "simple" Neil thought it
would be.

> I remember the day when someone mentioned that they couldn't "see" any
> of the equipment on the far side of the site (there was a canal running
> through the middle of the factory, with a bridge that carried the
> cables and pedestrians across) and it turned out someone had cut
> through a great wad of cables, having been told they were disused.  One
> of them, ours, wasn't!  The system carried on happily in two halves,
> and since the cross-canal requirement was only used a few times a day,
> nobody noticed for some time!  As soon as the culprit cable had been
> identified and re-made, it all reconfigured itself back as it had been.

Very interesting.


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

2005\05\27@120451 by Michael Rathbun

flavicon
face
On Fri, 27 May 2005 10:32:51 -0400, spam_OUTolin_piclistTakeThisOuTspamembedinc.com (Olin
Lathrop) wrote:

>Your approach is a good example of that.  How long did it take how many
>people to develop this?  

When I was at Datapoint, I recall at least three people being involved, for
perhaps a year.  However, it was a "secret" project at the time, so it
could have been more for longer.   Unfortunately, as mentioned above, it
stayed secret nearly forever.

>                         Certainly it could all be done in a PIC using
>RS-485, but I would hardly classify that as the "simple" Neil thought it
>would be.

The host was the equivalent of an 8008 with 16K.  The controller was only
slightly smarter.

2005\05\30@142219 by PicDude

flavicon
face
On Friday 27 May 2005 09:32 am, Olin Lathrop scribbled:
> I agree this is all possible.  I was just trying to get Neil to realize
> that while RS-485 can be made to do what he wants, there are a lot of
> sticky details that are going to make a robust implementation tricky, or at
> least a lot more work than he seems to think.

Totally understand and expect that.  My only communications code to date was a
terminal program with xmodem/ymodem I did on Win3.1 eons ago.  But I have
some idea of RS232 communications and acks, naks, etc.

Any communications will require some head-scratching, but I still feel this is
relatively simple, especially considering my non-critical messaging.  When a
station sends out a signal, the master will distribute it to a number of
other stations requiring it, including the original sender.  A light on that
original sender will go on to indicate the activity/state, so that in itself
will count as an acknowledgement.  If an error occurs, the sender (person)
will just re-send the signal.

It is difficult to see all of the potential failure points from this
bird's-eye view currently, so I'm waiting on some of the RS485 transcievers
to come in so I can mock-up a few stations and really see what I'm in for.

Cheers,
-Neil.


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