Splitting a serial (RS232) port signal?

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

"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

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