RE: RS485 communicatio

RE: RS485 communicatio

[Ed Vance]

On Wed, Mar 12, 2003 at 10:15 PM, linuxppp@indiainfo.com wrote:
> Hi all,
> am currently working on PPP over serial interface (RS485) in 
> linux 2.4.2-2. I believe RS485 half duplex system and hence 
> only one can transmit at a time. And for RS485 we basicaly 
> use Master-Slave or Primary-Secondary kind of communication. 
> I don't know how to achieve the same using PPP since i need 
> to have max of 10 nodes connected via serial interface. I 
> tested with two nodes using PPP daemon it works fine. 
> Following are the commands i issued
> 
> In PPP server: 
> $usr/sbin/pppd -detach crtscts 10.10.10.100:10.10.10.101 
> 115200 /dev/ttyS0 &
> 
> In PPP client side : 
> $/usr/sbin/pppd call ppp-start 
> where ppp-start file is copied into directory /etc/ppp/peers/ 
> that had the following
> 
> -detach /dev/ttyS0 115200 crtscts
> noauth
> 
> This point to point communication worked fine with RS485 
> interface. If i had to connect one more node what i need to 
> do. Please clarify with the following 
> 
> i) Whether the existing pppd takes care of the RS485 with 
> multi node , if so how do i manage giving commands
> ii) If there is no direct support how do i go ahead. Is there 
> any other layer 2 protocol allows me to acheive TCP/IP 
> communicattion over RS485 which is my ultimatum.
> 
> I will be grateful if anybody of them could help me with my 
> current problem.
> 

I believe Point-to-Point Protocol only supports point-to-point symmetric
links. Don't think there is any multi-point support in the protocol. IIRC,
PPP also requires a full duplex link, which is not available on an RS-485
link with more than two stations, even if it is a 4-wire link. 

I don't know of an easy way around this fundamental limitation.

Maybe somebody on the kernel list has a suggestion.

Cheers

---------------------------------------------------------------- 
Ed Vance              edv (at) macrolink (dot) com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------

RE: RS485 communicatio

[Richard B. Johnson]

On Thu, 13 Mar 2003, Ed Vance wrote:

> On Wed, Mar 12, 2003 at 10:15 PM, linuxppp@indiainfo.com wrote:
> > Hi all,
> > am currently working on PPP over serial interface (RS485) in 
> > linux 2.4.2-2. I believe RS485 half duplex system and hence 
> > only one can transmit at a time. And for RS485 we basicaly 
> > use Master-Slave or Primary-Secondary kind of communication. 
> > I don't know how to achieve the same using PPP since i need 
> > to have max of 10 nodes connected via serial interface. I 
> > tested with two nodes using PPP daemon it works fine. 
> > Following are the commands i issued
> > 
> > In PPP server: 
> > $usr/sbin/pppd -detach crtscts 10.10.10.100:10.10.10.101 
> > 115200 /dev/ttyS0 &
> > 
> > In PPP client side : 
> > $/usr/sbin/pppd call ppp-start 
> > where ppp-start file is copied into directory /etc/ppp/peers/ 
> > that had the following
> > 
> > -detach /dev/ttyS0 115200 crtscts
> > noauth
> > 
> > This point to point communication worked fine with RS485 
> > interface. If i had to connect one more node what i need to 
> > do. Please clarify with the following 
> > 
> > i) Whether the existing pppd takes care of the RS485 with 
> > multi node , if so how do i manage giving commands
> > ii) If there is no direct support how do i go ahead. Is there 
> > any other layer 2 protocol allows me to acheive TCP/IP 
> > communicattion over RS485 which is my ultimatum.
> > 
> > I will be grateful if anybody of them could help me with my 
> > current problem.
> > 
> 
> I believe Point-to-Point Protocol only supports point-to-point symmetric
> links. Don't think there is any multi-point support in the protocol. IIRC,
> PPP also requires a full duplex link, which is not available on an RS-485
> link with more than two stations, even if it is a 4-wire link. 
> 
> I don't know of an easy way around this fundamental limitation.
> 
> Maybe somebody on the kernel list has a suggestion.
> 
> Cheers

