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

Re: RS485 communication

[Paul Mackerras]

Cigol C writes:

> i) Linux PPP interface with IP: Registration, Packet send/receive/close
> ii) Linux PPP interface with serial driver:Registration, Packet send/receive/close

See Documentation/networking/ppp_generic.txt in any recent linux
kernel source tree.

> iii) Linux PPP server configuration and initial sequence of working. i.e. associating a IP address with serial device and ppp0

You will need a plugin for pppd that provides a new channel type.  See
the rp-pppoe plugin for an example of how this is done.

However, given that rs485 is multidrop, I really don't think PPP is
the best protocol to use.

RS485 communication

[Joachim Franek]

Hi,
have a look to my net9eth and net9ch driver code:

http://rs485.de-franek.de/

Greetings,
Joachim 
http://www.pibf.de

RS485 communication

[Cigol C]

Hi all,
Regarding RS485 communication I thank all of them for their responses. I finally decided to write a custom Layer 2 char driver or protocol to pave way for my IP over RS485 communication. I will like to get some inputs/docs/references on linux-ppp implementation. ISo am in the process of browsing the PPP code and exploring the interface it has with the serial driver which is crucial for me. Regarding this I request for more clarity on following: 
i) Linux PPP interface with IP: Registration, Packet send/receive/close
ii) Linux PPP interface with serial driver:Registration, Packet send/receive/close
iii) Linux PPP server configuration and initial sequence of working. i.e. associating a IP address with serial device and ppp0

I will be grateful if somebody could help me on this.
Thanks and Best Regards
Karthik
-- 
______________________________________________
http://www.indiainfo.com
Now with POP3/SMTP access for only US$14.95/yr

Powered by Outblaze

RE: RS485 communication

[Robert White]

Um... Chris' choice three was my choice 1 (if you go back through the thread
to the long explanation.)

Chris said the core of it better.  8-)

But remember, this thing has to run on each slave, it has to run multiply on
the master (or be multi-headed, with multiple ptys).  The protocol has to
have targeting (addressing).  And some program/instance/something has to be
the master/gatekeeper of who gets to talk when.  Making the "master" a
slightly different program from the slaves, or requiring the binary to be
very configurable in this regard.

Rob.

-----Original Message-----
From: Chris Fowler [mailto:cfowler@outpostsentinel.com]
Sent: Thursday, March 20, 2003 3:18 PM
To: Robert White
Cc: Cigol C; EdV@macrolink.com; linux-serial@vger.kernel.org;
'linux-kernel'
Subject: RE: RS485 communication


Choice 3.

create a program that works like a ppp tunnetl through the internet.
Instead ot using the tty of RS485 on the command line, use a pseudo
tty.  Then write some nasty code that will read the master pseudo and
send that pppd out the RS485 port via its own protocol.  so the pppd
data will be burried in the protocol of the middle man that runs.

Of course, ppp is point-to-point.  So  I'm not sure how you'll overcome
that problem.  You'll have to pair up the clients to the server if you
have multiple hosts on one RS485 line.  In other words, ppp is not pmp.
point-to-mesh.  Its point A to point B.

Chris

