About USART and USCI in MSP430

Thank you Bernhard weller for your reply and easy explanation of the different communication modules. I want to implement a RS-485 protocol in my MSP430FG4618/F2013 experimenter's board, so which module is the best and easy to implement. And is there is any limitation of implementation of RS-485 protocol.

Regards

Souvik

Sorry, I haven't done any RS485 projects, so I can't help you out there. Have you tried searching for RS485 here in the forum? There are quite a few posts around and also a lot of answers from Jens Michael.

My guess would be, as the communication is similar to RS232, you will need an external chip (MAX485 ?) and then you can use the USCI_A module in UART mode with additional software to implement the RS485 features.

But if you are going to implement this on the MSP430F2013 rather than the MSP430FG4618 then you will have to use a software UART as the USI module is not supporting UART.

But well have a look around the forum, there are certainly better answers around then my simple guesses.

One addition to Berhards info:

The USART does have I2C support. But while the USI I2C support is ratehr rudimentary (ultra-low-level, only slighlty above bit-banging), the USART I2C support is so high-level that it is barely usable because for small I2C jobs. It is fine if you have to write or read a large number of bytes (e.g. external memory access), but for jobs where you have to send a register number and read a register value, it is much, much too complex to be of any use. So I implemented my own bit-banging I2C code for the 1x family. The USCIs I2C, however, is easy to use and helpful for any kind of I2C connection.

souvik metia said:

I want to implement a RS-485 protocol in my MSP430FG4618/F2013 experimenter's board, so which module is the best and easy to implement.

There is, however, alarge difference: RS485 is half-duplex because both directions are transmitted over the same electrical lines, using a differential driver.
So the software needs sort of a handshaking mechanism to avoid mroe than one talking at the same time (resulting in a collision of the signals and the transmitte data is lost to the void).
The RS485 driver needs to be manually switched form sending to receiving (or you can leae receiving on all the time for a loopback/collision detection).

This means that you cannot simple send when you want. You'll need to enable the output driver, then send our data, wait for the last byte being sent completely including parity/stop bits, then disable the driver.
The driver is controlled completely by software using a normal GPIO port pin.

We use RS485 on our devices with 9600 and 38400Bd without problems. However, line termination is a critical thing on RS485. At one side, you need to pull the lines to 0V/5V, while on the end of the bus, the lines need to be shorted by e.g.470Ohms to avoid signal reflections. All peers except the one that pulls the lines high/low need to be more or less directly (some 10cm) attached to the main wire pair.
If you want to have a rather star-like connection scheme, things can get really nasty.

souvik metia said:

And is there is any limitation of implementation of RS-485 protocol.

Thank you Jens-michael Gross for your reply, actually i want to implement PROFIBUS protocol on my microcontroller board which is based on RS-485 communication based. So i just try to implement some RS-232 codes which are available by TI, but it still bit confusing to understand the code.

souvik metia said:

i just try to implement some RS-232 codes which are available by TI, but it still bit confusing to understand the code.