Serial (rs232 etc.) to IP

On 2005-10-28, Sonic <spam@spam.com> wrote:
>
> "Grant Edwards" <grante@visi.com> wrote in message 
> news:11m273c4bu05484@corp.supernews.com...
>> On 2005-10-27, Sonic <spam@spam.com> wrote:
>>
>>> I'm not sure if I am missing something, but this seems like a
>>> stupid conversation :)
>>>
><SNIP>
>>
>> Right, but how do you set the baud rate and parity?  How do you
>> get notified when a break or parity error was received?
>
> I can not find any mention in this thread of baud rate or parity needing to 
> be maintained over this TCP/IP connection.

Those are part of a normal "Serial (RS-232 etc.)" link.

> If you picture the primitve technology between a PC and a
> modem, the parity, baud, stop bits, etc. are configured
> between the serial port and the modem.

Not sure what you mean "configured between", they're configured
in each of the serial port and mode.

> The modem then negotiates settings with the remote peer. The
> remote peer has no notion of the fact that the PC is running
> at 115,200 with 1 stop bit and no parity, or whatever. It is
> irrelevant.

But the serial port and the modem must be running at the same
baud rate, parity, and stop bits.

> The remote peer has configured its own method of communicating
> with the telephone line. This might be an Ethernet aggregator,
> in which case, there is no baud rate unless you consider
> 100Mbit Ethernet to have a baud rate.

I've no clue what you're getting at.  When using Ethernet to
interface to a UART instead of PCI or ISA bus, you still need a
method to control the UART's settings (parity, buad rate, stop
bits, flow control, modem control lines, etc) and to read the
UART's status (errors, modem status etc.).

>>> Open a socket on one end and listen.
>>>
>>> Start sending characters to the remote socket.
>>
>> You apparently have never used a UART or serial port.  There's
>> a lot more to it that "start sending characters".
>
> I try not to make those type of judgements about people that I
> speak with in Usenet, more often than not those judgements
> would be wrong.
>
> The essence of this thread is that UART is history...how do we
> get rid of them?

This thread is not about getting rid of UARTs.  It's about
interfacing to a UART via Ethernet instead of PCI or ISA bus.
If you've got some magical way of connecting Ethernet to an
RS-232 serial data stream without using a UART, I'd like to
hear about it.

> The original author's question was regarding how to transport
> the serial data over a TCP/IP network.

His original question was about RS-232 Serial via Ethernet.

> I agree with you that clearly the data being received from the
> legacy device would be obtained at a particular rate, but I
> think it is safe to assume that that part of the system has
> been working for some time...hence the legacy.

I've designed and supported serial<->Ethernet products for many
years.  In the case the OP is talking about (providing a normal
"COM port" API to the application), you have to provide all of
the normal OOB stuff that a UART supports.

> What I believe we are dealing with here is that data is
> arriving at a UART at a given baud rate. We don't care what
> rate or parity, other than to ensure that we receive it all
> and don't lose any.

And you've got to provide the application a way to set that
baud rate and parity so that you _do_ receive it all and don't
lose any.  You've also got to provide the application a way to
set flow control, read modem status lines, etc.  There's a lot
more to RS-232 serial ports than data -- which is why all the
different protocls (like RFC2217) were invented when people
whated to do RS-232 via Ethernet (IP or otherwise).

> 'tis so! :) 

You seem to be focusing completely on the most trivial part of
the problem and doing nothing but hand-waving about the other
90%.

-- 
Grant Edwards                   grante             Yow!  Where do your SOCKS
                                  at               go when you lose them in
                               visi.com            th' WASHER?

Surely it is reasonable to expect that the legacy product already does *all* 
of that.

This problem is really *really* old.

The scenario:
Old product that used to connect via RS232 to a PC about 6 feet away.
New product that needs to be connected to PC about 6 degrees away.

Problem:
Legacy product must not change.

Solution:
Write program on PC 6 feet away that sends data to PC 6 degrees away. 20 
lines of code.
Modify program on PC 6 degrees away. 20 lines of code.