TCP/IP only requires two-way communicaton. It does not even
have to be reliable. There are IP/SCSI adapters and fibre
channel adapters already in the kernel.

Therefore, you just make a driver that substitutes for a
network communications adapter and away you go. PPP does not,
in principle, require simultaneous two-way communications.
However, current implimentations expect that a modem is
attached.

You should be able to use any serial cmmunications device
for a PPP link although one would have to make a serial driver
that handles the TX/RX direction-change in a transparent manner
as well as the RS-485 "address" problem. If the drivers on each
connected host communicate with each other, i.e., resolve their
own address problems,, then the payload between these hosts can
be the communications channels for PPP.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

RE: RS485 communication

[Robert White]

I would tend to agree.  The 485 bus is very like an extremely limited
version of the raw level communication access an Ethernet card gives to you
to the Ethernet wiring.  (Remember that conceptually an Ethernet is a
closed-circuit radio where any peer can transmit if it sees the circuit is
idle.  This is the "carrier sense" and "collision detect" parts of the
standard.)  The 485 bus is trickier though because there is no "carrier
sense" so each slave device must be told when it is, exactly, that it can
transmit.

If you are going to use RS485 you are going to have to have a management
layer on the participating boxes so that each party knows when it is "their
turn."  That means you are going to need to write essentially a multiplexing
driver that exposes a bunch of endpoints and manages the link.  (This would
conceptually a kin to the way /dev/hda has /dev/hda1-4 for the partitions.
This is also almost exactly what a TCP socket really accomplishes over an
Ethernet.)  Each endpoint would need to act as an independent, buffered
serial port.

If all the boxen are full featured computers (running Linux), you will also
need to make sure that they all know who the master is and this will lead to
needing a complete encapsulation protocol and some configuration settings.
If all the slave devices are obviously slaves (e.g. one computer and a bunch
of modems) then the multiplexor will need to conform to whatever is already
programmed into those devices.

Regardless, the resulting configuration as seen on your Linux box would
probably end up looking something like the following:

[485 device]
    ""
[Multiplexor Program]
    ""
[Some Number of PTYs]
    ""
[one PPP Daemon per PTY]

Each slave device would need a DeMultiplexor and a PPP daemon instance on a
single PTY.

I recommend you *DO NOT* try to create a mesh.  (e.g. each of ten hosts
running a complete multiplexor with nine PPP daemons to talk directly to the
other hosts.)  You will still need a RS485 Master and all the traffic will
have to at least marginally involve that master.  It is better, if the
slaves must intercommunicate, to have the host running the master
multiplexor act as an IP router.

Remember that PPP is a "point to point" protocol not a "multipoint" protocol
(like the hardware layer of an Ethernet) so it can't directly support a
multipoint architecture.

ASIDE:
I know all this not because I am an expert on RS485 but because at a
previous job the manufacturing staff decided to save $8US per box by
installing an embedded RS485 controller chip instead of an embedded Ethernet
controller chip.  We paid for that $8US several thousand fold.  If you are
not stuck with a specific and constrained hardware problem it *WILL* be
cheaper and less time consuming to use an Ethernet.  Even if you *are*
talking to a bunch of modems or something, it will *STILL* be
better/cheaper/less hassle to buy multi-port terminal servers and wire the
target devices up to it/them individually.  RS485 has specific value for
data collection tasks but it is not your friend for anything that looks even
remotely like IP traffic (e.g. anything you would run or require PPP).  Once
the third box is installed you will get less than Token Ring version 1
protocol performance characteristics and it will be over a MUCH slower
media.

Don't be "penny wise and pound (1.8 dollar 8-) foolish."
END ASIDE

Rob.


