# Routing one UART Tx output to multiple UART Rx using MOSFET

I have a very cost effective MCU that only contains one UART which can only be mapped to one set of pins. I am not willing to change the MCU choice. I also do not need to use the Rx on that MCU.

I was hoping to use the UART and a GPIO to send that Tx signal to multiple devices. This is a single input multiple output situation.

There are a few ways I can think of doing this so I'll list them out here:

1. Use two MOSFETs and two GPIOs to control them. I can't think of how to use one GPIO with two MOSFETs but this is the preferred solution.
2. Use a 2-1 MUX with the 1 connected to UART Tx. My hesitation is that for some reason I think the 2-1 will stop signals from flowing backward?

If anyone has advice I would appreciate it.

• Why not just send it to both simultaneously - will this cause a problem with the reciever chips if they get the wrong message? – Andy aka Feb 14 '18 at 17:37
• Reads like you only have two target MCU receivers. If so and if your UARTs support 9-bit mode, you could assess letting both receive the data and having each ignore incoming 9-bit words with the wrong MSB. If you've more than two target MCUs, 9-bit UARTs often have hardware support for an address-or-data flag in the MSB so only addressed targets get the following data bytes. – TonyM Feb 14 '18 at 21:55
• That's a great idea @TonyM, maybe I will implement it for future projects. I am unfortunately constrained on the output payload at this point in the project. – jb1681 Feb 15 '18 at 18:54
• Can you just bit-bang one of the channels, preferably whichever you talk to less? – Chris Stratton Feb 15 '18 at 19:09
• @jb1681 I updated my answer, thought I'd let you know. – Harry Svensson Feb 15 '18 at 19:47

You can make something that behaves like transmission gates by putting two MOSFET's together in series, this also works for high power routing.

Here is one schematic utilizing that concept.

• The upper graph = A, the pin that will mux the input
• The second graph = input, the data to be muxed
• The third graph = the output at top right, input & A
• The fourth graph = the output at bottom right, input & A'

A' means not(A).
$V_{GS}$ means gate to source voltage.
$V_{GS(TH)}$ means Threshold voltage of the gate to source.

Notice how there are diodes in parallel with the MOSFET's, I added them there in the simulator because they are there in real life, they are called body diodes.

If you think you can only use one MOSFET, then you will realize that the body diode will mess things up and conduct when you don't want it to conduct.

The good thing about using P-MOSFET's, is because their body diodes are pointing towards the source. This means that the first instant the input goes high, then the body diode of the left P-MOSFET will conduct and bring the source high which in turn will decrease $V_{GS}$, which in turn will make both P-MOSFET's conduct as much as they can which will result in a low resistance connection.

The negative part about this solution is that when the UART signal goes low, the input in my schematic, then the output of the mux only goes down to to the $-V_{GS(TH)}$ of the P-MOSFET's. So if you are using P-MOSFET's with $V_{GS(TH)}=-1.5\text{ V}$, then your output will go as low as 1.5 V. If whatever you are talking to can understand that 1.5 V is a logic low, then that's great. If whatever you are talking to is extremely picky, then you can add a 1 kΩ pull down resistor at the output, which I have done in the schematic. Because in reality there are parasitic capacitances everywhere, and there is one across the input of whatever you are talking to, and it is that capacitor that I am trying to drain from 1.5 V to 0 V.

Oh, didn't expect you to accept this answer. In that case I'll add some extra information thanks to TonyM's comment to the other answer.

Don't hook the 1 kΩ resistors to ground like I did in the schematic above. Hook them up to $V_{DD}$, or if you can, use the internal pull-ups of your MCU if your MCU supports it.

And then hope that whatever you are talking to understands that the threshold voltage of your mosfet = logic low. AO3402 + AO3401 got about +-1 V threshold voltage, I think 1 V counts as a logic low. Not 100% sure, check your specific datasheet for your MCU.

## Actually...

Just use this one, this solution doesn't load your communication pin and the output goes from 0 to 5 V. This solution is better for signals, the schematic above is better for routing actual power, like driving motors or other stuff.

Here's the link if you want to mess around.

This is a better solution than my previous one, if that wasn't clear.

If you want the output to be low when idle, then use this design. It's the same as the schematic just above this text, but instead of putting the MOSFET's on the output in series, you put them in parallel.

Click here to see what I mean, I'm too lazy to fix the image + this answer will then have 3 different circuits = LOL.