Note to self:
Do not get hung up on tedious baud rate issues...remind self continuously 
that they are not relevant to the problem.


<cs_posting@hotmail.com> wrote in message 
news:1130510981.299524.194700@g47g2000cwa.googlegroups.com...
> Sonic wrote:
>
>> I can not find any mention in this thread of baud rate or parity needing 
>> to
>> be maintained over this TCP/IP connection.
>
> No, but both are things we could reasonably expect might be needed.
>
> It's no the maintenance of baud rate that is important, but the serial
> side of the converter does need to be configured with the right baud
> rate (and word length and stop bits and parity setting) somehow.  Your
> options broadly speaking are hard coding, dip switches, auto detect, or
> a configuration command going over the ethernet side of the link.
> Similarly, the ethernet side needs to be configured for IP address,
> port number, protocol etc with similar options for how to do it.
>
> Parity is a possible serial error condition, which if present could
> need to be reported to the device on the ethernet side.  You have to
> figure out how you will signal that.  Similarly hardware flow control.
> You also may have status and errors from any protocol on the ethernet
> side, for which it may be necessary to pass through to the serial
> device somehow.
>
> Hard coding or dip switch configuration and ignoring error conditions
> can make this all very simple... but that may not be acceptable in the
> (undescribed) appliction.
> 

Sonic wrote:
> Surely it is reasonable to expect that the legacy product already does *all*
> of that.

Yes, which is why you have to be sure to support what the legacy
product expects.

If the legacy product uses parity, you have to tunnel or translate the
results of the parity compare over your ethernet link.

If the legacy product uses hardware flow control, you have to tunnel or
translate hardware flow control.

If you need to support a variety of possible baud rate or other
settings on the legacy product (users are using it in different ways)
you must be able to configure your translator's serial side to match.

And you must be able to configure the ethernet side settings of your
translator.

If it's a custom one-off, this is easy.  The more varied configurations
it needs to support, the harder the translation task.

Yes I agree Grant.

If indeed the original poster was concerned with developing a device that 
converted serial to Ethernet then baud rate, etc. would be a problem, as 
would all the Ethernet issues.

However, the market is already saturated with such devices, and they cost a 
few pennies, so I do not think someone would be contemplating developing 
their own.

Hence, I took the view that the poster was actually wanting to write a piece 
of software that took the data that was received from the serial port of his 
PC (from the legacy device) and send it out over the Internet to a remote 
terminal.

Based on that I wave my hand at 90% of the problem because the legacy device 
is *already* connected to the PC at the correct baud rate and data is 
*already* being received.

The 10% of the problem remaining is as I have described...Take the serial 
data, open a socket, send it.

If the original poster is contemplating designing a serial to ethernet 
converter then I agree wholeheartedly that at least 90% of the problem 
remains.

Regards.

"Grant Edwards" <grante@visi.com> wrote in message 
news:11m4epid216bb65@corp.supernews.com...
> On 2005-10-28, Sonic <spam@spam.com> wrote:
>>
>> "Grant Edwards" <grante@visi.com> wrote in message
>> news:11m273c4bu05484@corp.supernews.com...
>>> On 2005-10-27, Sonic <spam@spam.com> wrote:
>>>
<SNIP> 

On 2005-10-28, Sonic <spam@spam.com> wrote:

> Surely it is reasonable to expect that the legacy product
> already does *all* of that.

What "legacy product"?

> This problem is really *really* old.
>
> The scenario:
> Old product that used to connect via RS232 to a PC about 6 feet away.
> New product that needs to be connected to PC about 6 degrees away.

6 degrees away?  What does that mean?

Firstly I've never seen that scenario happen.  The problem that
usually needs to be sovled is:

PC talks to device X via RS-232 port.  Now we want to move
device X to the other side of the building (or use a PC w/o a
serial port).  

We are not allowed to 

 * modify device X
 
 * move the PC or change it's application software.