On Thu, 2003-03-20 at 18:09, Robert White wrote:
> I don't know if I answered this already...
>
> No.
>
> There is no "SOCK_PACKET" defined for the RS485 (serial) driver.  The
users
> comment about using SOCK_PACKET was made with respect to an Ethernet chip
> (and by extension driver).  You DON't HAVE a socket call interface until
you
> have gotten the IP up and running via PPP or some such.
>
> To do IP over RS485 you need to use PPP (or something similar).
>
> Any PPP daemon (instance) talks to exactly one other PPP daemon.  No
> exceptions.  "Point to Point Protocol".
>
> RS485 with only two participants is nearly indistinguishable from RS232
(as
> far as an application space entity like pppd is concerned.)
>
> If there are more than two participants on the RS485 bus then you need to
> write something to run between the RS485 driver and the multiple pppd(s)
to
> make sure that the PPP daemons run in pairs and only see data intended for
> one another.  (To the best of my knowledge) Nothing currently exists in
the
> commons that does this for you.  [I am sure someone has wrote this for
some
> purpose sometime, but I know of no source for it.]
>
> No shortcuts.
> No magic settings hiding somewhere in PPPd.
>
> You have exactly two-point-two choices.
>
> Choice 1:  Write a master/slaves arbiter and multiplexor.
>
> Choice 1.1: find someone who already wrote one that exposes a nice bunch
of
> pty(s) to the application space.
>
> Choice 2: Go buy hardware (c.f. an Ethernet card [or chip if you are
> designing custom hardware])
>
> Choice 2.1: put only two machines on any RS485 bus (e.g. buy one RS485
port
> per peer).
>
> That's it.  Sorry... 8-)
>
> Rob.
>
> -----Original Message-----
> From: Cigol C [mailto:linuxppp@indiainfo.com]
> Sent: Sunday, March 16, 2003 9:42 PM
> To: cfowler@outpostsentinel.com; rwhite@casabyte.com
> Cc: EdV@macrolink.com; 'Linux PPP'; linux-serial@vger.kernel.org;
> 'linux-kernel'
> Subject: RE: RS485 communication
>
>
>
> Thannks for the info. Can i acheive IP over RS485 if i use SOCK_PACKET. I
> need some more info on this if u could provide that. If this option is set
> in the socket call will i have an option the choose the hardware
interface.
>
> ----- Original Message -----
> From: Chris Fowler
> Date: 15 Mar 2003 10:42:53 -0500
> To: Robert White
> Subject: RE: RS485 communication
>
> > 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
> > >
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-serial"
in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> ______________________________________________
> http://www.indiainfo.com
> Now with POP3/SMTP access for only US$14.95/yr
>
> Powered by Outblaze

RE: RS485 communication

[Chris Fowler]

Choice 3.

create a program that works like a ppp tunnetl through the internet. 
Instead ot using the tty of RS485 on the command line, use a pseudo
tty.  Then write some nasty code that will read the master pseudo and
send that pppd out the RS485 port via its own protocol.  so the pppd
data will be burried in the protocol of the middle man that runs.

Of course, ppp is point-to-point.  So  I'm not sure how you'll overcome
that problem.  You'll have to pair up the clients to the server if you
have multiple hosts on one RS485 line.  In other words, ppp is not pmp.
point-to-mesh.  Its point A to point B.

Chris

On Thu, 2003-03-20 at 18:09, Robert White wrote:
> I don't know if I answered this already...
> 
> No.
> 
> There is no "SOCK_PACKET" defined for the RS485 (serial) driver.  The users
> comment about using SOCK_PACKET was made with respect to an Ethernet chip
> (and by extension driver).  You DON't HAVE a socket call interface until you
> have gotten the IP up and running via PPP or some such.
> 
> To do IP over RS485 you need to use PPP (or something similar).
> 
> Any PPP daemon (instance) talks to exactly one other PPP daemon.  No
> exceptions.  "Point to Point Protocol".
> 
> RS485 with only two participants is nearly indistinguishable from RS232 (as
> far as an application space entity like pppd is concerned.)
> 
> If there are more than two participants on the RS485 bus then you need to
> write something to run between the RS485 driver and the multiple pppd(s) to
> make sure that the PPP daemons run in pairs and only see data intended for
> one another.  (To the best of my knowledge) Nothing currently exists in the
> commons that does this for you.  [I am sure someone has wrote this for some
> purpose sometime, but I know of no source for it.]
> 
> No shortcuts.
> No magic settings hiding somewhere in PPPd.
> 
> You have exactly two-point-two choices.
> 
> Choice 1:  Write a master/slaves arbiter and multiplexor.
> 
> Choice 1.1: find someone who already wrote one that exposes a nice bunch of
> pty(s) to the application space.
> 
> Choice 2: Go buy hardware (c.f. an Ethernet card [or chip if you are
> designing custom hardware])
> 
> Choice 2.1: put only two machines on any RS485 bus (e.g. buy one RS485 port
> per peer).
> 
> That's it.  Sorry... 8-)
> 
> Rob.
> 
> -----Original Message-----
> From: Cigol C [mailto:linuxppp@indiainfo.com]
> Sent: Sunday, March 16, 2003 9:42 PM
> To: cfowler@outpostsentinel.com; rwhite@casabyte.com
> Cc: EdV@macrolink.com; 'Linux PPP'; linux-serial@vger.kernel.org;
> 'linux-kernel'
> Subject: RE: RS485 communication
> 
> 
> 
> Thannks for the info. Can i acheive IP over RS485 if i use SOCK_PACKET. I
> need some more info on this if u could provide that. If this option is set
> in the socket call will i have an option the choose the hardware interface.
> 
> ----- Original Message -----
> From: Chris Fowler
> Date: 15 Mar 2003 10:42:53 -0500
> To: Robert White
> Subject: RE: RS485 communication
> 
> > 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
> > >
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> ______________________________________________
> http://www.indiainfo.com
> Now with POP3/SMTP access for only US$14.95/yr
> 
> Powered by Outblaze