-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Ed Vance
Sent: Thursday, March 13, 2003 8:56 AM
To: 'Linux PPP'
Cc: linux-serial@vger.kernel.org; 'linux-kernel'
Subject: RE: RS485 communicatio


On Wed, Mar 12, 2003 at 10:15 PM, linuxppp@indiainfo.com wrote:
> Hi all,
> am currently working on PPP over serial interface (RS485) in
> linux 2.4.2-2. I believe RS485 half duplex system and hence
> only one can transmit at a time. And for RS485 we basicaly
> use Master-Slave or Primary-Secondary kind of communication.
> I don't know how to achieve the same using PPP since i need
> to have max of 10 nodes connected via serial interface. I
> tested with two nodes using PPP daemon it works fine.
> Following are the commands i issued
>
> In PPP server:
> $usr/sbin/pppd -detach crtscts 10.10.10.100:10.10.10.101
> 115200 /dev/ttyS0 &
>
> In PPP client side :
> $/usr/sbin/pppd call ppp-start
> where ppp-start file is copied into directory /etc/ppp/peers/
> that had the following
>
> -detach /dev/ttyS0 115200 crtscts
> noauth
>
> This point to point communication worked fine with RS485
> interface. If i had to connect one more node what i need to
> do. Please clarify with the following
>
> i) Whether the existing pppd takes care of the RS485 with
> multi node , if so how do i manage giving commands
> ii) If there is no direct support how do i go ahead. Is there
> any other layer 2 protocol allows me to acheive TCP/IP
> communicattion over RS485 which is my ultimatum.
>
> I will be grateful if anybody of them could help me with my
> current problem.
>

I believe Point-to-Point Protocol only supports point-to-point symmetric
links. Don't think there is any multi-point support in the protocol. IIRC,
PPP also requires a full duplex link, which is not available on an RS-485
link with more than two stations, even if it is a 4-wire link.

I don't know of an easy way around this fundamental limitation.

Maybe somebody on the kernel list has a suggestion.

Cheers

----------------------------------------------------------------
Ed Vance              edv (at) macrolink (dot) com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: RS485 communication

[Chris Fowler]

Are you saying that for him to to use PPPD that he will have to write a
program that will run on a master and tell all the slave nodes when they
can transmit their data.  In this case it would be ppp data.  Hopfully
in block sizes that are at least the size of the MTU ppp is running.

Chris

