> 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
Reply by Ulf Samuelsson●March 13, 20072007-03-13
"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
Reply by ElderUberGeek●March 9, 20072007-03-09
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
Reply by Jonathan Kirwan●March 9, 20072007-03-09
On Fri, 09 Mar 2007 22:22:08 GMT, Jonathan Kirwan
<jkirwan@easystreet.com> wrote:
>...in on the table...
...is on the table...
Reply by Jonathan Kirwan●March 9, 20072007-03-09
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
Reply by Jonathan Kirwan●March 9, 20072007-03-09
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:
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
Reply by Jonathan Kirwan●March 9, 20072007-03-09
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
Reply by Mark Walsh●March 9, 20072007-03-09
"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
Reply by jetq88●March 9, 20072007-03-09
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
Reply by andrew queisser●March 9, 20072007-03-09
"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