I know that some one ask this 2 weeks ago, but I lost this info. I would
like to know if there is a protocol for multi processor comunications using
serial port.
I've seen it using 9-bit communications, and using the ninth bit to
determine if the main controler is sending an address or data. It is
possible to do some thing similar to this using 8-bit communication, but not
using the 8-th bit as an address flag? (I would like to have 8 bits address
and 8 bits data)
I'm searching to for such a protocol too. Ofcourse it's not very difficult
to make one my own, but i think it's far better to use a well known
standard. But I haven't found it yet. I'm still looking in the 'home
automation' world, were there are standards as X10 and CE-bus. But they tell
you very little about the protocol itself. The 9-bit protocol i've seen too.
It sounds smart only the thing is that i want to be able to control my slave
devices (mostly ofcourse PIC-devices) with a visual basic program on a PC.
As far a i know 9-bit communications not supported.
What I already have used as a protocol is communcating with byte-packages like:
1: sync. byte (0xAA=master 0x55=slave)
2: slave adress (dip-switchable)
3: commando number (depending on the tasks the slave has to do)
4: lenght of package (inclusive header)
6: Checksum (LSB)
7: Checksum (MSB)
8: data (LSB)
9: data (MSB)
n: data (LSB)
It's pretty straigth forward. It's inportant that al the slave listen in
sync to the master. Then they know wether the package is adressed for them
or for another-slave. If the slave is out-of- sync, it will try to sync on
the first 0x55 it encounters. If this happens halfway a package, the
checksum will prevent the slave of taking. The change the slave will take
action on WRONG data is very little, but NOT zero!
I'm very curious to other protocols. So if you or anyone knows a good widely
used protocol consisting of LITTLE!! packages, I'm one big ear!
Edwin
Edwin Baaij (Electronic Engineer)
*********************************************************************
University of Amsterdam phone: +31-20-5256346
Van der Waals,- ZeemanInstitute fax: +31-20-5255877
Valckenierstraat 65-67 e-mail: spam_OUTbaaijTakeThisOuTphys.uva.nl
1018 XE Amsterdam
*********************************************************************
At 10:20 PM 22/04/95 -0400, you wrote:
>I know that some one ask this 2 weeks ago, but I lost this info. I would
>like to know if there is a protocol for multi processor comunications using
>serial port.
>I've seen it using 9-bit communications, and using the ninth bit to
>determine if the main controler is sending an address or data. It is
>possible to do some thing similar to this using 8-bit communication, but not
>using the 8-th bit as an address flag? (I would like to have 8 bits address
>and 8 bits data)
>
>thanks
>
>Ricardo
>
>
At 08:23 AM 23/04/96 +0200, you wrote:
>Hello Ricardo,
>
>I'm searching to for such a protocol too. Ofcourse it's not very difficult
>to make one my own, but i think it's far better to use a well known
>standard. But I haven't found it yet. I'm still looking in the 'home
>automation' world, were there are standards as X10 and CE-bus. But they tell
>you very little about the protocol itself. The 9-bit protocol i've seen too.
>It sounds smart only the thing is that i want to be able to control my slave
>devices (mostly ofcourse PIC-devices) with a visual basic program on a PC.
>As far a i know 9-bit communications not supported.
>What I already have used as a protocol is communcating with byte-packages like:
I have a similar problem(PC controlling several PICs) and I am using a similar
approach(details at http://www.magna.com.au/~rtasis/comms.htm). One recent
web reference on CAN was quite detailed and looked very promising. But it
is not serial based but works better bit banged. It is good if all you want
is inter-PIC comms and has multi-master capability. But if you want to connect
to a serial port I think there aren't any standard solutions. I am using a
similar packet structure and using a polled approach. This means a desperate
device has to wait till the host gets around to talking to it. I would be
interested to hear a multi-master approach using a serial comms port too.
Regards
Prashant
+----------------+ -------------------------------------------------
| | Prashant Bhandary
| +---+ | Spatial Information Systems Section
| | | | Roads and Traffic Authority
| | | | Rosebery NSW 2018, AUSTRALIA
| | | | Tel: +61-2-662 5299
| | +----+ | Fax: +61-2-662 5348
| | | | Email: prashbKILLspamrta.oz.au
| +--------+ |
| Still a newbie | "2b|!2b" - William Shakespeare
+----------------+ -------------------------------------------------
>Hello Ricardo,
>
>I'm searching to for such a protocol too. Ofcourse it's not very difficult
>to make one my own, but i think it's far better to use a well known
>standard. But I haven't found it yet. I'm still looking in the 'home
>automation' world, were there are standards as X10 and CE-bus. But they tell
>you very little about the protocol itself. The 9-bit protocol i've seen too.
>It sounds smart only the thing is that i want to be able to control my slave
>devices (mostly ofcourse PIC-devices) with a visual basic program on a PC.
>As far a i know 9-bit communications not supported.
>What I already have used as a protocol is communcating with byte-packages like:
>
>1: sync. byte (0xAA=master 0x55=slave)
>2: slave adress (dip-switchable)
>3: commando number (depending on the tasks the slave has to do)
>4: lenght of package (inclusive header)
>6: Checksum (LSB)
>7: Checksum (MSB)
>8: data (LSB)
>9: data (MSB)
>n: data (LSB)
>
>It's pretty straigth forward. It's inportant that al the slave listen in
>sync to the master. Then they know wether the package is adressed for them
>or for another-slave. If the slave is out-of- sync, it will try to sync on
>the first 0x55 it encounters. If this happens halfway a package, the
>checksum will prevent the slave of taking. The change the slave will take
>action on WRONG data is very little, but NOT zero!
>
>I'm very curious to other protocols. So if you or anyone knows a good widely
>used protocol consisting of LITTLE!! packages, I'm one big ear!
>
>Edwin
>
>
>
>
>
>
>
>
>
>
>Edwin Baaij (Electronic Engineer)
>*********************************************************************
>University of Amsterdam phone: +31-20-5256346
>Van der Waals,- ZeemanInstitute fax: +31-20-5255877
>Valckenierstraat 65-67 e-mail: .....baaijKILLspam.....phys.uva.nl
>1018 XE Amsterdam
>*********************************************************************
>
Edwin,
I like the idea uf using a different sync byte for the master/slave.
I use a text protocol where the sync byte is a few '+' (plus sign).
I send three or four at the start of each message. When a unit
(master or slave) sees a plus sign, it resets its receiver and
starts looking for data. If the next character is a plus sign,
then it just resets the receiver again and keeps looking. The first
non plus sign character is received, it starts the receive routine,
with it being the first character. Basically, a sync character
(plus sign in my case) resets the receivers and is otherwise ignored.
I also send some sync characters at the end of a message. This may
be what tells the receiver that message is complete. Not sure.
The sync characters at end of message (also a plus sign) also serves
the purpose of padding the end of the message with some non critical
characters so that if I turn off the transmitter in mid character,
there is no ill effect. With all units using one chanel, the line has
no one on it for long peroids of time so there may be some noise?
The idea uf using two different sync signals stops the slaves from
reading the message from other slaves, and the master from reading
and decoding its own message. (Don't let the sound of your own
wheels drive you crazy!) (from an old song)
I pass informayion as characters (0-9) and seperate the fields with
a tab character. The check sum is the addition of all the fields
modulus 1,000,000. So the check sum is six digits (characters)
max. By using numeric characters with tab seperators, the information
received can be directly inported into a spread sheet.
My use is for getting data from the slaves and telling the slaves to
clear old data. The master sends a command from 1 to 99 to a slave,
and the addressed slave replies to each command with a command
from 101 to 199. So a reply to a command from master of 20 would be
a 120 from the addressed slave.
It has been a long time sence I have looked at this code, I just keeps
working, that I am not sure of some of the details. But I think
that when the master sends a command of 10 to request the next logged
data from the slave, and the master receives a reply with a command
of 110 from the slave, the master then sends a command of 11, telling
the slave to marked that logged record as being sent.
The master sends a request for status to the slaves often. The slaves
reply with their current status and also if there is any logged data
to be sent to the master.
>similar packet structure and using a polled approach. This means a desperate
>device has to wait till the host gets around to talking to it. I would be
>interested to hear a multi-master approach using a serial comms port too.
I am currently trying to get a multi-master system working (for home
control). I am going to use RS-485 (not 422). My packets would be as follows
ASCII Character Description
[ (1 byte) Start Character
A-Z (1 byte) To address (26 possible hosts)
A-Z (1 byte) From address (26 possible hosts)
0-T (2 bytes) Data
0-T (2 bytes) Data
0-T (2 bytes) Checksum
] (1 byte) End character
Data and checksums would be sent in compressed BCD format.
Ie. use 0-9 to represent ones (byte 2)
use 0-9 to represent 0 hundreds and 0-9 tens (byte 1)
use A-J to represent 1 hundreds and 0-9 tens (byte 1)
use K-T to represent 2 hundreds and 0-9 tens (byte 1)
So my data byte can represent anywhere from 0-299 decimal in two bytes.
For multi-master all devices would listen and get all messages. Once the
message was complete they would wait a certain amout of time based on their
address. Ie if they have a low address they would be able to send right
away, but if they have a high address like 'Z' then they would have to wait
a while before they could send. If a new message comes in while they are
waiting the
the waiting period resets.
The problems with this is that all devices must get all the message and wait
the proper time. Since this is hobby stuff I am not to worried about the
chance of collisions (collisions shouldn't happen) since the Rs-485 chips
will shutdown in overload.
Thanks for you reaction. Using only characters as a protocol is also an
option. It's being used for example by Eurotherm controllers. I belief they
make a division : everyting above 0x127 are communication-commands, below is
data.
But I find it a bit of waste of time and bytes to communicate like this. Ok,
serial communication is not the fastest way to communicate, but i want make
an effort to do it as quick as possible.
About synchronising.. I've got also an idea to separate the packages with a
minimum time delay. Let's say 3ms for a 9600 baud link. The slave and master
can detect this delay, and uses this as reset or sync-alert or whatever.
Important for this idea is that the packages have to be send without
interruption, and I have to find out if Windows can do this (probably not!).
I don't think it's nescessary to use a end-sync or mark. If you tell the
device how many bytes there are in the package it can count (I hope ;-) ) on
this.
......
>The master sends a request for status to the slaves often. The slaves
>reply with their current status and also if there is any logged data
>to be sent to the master.
I've got also the idea to put two extra bytes in the package. The slave
device HAS to acknowledge a commands, so can make use of the following
status bytes:
STATUS BYTE 1:
Bit7: reserve
Bit 6/5/4/3 requested polling speed number
Bit 2/1/0 unity
STATUS BYTE 2: (Alarm)
Bit 7: Make a sound; action immediately demanded
Bit 6: Make a sound; action demanded
Bit 5: Give visual alarm (led)
Bit 4: Give visual signal (led)
Bit 3: Attention, command NOT yet executed/data NOT yet avalable
Bit 2: Invalid data/command
Bit 1: reserve
Bit 0: reserve
Edwin.
Edwin Baaij (Electronic Engineer)
*********************************************************************
University of Amsterdam phone: +31-20-5256346
Van der Waals,- ZeemanInstitute fax: +31-20-5255877
Valckenierstraat 65-67 e-mail: baaijspam_OUTphys.uva.nl
1018 XE Amsterdam
*********************************************************************
>Thanks for you reaction. Using only characters as a protocol is also an
>option. It's being used for example by Eurotherm controllers. I belief they
>make a division : everyting above 0x127 are communication-commands, below is
>data.
>But I find it a bit of waste of time and bytes to communicate like this. Ok,
>serial communication is not the fastest way to communicate, but i want make
>an effort to do it as quick as possible.
Thanks for your reaction to my reaction. O o
J
Speed is for the highways, at 2400 baud, I am not burning up the wires.
While using bits and bytes is very effencet and powerful, the ascii text
mode has advantages also. It is posible to manually type in the commands.
If you are watching what comes over the line, you can understand it.
By using the proper characters, the entire record can be put in a file
and imported to a spread sheet. And when someone else wants to hook their
machines to the network, the protocal is easier to implement.
I que op the strings for the messages to each unit, then start by sending
a "time/date" record, then the qued messages. After sending a message
i look for a reply and do not send the next message until I have received
no characters for a while.
>About synchronising.. I've got also an idea to separate the packages with a
>minimum time delay. Let's say 3ms for a 9600 baud link. The slave and master
>can detect this delay, and uses this as reset or sync-alert or whatever.
>Important for this idea is that the packages have to be send without
>interruption, and I have to find out if Windows can do this (probably not!).
>I don't think it's nescessary to use a end-sync or mark. If you tell the
>device how many bytes there are in the package it can count (I hope ;-) ) on
>this.
My sync bytes will reset the receiver's recieve program whenever they are
received. This is in case a receiver is busy receiving what it thinks
is a message and would just add the new message to the junk it was
collecting. The sync characters at end of message may do the same.
Don't think the receivers look for the end of message sync or if they
know the message has ended. Having a message length field is great, but
if the receiver gets thaoses bytes garbled, then he may think the message
is an extremly large one, and spend our lifetime just receiving the
"last message".
>>The master sends a request for status to the slaves often. The slaves
>>reply with their current status and also if there is any logged data
>>to be sent to the master.
>
>I've got also the idea to put two extra bytes in the package. The slave
>device HAS to acknowledge a commands, so can make use of the following
>status bytes:
>
>STATUS BYTE 1:
>Bit7: reserve
>Bit 6/5/4/3 requested polling speed number
>Bit 2/1/0 unity
>
>unity: 0: disabled
> 1: 10000sec
> 2: 1000sec
> 3: 100sec
> 4: 10sec
> 5: 1sec
> 6: 100ms
> 7: 10ms
>
>So the polling speed will be number*unity.
>
>STATUS BYTE 2: (Alarm)
>Bit 7: Make a sound; action immediately demanded
>Bit 6: Make a sound; action demanded
>Bit 5: Give visual alarm (led)
>Bit 4: Give visual signal (led)
>Bit 3: Attention, command NOT yet executed/data NOT yet avalable
>Bit 2: Invalid data/command
>Bit 1: reserve
>Bit 0: reserve
Does the slave request at what intervals he wants to be polled?
I found myself acking an ack. Then acking an ack to an ack. then.....
So I had to decide "at what point does this fooliness end".
One important thing though, it is importand not to loose loged data.
If i slaves current status reply is lost, you can get it next time.
But with logged data, the slave has to delete it (or mark the
location of the data "not in use") to make room for a new log.
So in the current status message from the slave, there is a field
that indicates that a log record is complete and ready to be sent.
The number of the log record is also included. So when the slave
indicates a log is complete, the master ask for it, the slave sendsthe
log and marks it as sent. The master knows the number of the log
he asked for, and if he doesn't get it, the master will ask for it
again. Until it is gotten. Once the slaves sends a log record,
it will never offer it to the master again. But the master can
ask for a specific log (that the slave thinks has been sent) again
and again and .......
The network I have described does not handle vital information. If
something goes wrong, then the one or more logs are lost and the
daily report of the loged data has a glitch. If people's lives or
money were involved, then much more would need to be done to insure
safety.
>Edwin.
---------
Bill Cornutt @spam@billcornKILLspaminfoserv.com
Located in Ione California USA.
A small town in Northern California.
Sitting against the foothills of the Mother Lode.
----------------------------------------------------
Can someone recommend an 8 pin DIP RS422 driver IC that has a high
output current potential. They will be used to transmit NMEA serial
data in marine electronics. They will output to several paralled
optocouplers. The 422 driver will not input. I am looking for a chip
with the maximum output current potential and that can take a shorted
output or output accidently connected to 12VDC. Data rate will only be
4800 baud. I normally use high current TTL drivers, but I need to do
some circuits without the negative grounded.
At a former employer, we had a driver card that was very similar to
RS485/422. It used a DS8831 for the transmitter, which is obsolete
(patience.. I'm getting somewhere) and an LM311 for a reciever. The driver
cards would multi drop at 300 BPS in coal mines at distances to 10 miles.
The remarkable thing was that the signal on the scope (use two probes,
invert second, and add), barely resembled a square wave, and messages still
got through. The secret to survival was that each card ad a DC/DC converter
and optos for TX, RX, and handshake. This allowed the interface circuitry
float with respect to each computer ground, which improved noise problems a
lot. In a modern design, try using some of those higher speed logic optos
and some legitimate 485/422 drivers. The DS8831 was higher current and all,
but not very robust. The last key to survivability is to allow the isolated
ground to act as the shield connection for the cable. Shield typically cuts
distances in half, but that should not be a problem for you (that wasn't an
aircraft carrier, was it?). The shield would add some measure of lightning
and surge protection, and if I am not mistaken, lightning can seek out a
ship in water.
The other issue is speed. We did not terminate the pairs anywhere in the
system (collective hiss from the crowd). But at 300 BPS, the reflections
died down long before the signal was needed in the UART. At 4800 BPS,
though, you are cooking along a bit faster (still nothing like 115K). As
such, you may have to terminate. Pursue a straight bus topology, no
branches. Each reciever has a pair of resistors to pull the idle line to a
known state (one high and one low) so that whenever no transmitter was on
(between every send) the noise on the line did not creep into the reciever
and flood the UART. These bias resistors are typical, though. The National
(probably sold that to Fairchild too) driver and interface databook has some
awfully useful info on the subject.
As a last note, you said 422 in your post. 422 in it's virgin mode is for
driving between two nodes only. Square D uses a four wire 422 with tristate
driers, but that is really just complicated 485. I think you want to look
at 485 for multiple nodes.
Chris Eddy
Pioneer Microsystems, Inc.
>Can someone recommend an 8 pin DIP RS422 driver IC that has a high
>output current potential. They will be used to transmit NMEA serial
>data in marine electronics. They will output to several paralled
>optocouplers. The 422 driver will not input. I am looking for a chip
>with the maximum output current potential and that can take a shorted
>output or output accidently connected to 12VDC. Data rate will only be
>4800 baud. I normally use high current TTL drivers, but I need to do
>some circuits without the negative grounded.
> The other issue is speed. We did not terminate the pairs anywhere in the
> system (collective hiss from the crowd). But at 300 BPS, the reflections
> died down long before the signal was needed in the UART. At 4800 BPS,
> though, you are cooking along a bit faster (still nothing like 115K). As
> such, you may have to terminate. Pursue a straight bus topology, no
> branches. Each reciever has a pair of resistors to pull the idle line to
a
> known state (one high and one low) so that whenever no transmitter was on
> (between every send) the noise on the line did not creep into the reciever
> and flood the UART. These bias resistors are typical, though. The
National
> (probably sold that to Fairchild too) driver and interface databook has
some
> awfully useful info on the subject.
My experience paralells yours. We had a lan running at 9600, and all I could
ever see that terminating it did, was reduce the S/N level. We had
reflections, but as you say, you'd need an awfully long cable before they'd
be significant at that speed.
I have no control over what goes on the receiver end. Most marine electronics
device just have an optocoupler in the receive side. I have never seen anything
of a correct value termination resistor. Hookups vary, but can be 4 or more
devices all home runned to my transmitter, or daisy chained, or a combination.
The norm when using a true 422 driver is to terminate the shield at the
transmitter end only. Some people will terminate it to ground at the receiver
also, some will terminate it to the RX- at the receiver end.
> Brian;
>
> At a former employer, we had a driver card that was very similar to
> RS485/422. It used a DS8831 for the transmitter, which is obsolete
> (patience.. I'm getting somewhere) and an LM311 for a reciever. The driver
> cards would multi drop at 300 BPS in coal mines at distances to 10 miles.
> The remarkable thing was that the signal on the scope (use two probes,
> invert second, and add), barely resembled a square wave, and messages still
> got through. The secret to survival was that each card ad a DC/DC converter
> and optos for TX, RX, and handshake. This allowed the interface circuitry
> float with respect to each computer ground, which improved noise problems a
> lot. In a modern design, try using some of those higher speed logic optos
> and some legitimate 485/422 drivers. The DS8831 was higher current and all,
> but not very robust. The last key to survivability is to allow the isolated
> ground to act as the shield connection for the cable. Shield typically cuts
> distances in half, but that should not be a problem for you (that wasn't an
> aircraft carrier, was it?). The shield would add some measure of lightning
> and surge protection, and if I am not mistaken, lightning can seek out a
> ship in water.
>
> The other issue is speed. We did not terminate the pairs anywhere in the
> system (collective hiss from the crowd). But at 300 BPS, the reflections
> died down long before the signal was needed in the UART. At 4800 BPS,
> though, you are cooking along a bit faster (still nothing like 115K). As
> such, you may have to terminate. Pursue a straight bus topology, no
> branches. Each reciever has a pair of resistors to pull the idle line to a
> known state (one high and one low) so that whenever no transmitter was on
> (between every send) the noise on the line did not creep into the reciever
> and flood the UART. These bias resistors are typical, though. The National
> (probably sold that to Fairchild too) driver and interface databook has some
> awfully useful info on the subject.
>
> As a last note, you said 422 in your post. 422 in it's virgin mode is for
> driving between two nodes only. Square D uses a four wire 422 with tristate
> driers, but that is really just complicated 485. I think you want to look
> at 485 for multiple nodes.
>
> Chris Eddy
> Pioneer Microsystems, Inc.
>
> >Can someone recommend an 8 pin DIP RS422 driver IC that has a high
> >output current potential. They will be used to transmit NMEA serial
> >data in marine electronics. They will output to several paralled
> >optocouplers. The 422 driver will not input. I am looking for a chip
> >with the maximum output current potential and that can take a shorted
> >output or output accidently connected to 12VDC. Data rate will only be
> >4800 baud. I normally use high current TTL drivers, but I need to do
> >some circuits without the negative grounded.
phys.uva.nl
