RS485, multidrop protocol
Ian McCrum MI5AFL
anywhere for download?
I have homebrewed a couple of these in the past but is there a
standard way of doing this?
I am interested in using the serial port of a linux machine, with
RS485 line drivers/receivers and probably RTS control to effectively
network a number of machines together.
Two possible applications spring to mind, my own custom (udp) system
or trying to get TCP/IP sort of working, NFS or TFTP booting for
example, I'd accept atrocious performance just for the convenience of
it all. typically only a pair would be busy at once...
The SLIP and PPP protocols are not multidrop of course.
It may be possible to modify a TCP driver to provide a ALOHA type
connection ( there being no "collision dectect" on a simple system)
It may be possible to encode data so that 8 bits gets transmitted as
16 (20 actually if you include stop/start). E.g send each bit as a
dibit, 01 or 10. Then arrange to pad the line and use a token passing
mechanism so that each machine only transmits when the line is quiet.
I could even add hardware to provide a "sort of " collision detect but
it all seems a bit complicated.
There may be implementations already done... was localtalk rs485? (
old apple) or maybe versions of modbus, profibus or somesuch. I don't
know anything about modbus, profibus or localtalk, maybe someone here
can comment...
Tia
Ian McCrum
Paul Keinanen
<IJ.M...@ulster.ac.uk> wrote:
>I wonder if there is documentation on standard RS485 protocols
>anywhere for download?
There is no such thing as standard RS-485 protocols. The RS-485 is
simply the electrical specification as would RS-232 or 20 mA current
loop.
>I have homebrewed a couple of these in the past but is there a
>standard way of doing this?
There are hundreds ways of doing it. Pick your own standard :-).
>I am interested in using the serial port of a linux machine, with
>RS485 line drivers/receivers and probably RTS control to effectively
>network a number of machines together.
If you intend to use it with any decent transmission speeds, do not
even dream of using the standard 16550 etc. UART, since it does not
generate an interrupt, when the last stop bit has actually been
transmitted from the shift register. The 16550 family only generates
an interrupt, when the last character has been transferred into the
shift register, but this is too early to turn off the transmitter. Use
a UART that automatically controls the Rx/Tx through the RTS etc.
signal or at least a UART that will generate an interrupt of the
actual transmission of last stop bit from the shift register.
Paul
Grant Edwards
>>RS485 line drivers/receivers and probably RTS control to effectively
>>network a number of machines together.
>
> If you intend to use it with any decent transmission speeds, do not
> even dream of using the standard 16550 etc. UART, since it does not
> generate an interrupt, when the last stop bit has actually been
> transmitted from the shift register. The 16550 family only generates
> an interrupt, when the last character has been transferred into the
> shift register, but this is too early to turn off the transmitter. Use
> a UART that automatically controls the Rx/Tx through the RTS etc.
You definitely want one that does automatic half-duplex control
of RTS. The 16850 family will control RTS automatically. The
register interface is a nightmare since they've tried to keep
it backwards-compatible with the 16550.
Several years ago, I hacked up the Linux 16550 driver to do RTS
control. It worked with some chipsets but not with others.
Apparently, motherboard chipstes aren't very consistent about
when they set the shift-register-empty bit. Some of them seem
to do it before the final stop bit has been sent.
> signal or at least a UART that will generate an interrupt of the
> actual transmission of last stop bit from the shift register.
^^^^^^^^^^^^^
That's the key. I've had problems with UARTs that generated
the shift-register empty status at the _start_ of the final
stop bit.
--
Grant Edwards grante Yow! Yow! I want my nose
at in lights!
visi.com
Tom Woodrow
myren, lord
>> anywhere for download?
> There is no such thing as standard RS-485 protocols. The RS-485 is
> simply the electrical specification as would RS-232 or 20 mA current
> loop.
There is no standard RS-485 protocol but i dare say there are some
standard protocols built upon RS-485.
ROBIN - ROBot Independent Network - springs to mind
http://www.bdmicro.com/code/robin/
Wish it was around when I started my rs485 project. ;)
Myren
Paul Keinanen
>Several years ago, I hacked up the Linux 16550 driver to do RTS
>control. It worked with some chipsets but not with others.
>Apparently, motherboard chipstes aren't very consistent about
>when they set the shift-register-empty bit. Some of them seem
>to do it before the final stop bit has been sent.
Turning off the transmitter _during_ the last stop bit is usually not
a problem in half duplex protocols, since the driver has actively
driven to the "1" state at the beginning of the stop bit. Turning off
the transmitter during the stop bit has no effect on the line state,
since now the "fail safe" termination will start to pull the line to
the idle "1" state a bit earlier.
This becomes a problem only if you start the next transmission in a
full duplex protocol (or broadcast) before the stop bit period has
elapsed, does the UART even allow this?
Even if the driver is slave-rate limited and you turn off the
transmitter exactly at the start of the stop bit, the "fail safe"
termination will passively pull the line to the "1", hopefully before
the middle of the stop bit at which point the remote receiver is
sampling it.
If you have had problems with some chip sets when polling the
shift-register-empty, it actually has been set long before the start
of the stop bit, e.g. at the end of the actual data byte, but before
the parity and stop bit(s), in which case a "0" parity bit could be
lost.
Paul
-
- Half duplex
- Has discovery
- CheckSum (HDLC)
- Is well documented
- Can be small
- Multiple baudrates
- Need some minor modifications
- Easy design platform (if you first start with the ir implementation).
- etc.
I'm also using it for a RS485 network and is works great. The slave (sec) is
about 4K of rom and about 220 bytes of ram (8051 as target) with the IAS.
You need some small modifications such as the discovery mechanism (after a
sec. is found the master tells the sec. that it must stop respond to
discovery frames for a while, if it's completely quite during the discovery,
all the slaves are found ).
The prim. also need some small modifications so that it can handle multiple
lap conections etc.
Gerard / StackTools
"Ian McCrum MI5AFL" <IJ.M...@ulster.ac.uk> wrote in message
news:67gfp0dr2na07h75i...@4ax.com...
Ian McCrum MI5AFL
It is standard protocols that use rS485 that I am interested
I am not too worried about exactly when to turn the line around, or at
least enable transmitters, I can do this and slight inefficiencies
don't matter, It WILL depend on the actual hardware, it is often
enough to listen to yourself transmitting, provided you clear all
double buffers etc.,
Want I really want is a LLC and MAC based on RS485 that will allow
easy use of standard TCP/IP protocols/applications. I can put up with
atrocious performance initially provided I have the convenience the
standard applications. Perfromance can be improved later...
>Ian McCrum MI5AFL wrote:
>> I wonder if there is documentation on standard RS485 protocols
>> anywhere for download?
>> or trying to get TCP/IP sort of working, NFS or TFTP booting for
>> example, I'd accept atrocious performance just for the convenience of
>> it all. typically only a pair would be busy at once...
>>
>> There may be implementations already done... was localtalk rs485? (
>> old apple) or maybe versions of modbus, profibus or somesuch. I don't
>> know anything about modbus, profibus or localtalk, maybe someone here
>> can comment...
Thanks again,
Ian McCrum
Jim Granville
> Consider IrDA. It is:
>
> - Half duplex
> - Has discovery
> - CheckSum (HDLC)
> - Is well documented
> - Can be small
> - Multiple baudrates
> - Need some minor modifications
> - Easy design platform (if you first start with the ir implementation).
> - etc.
>
> I'm also using it for a RS485 network and is works great. The slave (sec) is
> about 4K of rom and about 220 bytes of ram (8051 as target) with the IAS.
> You need some small modifications such as the discovery mechanism (after a
> sec. is found the master tells the sec. that it must stop respond to
> discovery frames for a while, if it's completely quite during the discovery,
> all the slaves are found ).
>
> The prim. also need some small modifications so that it can handle multiple
> lap conections etc.
IrDA has a new 16MBaud standard, now ramping, and at that speed the
hardware layers will become real candidates for isolated control busses.
We just need to wait for the small uC to catch up, and include the
faster IrDA codecs :)
-jg
T Marchini
>>Ian McCrum MI5AFL wrote:
>
>>>or trying to get TCP/IP sort of working, NFS or TFTP booting for
>>>example, I'd accept atrocious performance just for the convenience of
>>>it all. typically only a pair would be busy at once...
>
>
> Ian McCrum
Here is a fun one,
Hack PPP and add an address field to it, along with a token passing
scheme and a master.
Look at the older parallel port protocol for linux PLIP.
There could be some interesting reading along with methodology for
stuffing your serial protocol to work with the built in TCP/IP of linux.
T.
Not Really Me
> I wonder if there is documentation on standard RS485 protocols
> anywhere for download?
>
> I have homebrewed a couple of these in the past but is there a
> standard way of doing this?
> Tia
> Ian McCrum
Ian, as you can see from the responses there doesn't seem to be a standard.
We also have homebrewed a couple. I have placed a zip file in a download
area of our web site of a simple protocol we have used a few times.
http://www.exotech.com/downloads.htm.
I realize this is asking all the NG's old hens to fuss about how it could be
better, faster, simpler, etc. But the cost is the same, and I can't
remember seeing there offerings. Although I am willing to host any others
on the site.
Scott
Ian McCrum MI5AFL
>> I wonder if there is documentation on standard RS485 protocols
>> anywhere for download?
>>
>> I have homebrewed a couple of these in the past but is there a
>> standard way of doing this?
><SNIP>
>> Tia
>> Ian McCrum
>On Mon, 15 Nov 2004 11:38:05 -0700, "Not Really Me" <sc...@exoXYZtech.com> wrote:
>Ian, as you can see from the responses there doesn't seem to be a standard.
>We also have homebrewed a couple. I have placed a zip file in a download
>area of our web site of a simple protocol we have used a few times.
>http://www.exotech.com/downloads.htm.
>
>I realize this is asking all the NG's old hens to fuss about how it could be
>better, faster, simpler, etc. But the cost is the same, and I can't
>remember seeing there offerings. Although I am willing to host any others
>on the site.
>
>Scott
==============================
Thanks Scott, I have downloaded the .zip I'll give it a good looking
over.
It has been 3 or 4 years since I did my last RS485 network, and it has
always been one computer talking to a number of much smaller
microprocessors. I always used a four wire system. I'll see if I can
dig up the code.
I am running a simple RS485 lab past my students at the University and
it rekindled my interest,
Http://www.eej.ulst.ac.uk/~ian/modules/COM347J1/COM347J1_LAB5.pdf
A mate called Pat Sweeney wrote it, the students are only computer
science students and have no/little hardware expertise so they just
poke a few registers and see a few characters go flying by (at 1
baud!)
plus I am getting an ARM board to play with soon 8-)
In reply to other posters, is IrDA multi-drop?
Actually hacking PLIP or SLIP is fine for point to point, the real
physical media is not of too much importance, but getting multiple
machines to work is harder. PPP does not use addresses!
As a starting point, Jeremy Benthams book on putting TCP/IP on PICs
uses a ethernet card driver (for a 3com 3c509) of only 250 lines of C.
Might be worth a play. If the interface at a driver level is so
simple, e.g in linux then it would be easy to add a simple driver
module that pretended to be an ethernet card.
The driver code could play pass the parcel to get its message around
the network. Even if it meant defeating ARP and using hardwired ARP
tables, or frigging with various timeout timers it might be on...
8-)))
Ian
Byron A Jeff
Ian McCrum MI5AFL <IJ.M...@ulster.ac.uk> wrote:
-I wonder if there is documentation on standard RS485 protocols
-anywhere for download?
RS485 is an electrical standard. But that's not what you're talking
about. There is no multidrop data link standard.
-
-I have homebrewed a couple of these in the past but is there a
-standard way of doing this?
Nope.
-I am interested in using the serial port of a linux machine, with
-RS485 line drivers/receivers and probably RTS control to effectively
-network a number of machines together.
OK.
-
-Two possible applications spring to mind, my own custom (udp) system
-or trying to get TCP/IP sort of working, NFS or TFTP booting for
-example, I'd accept atrocious performance just for the convenience of
-it all. typically only a pair would be busy at once...
-
-The SLIP and PPP protocols are not multidrop of course.
PPP isn't. But SLIP is nothing other than a trivially modified IP
packet, which of course is routable. There's no technical reason why
you couldn't route addressible packets onto a SLIP link. Run UDP on
top of it and voila! a simple and standard multidrop link.
However you'd still have to implement a speak when spoken to only
duplex protocol on top of this to eliminate collisions.
-
-It may be possible to modify a TCP driver to provide a ALOHA type
-connection ( there being no "collision dectect" on a simple system)
Why not do it in the application layer and leave TCP out of it. Just
send datagrams over the SLIP link and have everyone involved strictly
follow a speak before spoken to protocol?
-
-It may be possible to encode data so that 8 bits gets transmitted as
-16 (20 actually if you include stop/start). E.g send each bit as a
-dibit, 01 or 10. Then arrange to pad the line and use a token passing
-mechanism so that each machine only transmits when the line is quiet.
-I could even add hardware to provide a "sort of " collision detect but
-it all seems a bit complicated.
Very complicated. If you're going there when implement a virtual token
system where you can only speak when you have the token.
Collisions are of course the problem. You can't afford to have any.
BAJ
Not Really Me
Should work fine for 4-wire also. We use it primarily on 2-wire in an
industrial control app with 2 to 20 or more devices per network.
Scott
Ian McCrum MI5AFL
>>In article <67gfp0dr2na07h75i...@4ax.com>,
>>Ian McCrum MI5AFL <IJ.M...@ulster.ac.uk> wrote:
>>-I wonder if there is documentation on standard RS485 protocols
>>-anywhere for download?
>>...
>>-The SLIP and PPP protocols are not multidrop of course.
>
>PPP isn't. But SLIP is nothing other than a trivially modified IP
>packet, which of course is routable. There's no technical reason why
>you couldn't route addressible packets onto a SLIP link. Run UDP on
>top of it and voila! a simple and standard multidrop link.
>
Ok, I'll go look at slip, I have only worked with PPP before ( Seiko
firmware chip)
>However you'd still have to implement a speak when spoken to only
>duplex protocol on top of this to eliminate collisions.
In practice collisions would be unlikely, a datalogging application
will look after the polling, that just leaves other miscellaneous
things I'd like to run, tftp and NFS. There would probably be a
"master" computer anyway
>Why not do it in the application layer and leave TCP out of it. Just
>send datagrams over the SLIP link and have everyone involved strictly
>follow a speak before spoken to protocol?
I'd probably want to run TCP applications over the link, e.g SSH,
TELNET or VNC so using a standard TCP/IP stack makes the applications
easier to get. And the off timeout wouldn't matter, or could be got
around.
Once you have a network, you'd use it for lots of things...
Regards and Thanks again
Ian
Paul Keinanen
<IJ.M...@ulster.ac.uk> wrote:
>It may be possible to modify a TCP driver to provide a ALOHA type
>connection ( there being no "collision dectect" on a simple system)
Running ALOHA on a bus which can be actively driven both high and low
at different units, is not a good idea. When one transmitter is
driving "1" and the other "0", a quite large short circuit current
will flow between Vcc and ground. While the short circuit current
limit will protect the devices against permanent physical damage, the
transceivers can run quite hot or produce other nasty side effects.
A better solution would be to use some kind of dominant/rescessive
system as used in CAN (Controller Area Network). Prior to the
availability of dedicated CAN transceivers, ordinary RS-485 chips were
used in CAN.
Connect the transmitter data input to a permanent "0" level and
connect the serial Tx signal to the Tx-driver enable signal in such a
way that the "0" serial data will activate the driver and send out the
fixed "0" level (dominant state). When the "1" is to be sent, the
RS-485 driver is disabled and the fail safe termination will pull the
line to the "1" (recessive) state.
If there is a collision, the dominant "0" driver will override the
recessive "1" termination. If you keep the receiver enabled all the
time, you can monitor, if some other station caused a collision which
overrided your recessive state.
Paul
Paul Burke
>>Ian McCrum MI5AFL wrote:
>>
>>>I wonder if there is documentation on standard RS485 protocols
>>>anywhere for download?
>>>
I've come across this thread rather late so I don't know what's been
said, but has anyone mentioned Bitbus?
<http://www.alfirin.net/flamer/bitbus/> for some stuff.
Paul Burke
Ted Wood
try:
Spehro Pefhany
<IJ.M...@ulster.ac.uk> wrote:
>There may be implementations already done... was localtalk rs485? (
>old apple) or maybe versions of modbus, profibus or somesuch. I don't
>know anything about modbus, profibus or localtalk, maybe someone here
>can comment...
Modbus is simple and may be appropriate. It comes in two flavors- RTU
and ASCII. Google for more.
Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
sp...@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Meindert Sprang
news:cbqjp05rjfpvfe2hj...@4ax.com...
> On Sun, 14 Nov 2004 20:46:59 +0000, the renowned Ian McCrum MI5AFL
> <IJ.M...@ulster.ac.uk> wrote:
>
> >There may be implementations already done... was localtalk rs485? (
> >old apple) or maybe versions of modbus, profibus or somesuch. I don't
> >know anything about modbus, profibus or localtalk, maybe someone here
> >can comment...
>
> Modbus is simple and may be appropriate. It comes in two flavors- RTU
> and ASCII. Google for more.
Modbus-RTU is horrible, because it relies on inter-character timing for
frame delimiting.
It is far more easy to use a modified SLIP, where you use 0xFE as start,
0xFD as end and 0xFC as escape characters. Actually, the choice of these
control characters is arbitrary.
Meindert
Spehro Pefhany
<mhsp...@NOcustomSPAMware.nl> wrote:
>"Spehro Pefhany" <spef...@interlogDOTyou.knowwhat> wrote in message
>news:cbqjp05rjfpvfe2hj...@4ax.com...
>> On Sun, 14 Nov 2004 20:46:59 +0000, the renowned Ian McCrum MI5AFL
>> <IJ.M...@ulster.ac.uk> wrote:
>>
>> >There may be implementations already done... was localtalk rs485? (
>> >old apple) or maybe versions of modbus, profibus or somesuch. I don't
>> >know anything about modbus, profibus or localtalk, maybe someone here
>> >can comment...
>>
>> Modbus is simple and may be appropriate. It comes in two flavors- RTU
>> and ASCII. Google for more.
>
>Modbus-RTU is horrible, because it relies on inter-character timing for
>frame delimiting.
That "feature" just requires low-level programming and may eat some
system resources (a timer) if there is no buffering on the serial
port. Other than that, it isn't difficult if you plan for it.
Anthony Marchini
your serial control protocol with internal TCP/IP transport.
Using PPP(type) packeting allows for an easy way to create begin and end
packet segments for easy packet synchronization.
PPP is point to point, but if you ADD a leading address byte to the
packet structure then you are all set.
You obviously need to add a bunch of code here to make this work. I am
just giving suggestions on where to start looking for pieces that can be
used to transport data in the way you suggest.
T
Tauno Voipio
The PPP framing is actually a special case of HDLC (ISO 3303)
framing. There is an address byte: the first byte after the
starting flag which is 0xff in PPP. If single byte addressing
is enough for your network, just put the address in there.
It may be worth while to think if the PPP link control
protocols (IPCP & co) are really needed in a special
network like this. The control protocol is needed if the
IP addresses and other network parameters have to get
distributed when the link is established.
The main problem in a RS-485 network is the distributed
control of the transmit enables to keep bus contention
out. If the network is a logical star controlled by a
single master station, the timing can be solely run
by the master.
--
Tauno Voipio (OH2UG)
tauno voipio (at) iki fi
Meindert Sprang
> That "feature" just requires low-level programming and may eat some
> system resources (a timer) if there is no buffering on the serial
> port. Other than that, it isn't difficult if you plan for it.
Try it on a UART with a FIFO.....
Meindert
Tauno Voipio
> On Tue, 16 Nov 2004 12:48:20 +0100, the renowned "Meindert Sprang"
> <mhsp...@NOcustomSPAMware.nl> wrote:
>
>
>>"Spehro Pefhany" <spef...@interlogDOTyou.knowwhat> wrote in message
>>news:cbqjp05rjfpvfe2hj...@4ax.com...
>>
>>>On Sun, 14 Nov 2004 20:46:59 +0000, the renowned Ian McCrum MI5AFL
>>><IJ.M...@ulster.ac.uk> wrote:
>>>
>>>
>>>>There may be implementations already done... was localtalk rs485? (
>>>>old apple) or maybe versions of modbus, profibus or somesuch. I don't
>>>>know anything about modbus, profibus or localtalk, maybe someone here
>>>>can comment...
>>>
>>>Modbus is simple and may be appropriate. It comes in two flavors- RTU
>>>and ASCII. Google for more.
>>
>>Modbus-RTU is horrible, because it relies on inter-character timing for
>>frame delimiting.
>
>
> That "feature" just requires low-level programming and may eat some
> system resources (a timer) if there is no buffering on the serial
> port. Other than that, it isn't difficult if you plan for it.
The main problem is that hardware receive buffering cannot
be used to prevent loss of frame timing gaps. You cannot
measure the character timing from the FIFO output.
Please forget Modbus/RTU - it seems to be designed for
maximum difficulty to transport. The receive interrupt
handler does not know the length of a frame unless is
parses all of the commands and sub-options of the frame,
and the parsing logic is different for a client (master)
and server (slave).
Modbus/TCP seems to be as broken, but in another way.
Been there - done that (gotten bitten by a tunneling
Modbus bridge).
--
Tauno Voipio
Paul E. Bennett
> The PPP framing is actually a special case of HDLC (ISO 3303)
Is that the correct ISO standard? I looked up ISO 3303 and found that it
relates to "Rubber or plastic coated fabrics - determination of bursting
strength". Nothing at all about HDLC protocols. Perhaps you really meant
ISO/IEC 3309:193 "Information Technology - Telecommunications and
information exchange between systems, High-level data link control (HDLC)
procedures - Frame structures".
--
********************************************************************
Paul E. Bennett ....................<email://peb@a...>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Grant Edwards
>>Modbus-RTU is horrible, because it relies on inter-character timing for
>>frame delimiting.
>
> That "feature" just requires low-level programming and may eat some
> system resources (a timer) if there is no buffering on the serial
> port. Other than that, it isn't difficult if you plan for it.
"some" resources? It eats tons of resources. It makes it
impossible to use the receive FIFO in a UART and thus requires
an interrupt for every single byte. That makes it almost
impossible to use at high baud rates.
--
Grant Edwards grante Yow! BELA LUGOSI is my
at co-pilot...
visi.com
Tauno Voipio
> Tauno Voipio wrote:
>
>
>>The PPP framing is actually a special case of HDLC (ISO 3303)
>
>
> Is that the correct ISO standard? I looked up ISO 3303 and found that it
> relates to "Rubber or plastic coated fabrics - determination of bursting
> strength". Nothing at all about HDLC protocols. Perhaps you really meant
> ISO/IEC 3309:193 "Information Technology - Telecommunications and
> information exchange between systems, High-level data link control (HDLC)
> procedures - Frame structures".
>
Yes - sorry for the slip. The text was at hand - and I
copied wrong (blush!).
--
Tauno Voipio
Paul E. Bennett
It's OK, you are forgiven. I am sure many others would have identified the
correct standard easily enough by googling for it. Generally you are below
the 3% error rate for keyboard entry so no need to blush too redly.
Paul Keinanen
<spef...@interlogDOTyou.knowwhat> wrote:
>Modbus is simple and may be appropriate. It comes in two flavors- RTU
>and ASCII. Google for more.
Modbus master and Modbus point to point slave is trivial to implement,
since you can rely on the message contents. However, implementing a
Modbus multidrop slave is tricky, since you must adhere to the strict
timing.
The simplest environment to implement nearly perfect timing would be
to use the QUICC co-processor found on the MC68360/MPC860/MPC2860
etc., but even in this case, the Tx message preamble would have to be
set to 2 character times (instead of nominal 1.5 character times), the
Tx trailer to 1 character time (nominal 1.5 character times) and the
Rx end of frame interrupt at 3 character times (nominal 3.5 character
times).
Running Modbus multidrop slave at 115k2 or above with a general
purpose hardware, you really need a timing accuracy and interrupt
latency of 50 us or less, which the standard Linux kernel is
definitely not going to offer.
Paul
Ian McCrum MI5AFL
links.
It looks like there is no clear cut winner in getting, say half a
dozen machines linked using RS485, a simple master-slave polling
scheme, where machines queue up outgoing requests and only speak when
spoken to would be simplest. The other candidates seem onerous.
The real trick will be to provide a physical layer that can link to a
standard TCP protocol stack.
When I get my linux board I'll start dismantling some of the ethernet
drivers, maybe I can "fool" the TCP/IP stack to think it is connected
to a perfect (unbusy) network.
I'll revisit slip and ppp then.
Thanks again
Ian McCrum MI5AFL.
( actually I just realised AX25 might be a good candidate as well...)
University of Ulster
Not Really Me
> Wow, a long thread, Thanks for the inputs, I am following up on the
> links.
>
> It looks like there is no clear cut winner in getting, say half a
> dozen machines linked using RS485, a simple master-slave polling
> scheme, where machines queue up outgoing requests and only speak when
> spoken to would be simplest. The other candidates seem onerous.
>
> Ian McCrum MI5AFL.
> ( actually I just realised AX25 might be a good candidate as well...)
> University of Ulster
www.micrium.com offers an inexpensive ModBus package.
Scott
Gunther Mannigel
> Ian McCrum MI5AFL <IJ.M...@ulster.ac.uk> wrote in message news:<67gfp0dr2na07h75i...@4ax.com>...
>
> try:
cheers
Gunther