Sharing a Serial output (logic level) to one device at a time.
RobotWorkshop
Posts: 2,307
I have a legacy device (Handyboard) with only one Serial port (logic level) that needs to talk to two separate serial devices. One of the target devices is going to be an SX48 based controller. Since there isn't any special protocol (like the appmod) one one device can listen in at once. I only need to transmit to each device and am not concerned with receiving any serial data back from them. My thought was to use something like a 4066 and an 74HC14 chip to handle the switching. With that I could have the Serial out goto the inputs on two of the 4066 switches and then use one of the inverter gates on the 74HC14 so that when the select line toggles only one will be active at once. I expect I may need some pull ups/downs but it should work.
Has anyone else had to do something similar and if so what did you use?
Robert
Post Edited (RobotWorkshop) : 12/7/2007 5:33:55 PM GMT
Has anyone else had to do something similar and if so what did you use?
Robert
Post Edited (RobotWorkshop) : 12/7/2007 5:33:55 PM GMT
Comments
The "legacy device" ?
The SX48 could probably handle the switching (instead of using the 4066 & 74HC14).
You could either receive and re-send to the other device, or use the comparitor to enable/disable the serial stream reaching the other device.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My goal is to live forever...Or die trying.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·
The legacy device is an older 68hc11 based system (Handyboard) with a single serial port. I can easily send whatever I want to the serial port and it can easily control a digital I/O port which it can use to specify what serial device should be hearing what it has to say. Adding an extra UART or trying to bit bang out the Serial data on another line would be much more complicated that just toggling an I/O line high or low to select the target device. I had thought about just sending everything to the SX48 and let it forward on things not meant for it but the way things are falling into place it may be easier to keep everything on the host. Besides, I think this may come up again and want to get this working as an alternate method of sharing a port. It should also work for sharing other things too.
So, the Serial out from the host would go to pins 1 and 3 on the 4066, Pin 2 (4066) would go to the Serial in on target device #1, Pin 4 (4066) would go to the Serial in on target device #2 (sx48 in this case). One digital line from the host would go pin 13 on the 4066. That same control line would be connected to one of the inverters on a 74HC14 and then goto pin 5 on the 4066. In theory it should only let the host talk to one of the serial target devices and the other will hear nothing.
This post isn't about if the Serial port should be shared in this example. That's not the point. It is more of a question that if it does need to be done, what is the best way to share the line and are there better choices than using a 4066 chip. I've seen some examples on using a 74hc157 so that the host could selectively listen to two separate target devices but that was the opposite of what I wanted to do.
Anyway, if you know of any examples or urls that may reference something like this or have any suggestions let me know.
Best Regards,
Robert
Post Edited (RobotWorkshop) : 12/7/2007 5:34:26 PM GMT
It sounds like your approach should work. If you like it, use it! There are other methods to accomplish the same result. Spending much time trying to identify the “best” method is probably not worth the effort.
If my recollection is correct, I have created a similar signal-sharing scheme with a single quad-NAND-gate chip. However, unless board space or shaving pennies off of the final cost is of great concern I would not say it is significantly better than what you have proposed.
I understand your desire not to want to code another UART. If you find it easier for your control signal to come from someplace other than the SX, a hardware solution seems like a good option. However, if you can allow the SX to handle the control of the serial port, Bean’s suggestion to use the built-in comparator is elegant in its simplicity! Basically, he is suggesting using the comparator as a switch that either passes or blocks the serial data stream to the 680x controller.
To accomplish this just use resistors to feed a 2.5V reference signal to one input of the comparator. The output will simply reflect whether the serial signal into the other input is above or below the reference signal. It will therefore copy (or invert, depending on the configuration) the serial signal from the input to the output. When you no longer want the serial signal to pass, simply disable the comparator and set the output pin to the appropriate state. It should be very simple.
Of course, you still have to know when to switch the serial signal!
- Sparks
I'm going to have to go back to the pullup resistors but have to figure out why the SpeakJet seems to get the data ok yet the SX48 always receives 255. Either that or look at a whole different method for sharing out a single serial (output only) port to multiple devices. I'm going to review the whole thing again and double check all the wiring but perhaps someone will notice something I may have missed.
After doing a couple searches online I found a link with an example but it is a bit more than I need:
www.netadmintools.com/art40.html
This one has a good example at the bottom but unfortunately it is the opposite direction...
www.freewebs.com/maheshwankhede/rs232.html
A couple chips that might work that I just found is:
www.onsemi.com/pub/Collateral/NLAS1053-D.PDF
or
www.onsemi.com/pub/Collateral/NL7SZ19-D.PDF
I'd like to see if the original circuit using the 4066 can work as it will save a lot of re-wiring on the protoboard.
If you have any suggestions i'd appreciate it.
Robert
Post Edited (RobotWorkshop) : 12/8/2007 3:35:18 PM GMT
The only issue (which isn't a problem) is that the SX48 is ready to start working so fast that it is up and ready to receive data before the main board comes up. Whenever the HandyBoard is reset it sees a single glitch on the line which Jon's Interrupt based Serial code sees as a start bit. The remaining bits are all high and this byte is always a 255. In all the testing done so far this happens during power up or a reset of the HandyBoard. All the other odd behavior and random garbage that would occational appear is now gone.
At first I was thinking about adding a flag to the Serial ISR on the SX48 to disable it when first powered up and then after a slight delay enable the ISR via the flag. That wouldn't fix any of the 255 character sent if the HandyBoard was reset after a powerup. Since the first byte sent to the SX48 should always be some sort of command (not a 255) the invaild character will just get discarded. With that I don't have to add the flag to disable the ISR and it also gets around the issue of the odd character being sent if the HandyBoard is reset.
Now I can finally get working on the rest of the SX48 program and keep going on the rest of the project.
Robert
On my latest board, I use a dual 4x1 multiplexer CD4052 to share·SPI and serial devices.
The X channel is used as input to read one of 4 outputs, the Y channel is used
as output to send a signal to one of 4 inputs. The Yn pins have all pullups, as has the X pin.
In addition, there are 1k series resistors in front of the X and Y pin (so Ron has little to no effect).
The two select inputs A and B are connected to my SDA and SCL lines.
This means, when I need to select a device, I must first lower SCL, then set SDA and SCL.
Before using the the I2C bus, I must set the Y pin high, because with I2C the·channels are selected
randomly, but due to the high·Y, and the pulups on Yn pins, the devices consistently only see
a high input. This works very well.
regards peter