1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Splitting a serial (RS232) port signal?

Discussion in 'Embedded' started by ElderUberGeek, Mar 9, 2007.

  1. 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
    COM1---- SPLITTER----
    | |---- COM1B------ Device
    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, Mar 9, 2007
    1. Advertisements

  2. ElderUberGeek

    Jim Stewart Guest

    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?
    Jim Stewart, Mar 9, 2007
    1. Advertisements

  3. ElderUberGeek

    Don McKenzie Guest

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

    can you add a uart?


    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.

    No More Damn Spam: http://www.wizard-of-oz.com
    Don McKenzie, Mar 9, 2007
  4. 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:


    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 queisser, Mar 9, 2007
  5. ElderUberGeek

    jetq88 Guest

    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.

    jetq88, Mar 9, 2007
  6. ElderUberGeek

    Mark Walsh Guest

    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


    Mark Walsh
    Mark Walsh, Mar 9, 2007
  7. 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.

    Jonathan Kirwan, Mar 9, 2007
  8. 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:
    And simply have DV1 pass on to DV2 any messages it doesn't parse for

    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.

    Jonathan Kirwan, Mar 9, 2007
  9. 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,

    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?

    Jonathan Kirwan, Mar 9, 2007
  10. ....is on the table...
    Jonathan Kirwan, Mar 9, 2007
  11. 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
    3) In the other peripheral, it is RS485 and no ability to change the
    ElderUberGeek, Mar 10, 2007
  12. 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.
    Ulf Samuelsson, Mar 13, 2007
  13. ElderUberGeek

    Roman Guest

    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, Mar 15, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.