• Will the new answer get me a better or worse low voltage? From the simulation it looks like the low voltage is 141 mV which should be plenty low enough. – jb1681 Feb 16 '18 at 20:30
• @jb1681 The new answer will get much better for the low voltage. It should get really close to 0 V, like a couple of mV as you saw in the simulator. In the real world you might have some stronger MOSFET's => low will be like 1 mV instead of 141 mV. If you got a MOSFET with a $R_{D(ON)}$ of ~ 100 mΩ, then you will have a 1 mV low output. – Harry Svensson Feb 16 '18 at 20:34
• I found my problem. I need both lines to be low when UART is not transmitting. Another weird part of my design. Luckily your first answer should be perfect for that? – jb1681 Feb 16 '18 at 21:28
• @jb1681 I updated my answer, the first schematic I made might load your communication pin too much => not good. The second is good for signals and if you want high when idle, now I made a third with a link that is the same as the second schematic, with the difference that it goes low when idle. It will make sure that whatever you are not talking to will go low. However I can't speak for what the UART will do to the one you are actually talking to. As far as I'm aware, as TonyM said to the other answer rings a lot of truth. When idle UART goes high. – Harry Svensson Feb 16 '18 at 21:37
• That's exactly what I want! Luckily my receiver is expecting this situation. You've saved me here! – jb1681 Feb 16 '18 at 21:52

The trouble with mosfets is the un-enabled output will float while you want to hold it low. You could use two 2-1 multiplexers to keep that line low. But what you really want is something with hard logical outputs.

I'm not sure what you mean by "signals from flowing backward". When a mosfet gate is open, nothing flows ether way. I did a little searching but didn't find a small form device off hand like you would want. What MU device are you using? 3.3 volts? I'll update this if need be.

Update: And as Andy aka points out. If it were me and I could program the receivers, I would use an addressing scheme on the transmission if needed. This means less hardware which is usually preferable.

Another Update: It has been a while. I checked for the MSP430 UART which I use most often. HIGH is the idle state as TonyM points out and probably the same for your device. So if you went with hardware you would have to deal with that using an OR wired device.

• UARTs transmit and receive logic high when inactive, I'm afraid, not logic low. It needs OR gates instead of AND gates between the master Tx and slave Rx's. Downvoting until corrected. – TonyM Feb 14 '18 at 22:09
• @TonyM FYI, it turns out that OP actually got low voltage as idle. So it's not like regular UART. So it's unfair to thumb down this answer now when this new information has come to light. – Harry Svensson Feb 18 '18 at 5:35
• @HarrySvensson the belief that the system idles low is dubious; if true, it suggests that these would not be logic level signals, but rather RS232 or similar, after the traditional inversion of the line/driver receiver. If it's actually the RS232 signalling which needs to be demuxed, that changes the question a bit from the assumed one everyone has been addressing. – Chris Stratton Sep 17 '20 at 15:36

My diagram for mux one uart to two slaves. If slaves just answers to master, possible to separate it with diodes instead of transistors

Personally, I would probably use a 74HC138 in this situation. You can feed the serial data into the active-low enable pin, and the serial data will appear on only one of the eight outputs. The unselected outputs remain high. You select which output you want to route to by the three address inputs.

A second solution would be to connect a resistor in between the TX pin and each receiver. Then, connect each receiver input directly to a GPIO pin. By setting the appropriate GPIO pin high, you force the receiver input high and stop it from receiving data. By setting the GPIO pin to an input, you allow data to go through to the receiver. You need to carefully select the resistor value. If the receivers have internal pull-ups, it needs to be low enough value to give you a good logic low level. But it also needs to be high enough to avoid exceeding the total sink/source capability of the TX and GPIO pins.

A third solution would be to dynamically reconfigure the UART pin assignments to route it to the desired output pin. Some MCUs have this feature, but there may be caveats to switching it at run time. Check the datasheet very carefully.

Finally the fourth solution as already suggested is to forget the UART and use an interrupt to bit bang the serial out of the desired GPIO pin.

The first option is probably the most robust solution and needs fewer GPIO pins. But the fourth option is also very reliable providing the timing of your application allows for it. Of course with any of the solutions you need to be certain that you've finished transmitting data before attempting to switch to the next receiver. Some MCUs give you a "transmit shifting finished" bit which you can poll. But unfortunately, some MCUs don't expose this to you - they only give you a transmit buffer empty bit. The buffer can be empty while a byte is still being shifted out. Workarounds include using a timer to calculate when the byte is projected to have finished transmitting, or looping the UART TX pin back to the RX pin - when you receive a byte, you know it's finished transmitting.

• The 74HC138 is too pricey for this application unfortunately, the third solution isn't possible with this MCU, and bit banging is something I really wanted to avoid. The second solution seems pretty reckless to me. Even if it works, it leaves a bad taste in my mouth. – jb1681 Feb 16 '18 at 20:15
• A 74HC138 is too expensive but a fancy MCU with an on-chip UART isn't? I'd have thought something like a 16F54 would be really "low end" or lower still a 4-bit MCU like those from Seiko Epson or Renesas. None of those have UARTs or even interrupts, you need to bit bang everything. Is it a very high-volume product? I wouldn't worry too much about the resistor solution. Just check the datasheet carefully for source/sink current and pullup resistance range. It should be perfectly reliable if you do that. If you can't afford logic, resistors are about the only cheaper thing. Or a custom ASIC? – Foxie Feb 17 '18 at 0:07
• @jb1681 a 74HC138 costs 10 cents, probably less than the BOM diversity introduced by an FET solution unless you already have those parts in your BOM. Now the space might cost you something, but that's why I suggested bit-banging the extra output. – Chris Stratton Sep 17 '20 at 15:32