RE: RS485 communication

[Robert White]

I don't know if I answered this already...

No.

There is no "SOCK_PACKET" defined for the RS485 (serial) driver.  The users
comment about using SOCK_PACKET was made with respect to an Ethernet chip
(and by extension driver).  You DON't HAVE a socket call interface until you
have gotten the IP up and running via PPP or some such.

To do IP over RS485 you need to use PPP (or something similar).

Any PPP daemon (instance) talks to exactly one other PPP daemon.  No
exceptions.  "Point to Point Protocol".

RS485 with only two participants is nearly indistinguishable from RS232 (as
far as an application space entity like pppd is concerned.)

If there are more than two participants on the RS485 bus then you need to
write something to run between the RS485 driver and the multiple pppd(s) to
make sure that the PPP daemons run in pairs and only see data intended for
one another.  (To the best of my knowledge) Nothing currently exists in the
commons that does this for you.  [I am sure someone has wrote this for some
purpose sometime, but I know of no source for it.]

No shortcuts.
No magic settings hiding somewhere in PPPd.

You have exactly two-point-two choices.

Choice 1:  Write a master/slaves arbiter and multiplexor.

Choice 1.1: find someone who already wrote one that exposes a nice bunch of
pty(s) to the application space.

Choice 2: Go buy hardware (c.f. an Ethernet card [or chip if you are
designing custom hardware])

Choice 2.1: put only two machines on any RS485 bus (e.g. buy one RS485 port
per peer).

That's it.  Sorry... 8-)

Rob.

-----Original Message-----
From: Cigol C [mailto:linuxppp@indiainfo.com]
Sent: Sunday, March 16, 2003 9:42 PM
To: cfowler@outpostsentinel.com; rwhite@casabyte.com
Cc: EdV@macrolink.com; 'Linux PPP'; linux-serial@vger.kernel.org;
'linux-kernel'
Subject: RE: RS485 communication



Thannks for the info. Can i acheive IP over RS485 if i use SOCK_PACKET. I
need some more info on this if u could provide that. If this option is set
in the socket call will i have an option the choose the hardware interface.

----- Original Message -----
From: Chris Fowler
Date: 15 Mar 2003 10:42:53 -0500
To: Robert White
Subject: RE: RS485 communication

> 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
> >
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
______________________________________________
http://www.indiainfo.com
Now with POP3/SMTP access for only US$14.95/yr

Powered by Outblaze

RE: RS485 communication

[Cigol C]

Thannks for the info. Can i acheive IP over RS485 if i use SOCK_PACKET. I need some more info on this if u could provide that. If this option is set in the socket call will i have an option the choose the hardware interface.

----- Original Message ----- 
From: Chris Fowler 
Date: 15 Mar 2003 10:42:53 -0500 
To: Robert White 
Subject: RE: RS485 communication 

> 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 
> > 
> 
> 
> - 
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in 
> the body of a message to majordomo@vger.kernel.org 
> More majordomo info at http://vger.kernel.org/majordomo-info.html 
-- 
______________________________________________
http://www.indiainfo.com
Now with POP3/SMTP access for only US$14.95/yr

Powered by Outblaze