Splitting a serial (RS232) port signal?

Started by ElderUberGeek March 9, 2007
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?productid460 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?cid81,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...
ElderUberGeek wrote:
> I went to sleep and when I woke up.... what a response! Thanks guys. > Well, I see I need to clarify a few things: > 1) I can modify the application in the "master" box (i.e. the one with > only a RS232 port). It is not PC based and I can only play with the > software, not the hardware obviously. > 2) In one of the peripherals, I can do basically what I like in both > software and type of interface (which is actually best to be Ethernet > but 485 could work also, just not 232 because a longer range is > needed) > 3) In the other peripheral, it is RS485 and no ability to change the > firmware > >
Since you can go RS485 on both peripherals, that is already multidrop. Use RS232/RS485 converter on master box and problem solved! However, if your device#2 (which you have no control over) does not support addressing, you may have little problem. Try to find something that device #2 will ignore and that will server as your protocol token for device #1. You still do not need micro. If there is nothing that device #2 would ignore (e.g it always ACKs or NACKs), then you may need help of external micro. Read what Ulf posted. Roman
"ElderUberGeek" <aribloch@gmail.com> skrev i meddelandet
news:1173493940.274968.249830@p10g2000cwp.googlegroups.com...
> > I went to sleep and when I woke up.... what a response! Thanks guys. > Well, I see I need to clarify a few things: > 1) I can modify the application in the "master" box (i.e. the one with > only a RS232 port). It is not PC based and I can only play with the > software, not the hardware obviously. > 2) In one of the peripherals, I can do basically what I like in both > software and type of interface (which is actually best to be Ethernet > but 485 could work also, just not 232 because a longer range is > needed) > 3) In the other peripheral, it is RS485 and no ability to change the > firmware > >
From what I have seen, you have RXD,TXD out from your H/W. Do you have any sideband signals like RTS/CTS etc? If not, you probably want to have a low cost micro. There is already a standardized protocol for this: GSM 07.10 This allows you to multiplex a number of UART streams on top of the single RS-232 port you have. If you take a micro with three UARTs like an AT91SAM7S321 you can connect the DBGU to your RS-232 port and the two standard UARTs with H/W RS-485 support to your peripherals. The ARM micro can decode the GSM 07.10 (Google to find the standard documents) and split it up into the two streams. By using the larger AT91SAM7X128/256 you can connect peripheral 2 with Ethernet. -- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
I went to sleep and when I woke up.... what a response! Thanks guys.
Well, I see I need to clarify a few things:
1) I can modify the application in the "master" box (i.e. the one with
only a RS232 port). It is not PC based and I can only play with the
software, not the hardware obviously.
2) In one of the peripherals, I can do basically what I like in both
software and type of interface (which is actually best to be Ethernet
but 485 could work also, just not 232 because a longer range is
needed)
3) In the other peripheral, it is RS485 and no ability to change the
firmware


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

>...in on the table...
...is on the table...
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: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 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
"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 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! >
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?cid81,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