On Thu, 2003-03-13 at 17:54, Robert White wrote:
> I would tend to agree.  The 485 bus is very like an extremely limited
> version of the raw level communication access an Ethernet card gives to you
> to the Ethernet wiring.  (Remember that conceptually an Ethernet is a
> closed-circuit radio where any peer can transmit if it sees the circuit is
> idle.  This is the "carrier sense" and "collision detect" parts of the
> standard.)  The 485 bus is trickier though because there is no "carrier
> sense" so each slave device must be told when it is, exactly, that it can
> transmit.
> 
> If you are going to use RS485 you are going to have to have a management
> layer on the participating boxes so that each party knows when it is "their
> turn."  That means you are going to need to write essentially a multiplexing
> driver that exposes a bunch of endpoints and manages the link.  (This would
> conceptually a kin to the way /dev/hda has /dev/hda1-4 for the partitions.
> This is also almost exactly what a TCP socket really accomplishes over an
> Ethernet.)  Each endpoint would need to act as an independent, buffered
> serial port.
> 
> If all the boxen are full featured computers (running Linux), you will also
> need to make sure that they all know who the master is and this will lead to
> needing a complete encapsulation protocol and some configuration settings.
> If all the slave devices are obviously slaves (e.g. one computer and a bunch
> of modems) then the multiplexor will need to conform to whatever is already
> programmed into those devices.
> 
> Regardless, the resulting configuration as seen on your Linux box would
> probably end up looking something like the following:
> 
> [485 device]
>     ""
> [Multiplexor Program]
>     ""
> [Some Number of PTYs]
>     ""
> [one PPP Daemon per PTY]
> 
> Each slave device would need a DeMultiplexor and a PPP daemon instance on a
> single PTY.
> 
> I recommend you *DO NOT* try to create a mesh.  (e.g. each of ten hosts
> running a complete multiplexor with nine PPP daemons to talk directly to the
> other hosts.)  You will still need a RS485 Master and all the traffic will
> have to at least marginally involve that master.  It is better, if the
> slaves must intercommunicate, to have the host running the master
> multiplexor act as an IP router.
> 
> Remember that PPP is a "point to point" protocol not a "multipoint" protocol
> (like the hardware layer of an Ethernet) so it can't directly support a
> multipoint architecture.
> 
> ASIDE:
> I know all this not because I am an expert on RS485 but because at a
> previous job the manufacturing staff decided to save $8US per box by
> installing an embedded RS485 controller chip instead of an embedded Ethernet
> controller chip.  We paid for that $8US several thousand fold.  If you are
> not stuck with a specific and constrained hardware problem it *WILL* be
> cheaper and less time consuming to use an Ethernet.  Even if you *are*
> talking to a bunch of modems or something, it will *STILL* be
> better/cheaper/less hassle to buy multi-port terminal servers and wire the
> target devices up to it/them individually.  RS485 has specific value for
> data collection tasks but it is not your friend for anything that looks even
> remotely like IP traffic (e.g. anything you would run or require PPP).  Once
> the third box is installed you will get less than Token Ring version 1
> protocol performance characteristics and it will be over a MUCH slower
> media.
> 
> Don't be "penny wise and pound (1.8 dollar 8-) foolish."
> END ASIDE
> 
> Rob.
> 
> 
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Ed Vance
> Sent: Thursday, March 13, 2003 8:56 AM
> To: 'Linux PPP'
> Cc: linux-serial@vger.kernel.org; 'linux-kernel'
> Subject: RE: RS485 communicatio
> 
> 
> On Wed, Mar 12, 2003 at 10:15 PM, linuxppp@indiainfo.com wrote:
> > Hi all,
> > am currently working on PPP over serial interface (RS485) in
> > linux 2.4.2-2. I believe RS485 half duplex system and hence
> > only one can transmit at a time. And for RS485 we basicaly
> > use Master-Slave or Primary-Secondary kind of communication.
> > I don't know how to achieve the same using PPP since i need
> > to have max of 10 nodes connected via serial interface. I
> > tested with two nodes using PPP daemon it works fine.
> > Following are the commands i issued
> >
> > In PPP server:
> > $usr/sbin/pppd -detach crtscts 10.10.10.100:10.10.10.101
> > 115200 /dev/ttyS0 &
> >
> > In PPP client side :
> > $/usr/sbin/pppd call ppp-start
> > where ppp-start file is copied into directory /etc/ppp/peers/
> > that had the following
> >
> > -detach /dev/ttyS0 115200 crtscts
> > noauth
> >
> > This point to point communication worked fine with RS485
> > interface. If i had to connect one more node what i need to
> > do. Please clarify with the following
> >
> > i) Whether the existing pppd takes care of the RS485 with
> > multi node , if so how do i manage giving commands
> > ii) If there is no direct support how do i go ahead. Is there
> > any other layer 2 protocol allows me to acheive TCP/IP
> > communicattion over RS485 which is my ultimatum.
> >
> > I will be grateful if anybody of them could help me with my
> > current problem.
> >
> 
> I believe Point-to-Point Protocol only supports point-to-point symmetric
> links. Don't think there is any multi-point support in the protocol. IIRC,
> PPP also requires a full duplex link, which is not available on an RS-485
> link with more than two stations, even if it is a 4-wire link.
> 
> I don't know of an easy way around this fundamental limitation.
> 
> Maybe somebody on the kernel list has a suggestion.
> 
> Cheers
> 
> ----------------------------------------------------------------
> Ed Vance              edv (at) macrolink (dot) com
> Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
> ----------------------------------------------------------------
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

