PDA

View Full Version : Sharing Serial connection



DynamoBen
- 8th March 2006, 04:31
I have a situation where a PC and a PIC need to be able to send data to a serial (RS232) device.

When the PC is being used I want to disable the PIC from sending data. I have a switch right now that is a PC/PIC selector. (Might looking into sensing DTR latter) Basically it disables TX on the PIC when the PC is being used.

What is the best way to protect the TX pins on the PC and the PIC? I was thinking of just using some diodes on both TX pins to keep it simple. (RX should be a none issue) Is that OK or should I go with a mechanical disconnect like a relay?

Thoughts?

sougata
- 8th March 2006, 09:10
Hi,

When you are using a PC to PIC comm. you are necessarily using a software at the PC side. In its simple form there could be two situations :

1. Your PC side program is running.

2. Your PC side program is not running.

Situation1 : Your com port is open and cannot be used by any other prog. So no issues on the TX part.

Situation2 : Your PC app for the PIC is not running and you want to use another prog with another connection.So a TX from the other devices cause a conflict with your TX output.

Using the DTR is not a recommended option as there can usage of it by the other device.

At this moment what I can think of is a thru connection via your PIC module.

Use a Relay or CMOS switch to select one of the TX (either the PIC or the shared device). Depending on the priority you want you can sense activity on the other TX and switch from the PIC to it. Otherway round is to poll for a particular string on the RX line to enable the PIC TX or it is a thru of the other device.

Please ellaborate your PC-PIC and other device connections. Whether you are using a level translator or a simple resistor. Also which PIC you are using and the type of other device (PIC type or true RS232)

Regards

Sougata

Luciano
- 8th March 2006, 11:58
Hi,

Use the PIC to repeat the data. (Link through the PIC).
You will need a PIC with hardware UART + interrupt routine.

http://img8.picsplace.to/img8/10/pic_uart.JPG (http://picsplace.to/)

Best regards,

Luciano

sougata
- 8th March 2006, 13:38
Hi,

Luciano's solution can be best and economical. But it is hard to comment without a little more detail. So ben give us some more info.

Regards

Sougata

DynamoBen
- 8th March 2006, 18:14
That was one of my thoughts and I'm all for it. Here is where it gets sticky.

The software on the PC side is locked to com1 but I'm trying to interface with 2 serial devices with it. The original idea was to use a serial switch box and control each individually with the software.

The devices can be turned on/off remotely via serial. The request was to be able to turn both devices on/off on a day to day bases w/o the PC but they still want the ability to use the more advance PC software on occasion.

I'm trying to combine the functionality of the switch box with the automated control of the pic.

Keep in mind the protocol is a send and reply protocol which means the PC can't just send commands blindly to both devices.

Make sense?

sougata
- 9th March 2006, 10:49
Hi,

You can share the RXin (TXout of PC) from the PC to the PICs so that both of them listen to what the software is asking to do. So the objective is to prevent clash of TXout (Rxin of PC) line. If you are using two MAX232 on both the device then things get complicated. You already thought of the DTR line. So lets do it in this way.

1. Do not use individual MAX232

2. OR both the PICs TX output by a couple of 1N4148 diodes.

3. Use the ORed output to the TXin of the MAX Chip

4. Use the same ORed output to form some sort of bus activity signal to both the PICs.

5. Now in your software just before you transmit check for activity (at least one frame according to your baud rate)

6. If the line is active go idle for a few secs (or so according to your traffic and protocol).

So when one PIC is sending the other would just wait for the bus to become free (sort of inverse DTR)

Regards

Sougata

DynamoBen
- 9th March 2006, 19:07
Doing it this way is more work than its with. I'm going to take another route and eliminate the switcher and PC portion of the design. If they want to you the PC they will have to replug as needed.