• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 3828 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

UART multiplexing

Markus Nemitz
Prodigy 120 points
Other Parts Discussed in Thread: MSP430G2553

Hi all,

I have a really annoying issue with some UART multiplexing. Here the initial situation:

I would like to let a MSP430G2553 communicate with up to eight UART parties. Therefore I multiplex the RX and TX line through a multiplexer each, using GPIO pin voltages to control the multiplexer accordingly. Lets assume that my multiplexer work -> I have eight UART (RX,TX,GND) interfaces. Here comes the tricky bit: Lets just think about one other party connected to one of the eight multiplexed connections. This party has also two multiplexer and also eight UART interfaces. How can I now ensure that both both x553 uC interact with each other? I tried to make the one uC faster than the other in terms of multiplexing the signal. 

Right now I try to let them establish some connection by sending single signs to kind of verify a uC-uC communication.

if(Serial.available()>0){

incomingRequest=Serial.read();
if(incomingRequest==100){...

I guess that the UART realization with having two different overall times multiplexing the RX/TX connections of a uC, is to complicated and you guys will probably recommend to think about some other communication. Anyway I am happy about every comment. I added as attachment a picture of the conceptional idea.

Best,

M.

  • 0
    TI__Guru 56650 points

    Hi M,

    I am not sure that I 100% understand the problem, but anyway I think you were asking how to enable both sides choose the same channel so that they can communicate with each other. 

    If this is the case, my idea is to switch the RX pins of each sides to a normal GPIO input pin and sense each channel state. The UART line is pulled up if idle, if you are attached pull down resistor on each RX multiplexer pins, only the one connected with the TX shall be in high state.

  • 0
    Guru 46710 points

    Markus Nemitz said:
    I guess that the UART realization with having two different overall times multiplexing the RX/TX connections of a uC, is to complicated and you guys will probably recommend to think about some other communication.

    Problem is not that complicated at all. Supposedly TX and RX muxes of single party are addressed same way? If so then both parties shall continuously send some escape character, and obviosuly are ready to receive. One party switches MUX after each 2 (no less) escape chars, another switches slower (2 up to NUM_LINES slower). Sooner or later one party will receive char so it can stay on particular MUX "address" and send escape chars into discovered  line continuously so other party can find connected line in next pass

  • 0
    Guru 227245 points

    In addition to Ilmars’ suggestion: you only need one multiplexer per peer. On its RX line. So it can listen to one of the other peers. It always talks to all who want to listen. Its TX is connected to one input of the other peer’s multiplexers.

    Unless, of course, you want to allow any two peers to talk with each other at any time. So with 8 peers, you could have 4 connections active simultaneously. Then you need a real crossbar switch. Or two multiplexers per peer and the risk of two talking to the same at the same time.

    If you don’t need full duplex operation, you might want to take a look at RS485. It is not only built to withstand rough conditions and long lines, but also needs only two wires for up to 128 peers. However, some sort of time-slice (equal peers) or polling (one master, n slaves) mechanism is required. RS485 is a bit more complex than simple UART (code-wise), as you need to handle direction switching. However, it is reliable.

    Or you go for a bus system like I2C, that is natively supported by most MSPs.

**Attention** This is a public forum