Splitting a serial (RS232) port signal?

I have a hardware platform that only have one serial port (COM1, a
RS232 port) available, but I need to connect to two devices. The
following diagram shows how A and application B want to talk to device
Ad and device Bd respectively (over the single COM port).

App A----
            |                                |---- COM1A------ Device
Ad
            COM1---- SPLITTER----
            |                                |---- COM1B------ Device
Bd
App B----

So, I though of creating a small splitter device that would know how
to split and combine data and send it to the right port. Meaning, data
from AppA would end up on COM1A for device Ad and data from AppB would
end up on COM1B for device Bd.

I thought that to accomplish this I could prefix something to the
message sent from each application which would act like a routing
signal and the splitter would then look at it and send the message
(minus the prefix) to the right port. Similarly, for data arriving
over one of the split port, the splitter would add the prefix and send
it back to the host, where it would again be looked at and routed to
the correct application.

I hope this was clear and not confusing!

So...... my question is, is this a good way to accomplish this? Are
their devices that do it? I did find references to "serial port
splitters" but they were all for PC environment and all my devices are
embedded boxes.

Thanks for your inputs!

ElderUberGeek wrote:

> I have a hardware platform that only have one serial port (COM1, a
> RS232 port) available, but I need to connect to two devices. The
> following diagram shows how A and application B want to talk to device
> Ad and device Bd respectively (over the single COM port).
> 
> App A----
>             |                                |---- COM1A------ Device
> Ad
>             COM1---- SPLITTER----
>             |                                |---- COM1B------ Device
> Bd
> App B----
> 
> So, I though of creating a small splitter device that would know how
> to split and combine data and send it to the right port. Meaning, data
> from AppA would end up on COM1A for device Ad and data from AppB would
> end up on COM1B for device Bd.
> 
> I thought that to accomplish this I could prefix something to the
> message sent from each application which would act like a routing
> signal and the splitter would then look at it and send the message
> (minus the prefix) to the right port. Similarly, for data arriving
> over one of the split port, the splitter would add the prefix and send
> it back to the host, where it would again be looked at and routed to
> the correct application.
> 
> I hope this was clear and not confusing!
> 
> So...... my question is, is this a good way to accomplish this? Are
> their devices that do it? I did find references to "serial port
> splitters" but they were all for PC environment and all my devices are
> embedded boxes.

