This may have been discussed before, but I couldn't find anything by searching google, I may not have been using the right keywords.
Please give your thoughts on the attached communication situations:
Questions on my mind:
-How will the MAX232 act when it gets TX signal on the ROUT pin?
-How will the uC's act when TX signal from one uC is on the TX pin of the other uC?
Goals:
-Normally the top and bottom uC's should communicate, the top and RS232 should be able to communicate.
-The operating params able to be changed on the top uC via RS232.
-The operating params able to be changed on the bottom uC via RS232.
My third sch should solve this... As long as the questions above aren't an issue??
Both uC's use a completely different protocol(of waits and characters) to enter command mode.
I should note I can NOT change the firmware on the top or bottom uC, I CAN on the right and the RS232.
Idea in third sch:
When the correct command mode sequence is recognized by the right uC it can control the multiplexer to reprogram operating params on the bottom uC that were given to it by RS232. All other times it will work as stated in the goals.
Should mention the multiplexer chip will really be SN74LV4052A. I only used the one shown for an easy way to communicate my goal... Or a MAX399 but they are pricey.
I though of another way to do this. Please see the attached sch.
I should also mention I have already had the boards manufactured that hold the top uC and the MAX232. The bottom and right uC's will be on a board yet to be manufactured, connected to the original board with a jumper, with these pins. PWR-TX-RX-GND.
This solution uses serialsoft, and the MAX399 to isolate the communication when UC2(bottom) is talking to UC3(right).
You can't have two TX's connected, they will interfere with each other.
What you can do is add Serial.end(); after transmitting, and pinMode (TXpin, INPUT); so the pin is not interfering with the other transmitter. Not sure how you'd coordinate that, or if you have access to the right 328P's code to do that.
After that, hardware muxing makes sense.
Can do with 2 AND gates and an OR gate, and one NOR gate if you want just 1 select line:
The Serial.end();/pinmode would be an option. I will be writing the code on the right 328p for the sole purpose of being able to change operating params on the bottom uC. Thanks for the idea.
I see how the gates would work also, I have found a couple sch with that set-up. The problem I have now is that I already have the completed original boards so I cant add components... So when the right 328p is transmitting to the MAX232 I have no way to isolate the TX line of the top uC. I have read that adding a 4k7 pull-up resistor to the line might help with the issue??
Pullup will not help. The uCs will try and hold the level commanded in their respective output registers.
If one wants high, and one low, it will not turn out well.
If I were to have the original boards remade with two extra pins(tx, rx) in the header/board interconnect. Would the attached make sense for my objectives?
The bottom uC is actually a bluetooth module, on the new sub-board. The original board should run with or without the sub-board but I need to be able to change the params on the bluetooth module via UART.(this info may help understand what I'm trying to accomplish)
I may be better off just buying a BT that is capable of "overair" AT commands.....
Output from Rs232 can go to inputs on all 3 uCs.
Only 1 TX should be connecting to th RS232 input at a time.
How are you turning the top one off?
You need to control G on the LS157 so you can turn the bottom 2 off.
I think you've got the idea, just think thru the path of the signals some more.
This image looks messy but I hope it helps communicate my goal.
The GREEN arrows are UART paths that need to communicate.
The RED arrows show paths that don't need communication.
So output from RS232 doesn't need to get to the bottom uC.
Maybe I should look at taking the right 328p out of the picture again, but then I don't have programmable logic to control the gates... The second picture shows the talk paths without the 328p, I will check the datasheets and see if they have a "Enable" output pin for UART transmit..??..
The only time the Bluetooth needs to communicate with RS232 is to get AT commands for settings.
Otherwise RS232 needs to communicate with the top uC, for sending data or AT commands.
Top uC needs to send data via RS232 or Bluetooth if RS232 is not connected.
Bluetooth needs to be able to send the top uC AT commands and maybe data when not connected to RS232.
More or less im trying to have RS232 and bluetooth as forms of communication for the top Uc... The problem is RS232 could send a AT command to top uC changing the baud. So now there needs to be a way to change the BT to match...........
Programming the AT commands:
I wrote the windows app for sending the AT commands via RS232 so I can add the commands to change BT settings at the same time.
I also wrote the Android app for sending AT commands via BT. Can make changes there also.
I cant change the firmware on the top uC or the BT module.....
Bad thing is I will have to have the original boards remade or maybe able to add the components to the current boards.
The top uC has CTS for RS232 that can be reconfigured to be TX Enable for RS485 or RS422. I will use that line for a switch or gate to isolate the TX when its not transmitting.(black square) And when the bottom board isn't connected everything should still act normally...
I will program a pin on the right 328p to act the same way as above for a TX Enable...(black square)
The problem I now face is the MAX232's ROUT and bottom uC TX will be on the same line when the top uC and bottom are talking....(red boxes) Is there a chance that the ROUT wont interfere with the line?????
No chance of non-interference. RS232 does not have output enable, can't be turned off.
These are thru hole parts? You can straighten pins out, add parts dead-bug style and add wires.
Ugly, but gets the job done.
It's mostly smd... I will solder an ugly mess up for testing. The boards have other things going on as well so they are almost 5x5 inches.. not cheap to keep ordering prototypes lol
It looks like I will have to do a substantial rework of the main board. I really didn't want to add extra components to it because as I said some will be running without the BT sub-board. I was really hoping to not have the extra failure points. But as it looks pwr gnd tx rx are not going to be enough board interconnects.
Thanks for your advice. If you have any ideas on a good solution for the rework I would be glad to hear them I doubt the BT module will have TX enable output... I will read some more datasheets.
I doubt the BT module will have TX enable output... I will read some more datasheets.