How to get 4 UART on a MSP430?

Thanks a lot Brandon and Adrian,

I do not know why but I always ignored the 5th series from the MSP430!!!

I just had a long look yesterday, and they are really amazing MCU... 25 MHz, most have USB connectivity (except the ones I want), up to 8 USCI, DMA (unlike 2274)...

It would have been called a DSP a few years ago.

Hi Jens-Michael,

Thank you for the information. I have thought of communicating via SPI too. I started designing each slave board with an UART interface with the idea to communicate with the computer straight (MAX3232+uSB-2-Serial Converter). Now, for my project, I want a main MCU to control these slave boards. Therefore, my slave boards can not communicate via SPI.

I will have to stick with UART for now on. However, my next project will include SPI communication between MCUs!

I have ordered 5439/38 via Digikey for some testing. Thanks to the 4 UART on the module A, I will be able to keep on my design.

Hi Jens-Michael, I have an issue related to this post. I have three MSP430g2553 all connected via UART. At this point, the master sends an specific character (command) that will be identified by one of the slaves and the slave will reply with an specific character (response/data). Each slave has it own specific command and its specific response so that it can be ignored by the other slave. The problem I have is that no matter what I do, the master cannot receive data from any of the two slaves. 

The TX from the master is connected to each RX from the slaves, and the RX from the master is connected to each TX on the slaves. 

Thanks in advance for your help.

Andres Mora said:

the RX from the master is connected to each TX on the slaves. 

You'll have to put the TX pin of the slaves into high-impedance state (switch them from UART use to GPIO input) and only put them into TX mode for the time the slave is sending.

Thanks, Jens-Michael. 

I will try that.

Now, an additional question: are both slaves' TX going to be fighting each other even when only one slave is talking to the master at any given time? In our setup the slaves are sharing the "UART bus" but they never talk at the same time. The master however, does broadcast its messages/commands.

Thanks in advance!

Precautions:

To avoid the Master seeing ghosts during the time all slaves are in high-impedance, you need an external pull-up resister. An alternative is to enable internal pull-up when the slaves are in input GPIO mode and not in TX mode.

Also, need to make sure that the slaves finishes the TX transmission before it switches to input GPIO mode. That is, make sure that the TX buffer register is empty and the TX shift-register is finished sending all the bits out.

Andres Mora said:

.. are both slaves' TX going to be fighting each other even when only one slave is talking to the master at any given time? ...

TX is driven high when it is not actively transmitting. Thus it will fight with another TX trying to drive it low. TX is not designed to be used as a bus.

Thanks for help, old_cow_yellow!

In your previous comment, you said: "To avoid the Master seeing ghosts during the time all slaves are in high-impedance, you need an external pull-up resister." I agree with this, but wouldn't this resistor "emulate" the other slave's TX line?

Cheers.

Andres Mora said:

wouldn't this resistor "emulate" the other slave's TX line

Years ago, a TTL output driver was driving to GND strongly, but driving to VCC only weakly. In a direct 1:1 fight, the low-driving one would 'win'. So when connection two TX outputs with TTL drivers, teh idle one would drive to VCC less strong than the 'active' was pulling the line low. Also, a TTL input was slightly (very weakly) pulling the line towards VCC. Communication would have worked. (at the cost of relatively high cross-currents). Also, if both TX lines were inputs, the line would still be 'high' by the input pullups.

On the MSP, howeve,r the output pins have CMOS driver that are capable of driving multiple mA. And they are equally strong in both directions. Also, when switched to input, they go into high impedance, not pulling the line up at all. This is why you need to add a weak pullup. Sure, when one output speaks low, it has to fight the resistor. But with a 33k pullup, 100µA are coming from VCC, while the output pin can easily pull 100 times as much to GND. But when both TX pins are set to input, the 100µA (maximum) ensure that the line will be held high despite of any crosstalk, radio waves or other influences. So the receiver will not erratically detect any bits.

However, for a real bus with multiple peers, tehre are things like RS485. It is half-duplex (only one can speak at a time while all others listen). In case of two speaking, the drivers will produce cross-currets up to 50mA and the communication is distorted, btu they are designed to bear this.
With a driver chip like MAX485 for each peer, several peers can be connected. The only thing that needs to be added to the nortmal UART code is a por tpin that controls the direction: low while sending, and high otherwise. The peers then need to know when they can speak (or have to detect collisions).
We use RS485 with good results while connecting up to 5 MSPs through UART.

Thanks to both of you (Jens-Michael and old_cow_yellow). We fixed our problem by changing TX of the slaves to input when not talking to the Master and also using a pull-up resistor.

I have one more question. In our setup, besides the two MSP430g2553 that are work as slaves, we have an OpenLog SD card board (http://tinyurl.com/c4besmj) attached to the UART bus. The master has a sequence that starts turning on the SD card and then sending a CR to it and waiting for its response. After the master receives theOpenLog's reply it turns it off and then goes on to talk to the first MSP430 slave and then to the second slave. When all the slaves are connected to the UART and powered on (including the OpenLog), the master will not see anything coming from the OpenLog but it will receive the expected responses from the MSP430 slaves. However, just by turning off the two slaves, and without any changes in software nor hardware, the master receives the OpenLog's reply.

Any idea why this happens? Any idea on how to fix it?

What you need to look at is the  Address-Bit Multiprocessor Format mode of the USCI. This mode is used for "multi-drop" where you have multiple devices on a serial port. The data format is 9 bits with the 9th bit used to define address or data. This is the mode used for RS485 multidrop. All you would have to do is put some sort of tristate buffer on the TX line of each slave device and control the buffer based on a valid address detection.

Thanks for the suggestion Timothy. However, in this case I don't think your proposed solution will work.

Currently, we have successfully communicated between the master and the two other MSP430g2553 slaves even when having the OpenLog and the two slaves sharing the UART. Modifying the current transmission format to the address-bit multiprocessor format you suggest would most likely work if the OpenLog was attached to another MSP430. Unfortunately, we are directly connecting the OpenLog to the UART bus and since we don't have control over the transmission format of the OpenLog.

You can use any de-multiplexer IC which accept 2 input (Rx & Tx) and four output (Rx0,1,2,3 & Tx0,1,2,3). You can easily switch between slave by address pin available on IC (A0,1). I assume that you are working on half duplex mode (query based protocol), in that case any slave answer if it is ordered to do so. No collision, no need to use costly MCU!!!

Andres Mora said:

...

However, just by turning off the two slaves, and without any changes in software nor hardware, the master receives the OpenLog's reply. ..

Do you mean that you have two powerless slaves hanging on s weakly pulled up bus? Couldn't you just put the slaves in LPM5?

Hi old_cow_yellow,

   Perhaps I didn't explain myself. What I mean with "turning the slaves off" is simply leaving them connected to the UART with out the master talking to them. They are powered at all times. This was just as test condition. Thanks for your advice though.