RE: RS485 communication

[Robert White]

Yes, that, but that is only part of it.

The RS485 is a proper bus, so this custom program (or programs) will have to
act as full bus arbiters and a kind of router.  Each PPP daemon must receive
ONLY the data that its peer daemon transmits.  That means that each slave
must know to ignore the data not destined for it.  Further, the master,
which would have multiple PPP instances running on it, will need to decide
which of those instances get which of the receiving bytes.

So just like an Ethernet transceiver puts a protocol frame around the data
to get it to the destination, the transport program will have to put
envelopes around the data.  THEN the master transport program will tell each
slave when and how many of its envelopes it may send.  The only way that can
work (because there is no "ring" you can't pass a "token") is for the master
to ask each slave in turn: "Got anything to send?"

This usually devolves to a sequence of "#1, say your piece", "#2 say your
piece" etc.  That is a very bad performance model.

So every frame of data will need to be arbitrarily wide, meaning a length
code, and will need an in-multiplexor address.

So the master, for instance, will say "slave 1, go".  The slave 1 will send
a packet (not necessarily a PPP packet, as the multiplexor will have
overhead data etc.)

The master will look at the address and decide which local pty the data is
for and send it there.  (Think a simple byte pump here)

When that pty has response data, and when the master says "slave 0 (e.g. me)
go" it will frame a message that slave #1 will receive and put through to
its local pty.  Slave 1 also has the job of ignoring data for slaves 2
through N and the Master (Slave 0).

In short, he has to write a distributed application that pumps data into and
out of a broadcast medium, and makes sure that each participant gets only
the data intended for itself.  (This is what both the Ethernet hardware
layer, and the IP protocols do.)

In communications you almost always put protocols inside of protocols to
some significant depth.

For instance, when you play Unreal Tournament 2003:
Unreal Tournament's data is carried by UDP,
The UDP is carried by IP,
The IP is carried by the Ethernet hardware access layer (raw Ethernet),
Those packets may go to your cable modem which either wraps the Ethernet
hardware packets or decodes them and reencodes the IP  into whatever it
does.

>From there, if your cable modem is doing PPPoE there are even more layers.

This guy will only have to write a multiplexing layer, but it won't be fun.

Then again, the Ethernet people have done all that, which is why it is
cheaper and easier to just get the Ethernet hardware and use it.

Rob.

-----Original Message-----
From: Chris Fowler [mailto:cfowler@outpostsentinel.com]
Sent: Thursday, March 13, 2003 3:31 PM
To: Robert White
Cc: Ed Vance; 'Linux PPP'; linux-serial@vger.kernel.org; 'linux-kernel'
Subject: RE: RS485 communication


Are you saying that for him to to use PPPD that he will have to write a
program that will run on a master and tell all the slave nodes when they
can transmit their data.  In this case it would be ppp data.  Hopfully
in block sizes that are at least the size of the MTU ppp is running.

Chris

RE: RS485 communication

[David Woodhouse]

On Thu, 2003-03-13 at 23:30, Chris Fowler wrote:
> Are you saying that for him to to use PPPD that he will have to write a
> program that will run on a master and tell all the slave nodes when they
> can transmit their data.  In this case it would be ppp data.  Hopfully
> in block sizes that are at least the size of the MTU ppp is running.

You don't _need_ a master, although it's often an easy answer.

You can have a token-bus arrangement like ARCnet does. In fact, the
ARCnet data sheets describing how it works may make interesting reading.

-- 
dwmw2

RE: RS485 communication

[Chris Fowler]

I think using SOCK_PACKET an an ethernet chip may be the best choice. 
You can use IP or you can use RWP (Rober White Protocol).


On Sat, 2003-03-15 at 03:07, Robert White wrote:
> Yes, that, but that is only part of it.
> 
> The RS485 is a proper bus, so this custom program (or programs) will have to
> act as full bus arbiters and a kind of router.  Each PPP daemon must receive
> ONLY the data that its peer daemon transmits.  That means that each slave
> must know to ignore the data not destined for it.  Further, the master,
> which would have multiple PPP instances running on it, will need to decide
> which of those instances get which of the receiving bytes.
> 
> So just like an Ethernet transceiver puts a protocol frame around the data
> to get it to the destination, the transport program will have to put
> envelopes around the data.  THEN the master transport program will tell each
> slave when and how many of its envelopes it may send.  The only way that can
> work (because there is no "ring" you can't pass a "token") is for the master
> to ask each slave in turn: "Got anything to send?"
> 
> This usually devolves to a sequence of "#1, say your piece", "#2 say your
> piece" etc.  That is a very bad performance model.
> 
> So every frame of data will need to be arbitrarily wide, meaning a length
> code, and will need an in-multiplexor address.
> 
> So the master, for instance, will say "slave 1, go".  The slave 1 will send
> a packet (not necessarily a PPP packet, as the multiplexor will have
> overhead data etc.)
> 
> The master will look at the address and decide which local pty the data is
> for and send it there.  (Think a simple byte pump here)
> 
> When that pty has response data, and when the master says "slave 0 (e.g. me)
> go" it will frame a message that slave #1 will receive and put through to
> its local pty.  Slave 1 also has the job of ignoring data for slaves 2
> through N and the Master (Slave 0).
> 
> In short, he has to write a distributed application that pumps data into and
> out of a broadcast medium, and makes sure that each participant gets only
> the data intended for itself.  (This is what both the Ethernet hardware
> layer, and the IP protocols do.)
> 
> In communications you almost always put protocols inside of protocols to
> some significant depth.
> 
> For instance, when you play Unreal Tournament 2003:
> Unreal Tournament's data is carried by UDP,
> The UDP is carried by IP,
> The IP is carried by the Ethernet hardware access layer (raw Ethernet),
> Those packets may go to your cable modem which either wraps the Ethernet
> hardware packets or decodes them and reencodes the IP  into whatever it
> does.
> 
> >From there, if your cable modem is doing PPPoE there are even more layers.
> 
> This guy will only have to write a multiplexing layer, but it won't be fun.
> 
> Then again, the Ethernet people have done all that, which is why it is
> cheaper and easier to just get the Ethernet hardware and use it.
> 
> Rob.
> 
> -----Original Message-----
> From: Chris Fowler [mailto:cfowler@outpostsentinel.com]
> Sent: Thursday, March 13, 2003 3:31 PM
> To: Robert White
> Cc: Ed Vance; 'Linux PPP'; linux-serial@vger.kernel.org; 'linux-kernel'
> Subject: RE: RS485 communication
> 
> 
> Are you saying that for him to to use PPPD that he will have to write a
> program that will run on a master and tell all the slave nodes when they
> can transmit their data.  In this case it would be ppp data.  Hopfully
> in block sizes that are at least the size of the MTU ppp is running.
> 
> Chris
> 

Re: RS485 communicatio

[Pavel Machek]

Hi!

> > I will be grateful if anybody of them could help me with my 
> > current problem.
> > 
> 
> I believe Point-to-Point Protocol only supports point-to-point symmetric
> links. Don't think there is any multi-point support in the protocol. IIRC,
> PPP also requires a full duplex link, which is not available on an RS-485
> link with more than two stations, even if it is a 4-wire link. 

Get scarabd (I don't know *where* it is), it can run TCP/IP over slip over
half-duplex link. Performance is not too good.
									Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

RE: RS485 communication

[Alan Cox]

On Sat, 2003-03-15 at 12:46, David Woodhouse wrote:
> On Thu, 2003-03-13 at 23:30, Chris Fowler wrote:
> > Are you saying that for him to to use PPPD that he will have to write a
> > program that will run on a master and tell all the slave nodes when they
> > can transmit their data.  In this case it would be ppp data.  Hopfully
> > in block sizes that are at least the size of the MTU ppp is running.
> 
> You don't _need_ a master, although it's often an easy answer.
> 
> You can have a token-bus arrangement like ARCnet does. In fact, the
> ARCnet data sheets describing how it works may make interesting reading.

RS485 supports CDMA, thats more than enough to implement ppp nicely, all
you have to do is a little abuse in the app or driver layer to block
sending when carrier is asserted

RE: RS485 communication

[David Woodhouse]

On Sun, 2003-03-16 at 00:56, Alan Cox wrote:
> RS485 supports CDMA, thats more than enough to implement ppp nicely, all
> you have to do is a little abuse in the app or driver layer to block
> sending when carrier is asserted

Note you don't need any separate lines for this. If someone else is
transmitting a zero while you are also transmitting a zero, that's fine
and you didn't stomp on each other. If someone else is transmitting a
zero while you are transmitting a one, you won and a one was
transmitted, and they back off. If they transmit a one while you
transmit a zero, then they won :)

That's how CAN does it, IIRC. I don't believe it actually requires
synchronous clocks.

-- 
dwmw2

Re: RS485 communication

[Russell King]

On Sun, Mar 16, 2003 at 10:05:31AM +0000, David Woodhouse wrote:
> Note you don't need any separate lines for this. If someone else is
> transmitting a zero while you are also transmitting a zero, that's fine
> and you didn't stomp on each other. If someone else is transmitting a
> zero while you are transmitting a one, you won and a one was
> transmitted, and they back off. If they transmit a one while you
> transmit a zero, then they won :)

No - that's not how RS485 works.  With a balanced line, the result
that any one receiver will see will depend on it's position on the
line and the relative distance to each transmitter, the resistance
of the line, and the manufacturer/type of the RS485 transceiver.
In other words, the state you see is indeterminent.

Also, a correctly terminated RS485 has no way to tell if someone is
transmitting other than yourself receiving characters since the
termination resistors bias the line into the mark state.

If you don't have a correctly biased RS485 line, you can end up with
framing errors with validly transmitted data, and given the right
data pattern, it could be an undetectable without checksums and the
like. What's worse is that this type of error can occur each time
you retransmit.  Naturally, there are certain tricks you can pull to
ensure that the receiver is properly synchronised before you transmit
real data.

Been there, seen the problem, diagnosed it, and modified embedded
software on both master and slave ends to work around it.  After
you've dealt with equipment with 20 RS485 buses internally with up
to 50 transceivers on a line, and around 50 RS485 buses running
around large buildings to various sensors, you end up understanding
some of these problems fairly well. 8/

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: RS485 communication

[David Woodhouse]

On Sun, 2003-03-16 at 10:35, Russell King wrote
> No - that's not how RS485 works.  With a balanced line, the result
> that any one receiver will see will depend on it's position on the
> line and the relative distance to each transmitter, the resistance
> of the line, and the manufacturer/type of the RS485 transceiver.
> In other words, the state you see is indeterminent.

Ah, OK. Then I must have been mistaken in thinking that CAN was based on
RS485 -- or mistaken in remembering that that's how CAN does collision
avoidance I suppose, but I suspect the former is more likely.

Thanks for the correction.

-- 
dwmw2

Re: RS485 communicatio

[Alan Cox]

On Sat, 2003-03-15 at 19:46, Pavel Machek wrote:
> > I believe Point-to-Point Protocol only supports point-to-point symmetric
> > links. Don't think there is any multi-point support in the protocol. IIRC,
> > PPP also requires a full duplex link, which is not available on an RS-485
> > link with more than two stations, even if it is a 4-wire link. 
> 
> Get scarabd (I don't know *where* it is), it can run TCP/IP over slip over
> half-duplex link. Performance is not too good.

Robin O'Leary wrote most of it, so its probably somewhere like
caderus.co.uk

Half duplex performance is fine at a sensible speed and with decent
reliability. On radio will collisions its a lot less pretty