So we plug a serial<->Ethernet widget into device X's serial
port, connect said widget and the PC to "the network", and
install a device driver on the PC that makes said widget's
serial port appear as a "COM port" in Windows-speak.  The PC's
application SW still needs to be able control wiget X's serial
port configuration and read it's status.  We're just replacing
the PCI or ISA with Ethernet.  Everything that the PC
application used to be able to do with the serial port via the
old busses needs to be supported via the new one (Ethernet).

> Problem:
> Legacy product must not change.
>
> Solution:
> Write program on PC 6 feet away that sends data to PC 6 degrees away. 20 
> lines of code.

You seem to have replaced the legacy product with a PC, and
then written custom software for both PCs.  The requirements
are use the existing legacy product and PC application.  You
don't get to add extra PCs or re-write the legacy applications.

> Modify program on PC 6 degrees away. 20 lines of code.

In my experience, you're never, ever allowed to do that.

> Note to self:
> Do not get hung up on tedious baud rate issues...remind self continuously 
> that they are not relevant to the problem.

You've never done serial stuff in the field, eh?
Baud/parity/flow/etc. are a _huge_ part of the
serial-communications "problem".  The data part of it is
trivial.

-- 
Grant Edwards                   grante             Yow!  Don't hit me!! I'm in
                                  at               the Twilight Zone!!!
                               visi.com            

Said OP says:
  I am indeed doing a serial to ethernet product, but not stand alone.
It is part of a much larger & expansive product.  It appears that
existing serial to ethernet products let the user decide what TCP or
UDP port to use, leaving the decision to the installer.  Terminal
servers on the other hand are ... well ... terminal servers, and on the
IP side use telnet, while allowing the user also to set
baud,parity,stop bits, for the terminal servers UART.  In my experience
I think I've seen just one example where the device on the "far" side
of a serial link, let's communications from the other side set its com
parameters via the com link, since you will then immediatley loose the
connection ... sometimes you might be able to reconfigure the other
end, and reconnect, sometimes not...  I just have only seen that once,
but perhaps it's more pervasive than my experience...

Let's put this thread out to pasture...
-D

Sonic wrote:
> Yes I agree Grant.
>
> If indeed the original poster was concerned with developing a device that
> converted serial to Ethernet then baud rate, etc. would be a problem, as
> would all the Ethernet issues.
>
> However, the market is already saturated with such devices, and they cost a
> few pennies, so I do not think someone would be contemplating developing
> their own.
>
> Hence, I took the view that the poster was actually wanting to write a piece
> of software that took the data that was received from the serial port of his
> PC (from the legacy device) and send it out over the Internet to a remote
> terminal.
>
> Based on that I wave my hand at 90% of the problem because the legacy device
> is *already* connected to the PC at the correct baud rate and data is
> *already* being received.
>
> The 10% of the problem remaining is as I have described...Take the serial
> data, open a socket, send it.
>
> If the original poster is contemplating designing a serial to ethernet
> converter then I agree wholeheartedly that at least 90% of the problem
> remains.
>
> Regards.
>
> "Grant Edwards" <grante@visi.com> wrote in message
> news:11m4epid216bb65@corp.supernews.com...
> > On 2005-10-28, Sonic <spam@spam.com> wrote:
> >>
> >> "Grant Edwards" <grante@visi.com> wrote in message
> >> news:11m273c4bu05484@corp.supernews.com...
> >>> On 2005-10-27, Sonic <spam@spam.com> wrote:
> >>>
> <SNIP>

packer44@hotmail.com wrote:

> I think I've seen just one example where the device on the "far" side
> of a serial link, let's communications from the other side set its com
> parameters via the com link, since you will then immediatley loose the
> connection ... sometimes you might be able to reconfigure the other
> end, and reconnect, sometimes not...  I just have only seen that once,
> but perhaps it's more pervasive than my experience...

Something has to set the paramaters.  You either use something physical
(dip switches were traditional when RS232 was king) or you use a soft
configuration.  With a soft configuration, it has to originate from
something with a user interface, which for "device" may well be the
computer terminal on the other end of the link.

Pretty much any "device" is going to have one of fixed factory settins,
switches, auto detect, remote soft configuration - or have it's own
user interface.