Uart physical connection

This is not a "Make the Switch to MCU Success Story" - is it?

RS232 connections (the typical UART usage) are 1:1 connections. No master and slave, but two peers who communicate with each other. It is possible to have one peer to send to several peers at once, but it cannot receive from several peers

Going RS485, the UART connection is turned into a BUS structure (requireing special transmitters. There is no dedicated receive and send dirction on RS485. One is sending and the others are listening. And when two are sending at the same tiime, nobody will understand what is sent. It requires additional programming for handling the direction (needs to be controlled by GPIO) and for synchronizing all peers.

The multiprocessor format in teh USCI module is an additional support layer you can use on an RS485 connection (so incoming data can be filtered by hardware so you only have to answer packets ment for you), but it still requires the software handling of the hardware direction-switching. On a normal RS232, it is pretty much useless (unless you only have one sender and all others are just receivers and don't send anything ever)

If you want a simple bus system with a master and several slaves, use I2C or SPI instead. These are fully supported by the USCI hardware. For the master, SPI is easiest, btu if you have to implement the slaves too, I2C is much less demanding. Also, for multiple slaves, I2C doesn't require additional select lines. It is slower and has more protocol overhead to handle, though.

Depends on the UART you are using and the signal line length, the signal integrity and noise immunity, it is possible to connect more than two of them directly in multiprocessor mode. In this case, level shifting to RS485 is not necessary, and to RS232 is not desirable.

Your physical connection is correct. Your problem is probably caused by incorrect firmware.

The TXD pin of all slaves are physically connected together (wire-OR) to go to the RXD pin of the master. But at most one of the slaves should actively drive its TXD at any given time.

The TXD pin of the master is connected to the RXD pin of all the slaves. Using multiprocessor protocol, the master sands an address to selects one of the slaves. The addressed slave (and only the addressed slave) enables its TXD to actively respond to the master. All the other slaves sit on the side line listening to the master waiting to see its own address.

If you still have problems and need help, you should tell us what uP device and what UART you are using.

I use MSP430FG4618 (Experimental board kit) as Master device and MSPf2274 (EZ430rf2500) as Slave devices. How i can disable TXs pins at the all Slaves that are listener? Tx and Rx pins are located at P 3.4 (Tx) and P3.5 (Rx) .  When I try to disconnect through P3SEL = 0x20; the Rx line is working. When is created response I enable Tx through  P3SEL = 0x30; but Master device doesn't receive anything, interrupt is not generated. Maybe it is necessary to reset (Initialize USCI state machine -  UCA0CTL1 &= ~UCSWRST; ) or to make a short pause? Another question is if I can disable Tx direct from interrupt procedure (when is receiving address of slave) or it is necessary to exit from interrupts, enable Tx and after this to response (Acknowledge) at Master device?

I use UART multiprocessor mode with address bit,  and 9600 baudrate.

Thank you very much for your answer!

Regards

Alexei

I find the problem. Master device doesn't receive the message because Slave device, direct after command UCA0TXBUF=xxxxxx; disable Tx, and Tx buffer was not able to transmit. I make a small delay between transmission and Tx disconnection, and it's working properly. I have only one question relevant time of delay. I try to read if Tx buffer is empty with - while (!(IFG2&UCA0TXIFG));

But without delay, it doesn't work properly. 

Thank you in advance.

After Tx buffer is empty, an additional delay of a few "bit-time" is probably needed for the transmitter to finish the address-bit,  parity-bit, stop-bit(s), etc.

Try using the UCBUSY flag in the UCA0STAT register. I once had a problem using the USCI TX and RX flags and resolved it using the busy flag, although that sometimes meant to do a dummy read of the RX register to clear the flag again.