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
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?
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
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.
Bookmarks