Hams have been doing this for years, not that
that establishes it as good practice (:

Just take the TX signal from your host and
run it to both of your peripherals.  As you
said, you'll have to have some sort of header
or protocol so that you can send packets to
the one peripheral that will be ignored by
the other.

For the 2 TX signals coming from the peripherals,
put a diode in series with each.  Point the
anode toward the peripheral and tie the cathodes
together.  Connect the cathodes to the host RX
line and also pull it to ground with a pulldown
resistor, maybe 2.2k or so.  It's called a wired-
OR.  Either signal can pull high but neither can
pull low.

Now the reason this isn't a very good solution
is that the signal into your host is not actively
driven low.  It's pulled low by the resistor.
So you have to work out kind of an ugly compromise
between fall time of your signal and loading of
the outputs.  Furthermore, the high-going signal
will be .8 volts less than the actual outputs
because of the voltage drop of the diodes.  You
might end up with a circuit that works fine today,
but a year from now, when the purchasing department
buys a different brand of RS-232 transceiver, it
stops working.

Would I use it?  If I were backed into a corner
and I could limit the baudrate to 9600 or less,
probably.  Would I prefer to redesign it right?
Yes.

ElderUberGeek wrote:

> So...... my question is, is this a good way to accomplish this? Are
> their devices that do it? I did find references to "serial port
> splitters" but they were all for PC environment and all my devices are
> embedded boxes.

embedded boxes?
based on a pc or a specific micro?

can you add a uart?

Don...


-- 
Don McKenzie
E-Mail Contact Page:               http://www.dontronics.com/e-mail.html

Crystal clear, super bright OLED LCD (128x128) for your microcontroller.
Simple serial RX/TX interface. Many memory sizes.
http://www.dontronics-shop.com/product.php?productid=16460

No More Damn Spam: http://www.wizard-of-oz.com

"ElderUberGeek" <aribloch@gmail.com> wrote in message 
news:1173464501.163143.47600@t69g2000cwt.googlegroups.com...
>
> I have a hardware platform that only have one serial port (COM1, a
> RS232 port) available, but I need to connect to two devices. The
> following diagram shows how A and application B want to talk to device
> Ad and device Bd respectively (over the single COM port).
>
> App A----
>            |                                |---- COM1A------ Device
> Ad
>            COM1---- SPLITTER----
>            |                                |---- COM1B------ Device
> Bd
> App B----
>
> So, I though of creating a small splitter device that would know how
> to split and combine data and send it to the right port. Meaning, data
> from AppA would end up on COM1A for device Ad and data from AppB would
> end up on COM1B for device Bd.
>
> I thought that to accomplish this I could prefix something to the
> message sent from each application which would act like a routing
> signal and the splitter would then look at it and send the message
> (minus the prefix) to the right port. Similarly, for data arriving
> over one of the split port, the splitter would add the prefix and send
> it back to the host, where it would again be looked at and routed to
> the correct application.
>
> I hope this was clear and not confusing!
>
> So...... my question is, is this a good way to accomplish this? Are
> their devices that do it? I did find references to "serial port
> splitters" but they were all for PC environment and all my devices are
> embedded boxes.
>
> Thanks for your inputs!
>
I've seen just what you're describing in a catalog some time ago, complete 
with a virtual multi-com port driver for Windows (although it sounds like 
your app machine isn't a Windows box). I can't remember where I saw this but 
Black Box has some stuff that looks like what you're describing:

http://www.blackbox.com/Catalog/Category.aspx?cid=381,1451,1460

Of course their stuff is pricey but if you can find a small micro with three 
UARTs or enough GPIO it should be easy to do this yourself, maybe even power 
it from the RS232 lines.

Andrew

On Mar 9, 12:21 pm, "ElderUberGeek" <aribl...@gmail.com> wrote:
> I have a hardware platform that only have one serial port (COM1, a
> RS232 port) available, but I need to connect to two devices. The
> following diagram shows how A and application B want to talk to device
> Ad and device Bd respectively (over the single COM port).
>
> App A----
>             |                                |---- COM1A------ Device
> Ad
>             COM1---- SPLITTER----
>             |                                |---- COM1B------ Device
> Bd
> App B----
>
> So, I though of creating a small splitter device that would know how
> to split and combine data and send it to the right port. Meaning, data
> from AppA would end up on COM1A for device Ad and data from AppB would
> end up on COM1B for device Bd.
>
> I thought that to accomplish this I could prefix something to the
> message sent from each application which would act like a routing
> signal and the splitter would then look at it and send the message
> (minus the prefix) to the right port. Similarly, for data arriving
> over one of the split port, the splitter would add the prefix and send
> it back to the host, where it would again be looked at and routed to
> the correct application.
>
> I hope this was clear and not confusing!
>
> So...... my question is, is this a good way to accomplish this? Are
> their devices that do it? I did find references to "serial port
> splitters" but they were all for PC environment and all my devices are
> embedded boxes.
>
> Thanks for your inputs!

is there any other port like USB port or Parallel port or ethernet
port you can you use? if you go, they there is box to convert them to
RS232, this is simple way. if you dont, and your platform isn't
windows, you have to have the ability to pad the message from appA or
appB(for example, app was designed by your team), then definetely you
can design a box to do this conversion.

jet

"ElderUberGeek" <aribloch@gmail.com> wrote in message 
news:1173464501.163143.47600@t69g2000cwt.googlegroups.com...
>
> I have a hardware platform that only have one serial port (COM1, a
> RS232 port) available, but I need to connect to two devices. The
> following diagram shows how A and application B want to talk to device
> Ad and device Bd respectively (over the single COM port).
>
> App A----
>            |                                |---- COM1A------ Device
> Ad
>            COM1---- SPLITTER----
>            |                                |---- COM1B------ Device
> Bd
> App B----
>
> So, I though of creating a small splitter device that would know how
> to split and combine data and send it to the right port. Meaning, data
> from AppA would end up on COM1A for device Ad and data from AppB would
> end up on COM1B for device Bd.
>
> I thought that to accomplish this I could prefix something to the
> message sent from each application which would act like a routing
> signal and the splitter would then look at it and send the message
> (minus the prefix) to the right port. Similarly, for data arriving
> over one of the split port, the splitter would add the prefix and send
> it back to the host, where it would again be looked at and routed to
> the correct application.
>
> I hope this was clear and not confusing!
>
> So...... my question is, is this a good way to accomplish this? Are
> their devices that do it? I did find references to "serial port
> splitters" but they were all for PC environment and all my devices are
> embedded boxes.
>
> Thanks for your inputs!
>

There is a device called the RS-232 hub that works well for half duplex 
protocols like Modbus.  It has been used on oil and gas wells where two 
different devices that only had RS232 ports available need to share a radio. 
Commands come over the  radio and go to both PLC's.  When the one with the 
correct Modbus address responds, it goes out the radio and to the other PLC 
which again ignores it.

Basically the first port that talks is the master as long as it is talking 
and the other two are slaves until it stops.  Then the port that grabs it 
next is master while it talks.  It's easier than custom protocols or 
converting everything to RS485 and back again.

More info at

https://rawiq.com/store/


Mark Walsh

On Fri, 09 Mar 2007 11:36:33 -0800, Jim Stewart <jstewart@jkmicro.com>
wrote:

><snip>
> As you
>said, you'll have to have some sort of header
>or protocol so that you can send packets to
>the one peripheral that will be ignored by
>the other.
><snip>

I think the rest of your post was on-target, but this misses what I
think the OP implied...  that the two external devices probably aren't
software-modifiable.  If you read closely, the OP is talking about
some intermediate device that would accept headers and split off the
communication to the two devices, with the implication that the header
is removed in the process, I think.  The Tx going both ways will
probably be an issue, though it is probably fine from a hardware point
of view.

Jon

On Fri, 09 Mar 2007 22:14:24 GMT, Jonathan Kirwan
<jkirwan@easystreet.com> wrote:

>On Fri, 09 Mar 2007 11:36:33 -0800, Jim Stewart <jstewart@jkmicro.com>
>wrote:
>
>><snip>
>> As you
>>said, you'll have to have some sort of header
>>or protocol so that you can send packets to
>>the one peripheral that will be ignored by
>>the other.
>><snip>
>
>I think the rest of your post was on-target, but this misses what I
>think the OP implied...  that the two external devices probably aren't
>software-modifiable.  If you read closely, the OP is talking about
>some intermediate device that would accept headers and split off the
>communication to the two devices, with the implication that the header
>is removed in the process, I think.  The Tx going both ways will
>probably be an issue, though it is probably fine from a hardware point
>of view.

Just to make my point further, if it were possible for the OP to
modify the software in the devices, the OP could simply wire things
this way:

>                               +----------+
>                          ,----| rx       |
>  +--------------------+  |    |     DV1  |
>  |                 tx |--' ,--| tx       |
>  |  Application       |    |  +----------+
>  |      Box           |    |
>  |                 rx |--, |  +----------+
>  +--------------------+  | '--| rx       |
>                          |    |     DV2  |
>                          '----| tx       |
>                               +----------+

And simply have DV1 pass on to DV2 any messages it doesn't parse for
itself.

However, I don't think modifying the devices in on the table from what
I read.  This also means that MODBUS is out of the question, if I
gather this right.

Jon

On 9 Mar 2007 10:21:41 -0800, "ElderUberGeek" <aribloch@gmail.com>
wrote:

>
>I have a hardware platform that only have one serial port (COM1, a
>RS232 port) available, but I need to connect to two devices. The
>following diagram shows how A and application B want to talk to device
>Ad and device Bd respectively (over the single COM port).
>
>App A----
>            |                                |---- COM1A------ Device
>Ad
>            COM1---- SPLITTER----
>            |                                |---- COM1B------ Device
>Bd
>App B----
><snip>

I am assuming that you can modify the COM1 driver for your application
box but that you cannot modify the software on your two other devices,
there.

How many pins on the COM1 port are there, other than the obvious TX,
RX, and ground, that you can control from the COM1 driver software? Do
you have RTS, CTS, DTR, and/or DSR, with say one or two of these as
outputs you can set one way or another?  What speed?  Are both devices
at the same rate or can be set to the same rate?

Jon

On Fri, 09 Mar 2007 22:22:08 GMT, Jonathan Kirwan
<jkirwan@easystreet.com> wrote:

>...in on the table...

...is on the table...