msp430 rs485 multiplex communication

Started by Burak_aB 5 years ago6 replieslatest reply 5 years ago259 views
Hi all,
I wanna do rs485 communication with msp430 . This communication will be more than 2 connections. So , I need to use an addressable code for this. Will this address be in the uart configuration or It is enough to send only with the data ? and also what should we apply to not conflict the data ? Do you have sample code that this topic?
[ - ]
Reply by Tim WescottMarch 11, 2017

First, you can do whatever you want with the addressing scheme, as long as the hardware and software supports it.

Second, if your hardware supports it, it's handy in such systems to use 9 data bits, with the MSB used as an address flag bit.  Some UART hardware supports this, by letting you set a mode where the UART sleeps unless it either sees the flag bit, or if it sees the flag bit with the right address -- but this varies from chip to chip, so you have to go shopping for microcontrollers that support what you want.

For controllers that don't support this, some support using "fixed parity", i.e., the parity bit can be set hard on or hard off, and there is various levels of hardware support for interrupting on a "parity error" when there's a mismatch.  Again, it's a matter of shopping for the right hardware.

You can always use an 8-bit protocol with a deterministic packet structure, with the address embedded in the leading bytes of the packet.  The downside to this is that in order to maintain synchronization you have to process every packet, which loads down the processor on all your nodes, even if you don't care about the messages.  Again, some UART hardware supports "break detection", where a long period of all ones or all zeros (been a long time, I can't remember which), followed by activity, will make the UART wake up.  And again, this varies by UART hardware, so you need to go shopping.

It's been a long time since I've worked on systems that used this so I may not be remembering the keywords correctly, but search on "fieldbus" -- I think that's the name of the common industrial protocol that used this scheme before it became common to just use Ethernet.

[ - ]
Reply by Tim WescottMarch 11, 2017

I just glanced at the "MSP430x2xx Family User’s Guide" from TI.  It looks like this family of MSP430's, at least, supports both 9-bit data (they call it "Address - Bit Multiprocessor Format") and break detection (they call it "Idle-Line Multiprocessor Format").

Note that just because one family of MSP430's supports these there's no guarantee that others do -- you always have to look at the data on the specific chip that you're planning on using, and see if it has whatever mojo you need for your application.

Note, too, that when you do RS-485 stuff, the UART hardware may or may not support the enable line for transmit.  In the best circumstance, the UART will automatically enable the transmitter for a whole message, removing the enable when the message is done.  In the worst circumstance, the UART won't have such support, but it will have a built-in FIFO with no interrupt on transmit FIFO empty, or worse, no way at all for the software to know when it is empty.  Again, close and careful reading of the data sheet is to be recommended, and possibly even early prototyping.

[ - ]
Reply by Burak_aBMarch 12, 2017

I use msp430f5325 and this support feature that "Address - Bit Multiprocessor Format"

Will my code be the same as  Rs232 uart configuring ? but will I just send the address value to the first part to be sent? I did not find any relevant sample code. I mean I need to write a protocol like hand-shake protocol and my configuration like rs232 configuration and ı just send adres and data in sending data. And I want to see the data from the computer, and we need the c # program which is the option I can choose to have an address .There is no such example on the internet . just , There are programs showing uart output.

[ - ]
Reply by Tim WescottMarch 13, 2017

This is not the sort of thing that is rich in example code on the Internet.  You'll have to start from desired behavior and go from there.

Most of the code will be the same as if you're using RS-232.

Try doing a web search on "half-duplex serial protocols" -- hopefully useful information will pop up.

[ - ]
Reply by SpiderKennyMarch 13, 2017

You don't say what you are communicating with, but if you are writing the code which runs on all your devices connected to RS485, then you are in control.

Sending the address byte as the first byte is a perfectly sensible idea. BUt take into consideration such things as : i)How often will you be sending data? ii)What if one of the 'receivers' misses the first byte? How future proof do you want it to be?

I do a lot of RS485 work. What I've always done is transmit a header byte, then a pair of address bytes, then the payload, then a terminator. For example a command for an amp to set it's input-channel on my systems would look like this: $01SC01\n

The receiver can throw away all bytes until is receives the '$' thus ensuring that it is starting from the beginning of a transmission. It can then read the next two bytes and it these match it's address then read the rest up till the terminator, if not simply discard everything again until the next '$'.

Remember with RS485 you need a GPIO line to enable the transmitter. Avoid holding the trsnamitter enabled for any longer than necessary - ie release it as soon as the last 'bit' has been physically transmitted.

If this is your first foray into RS485 and you don't need any more advanced adressing then you might not have to start messing with 9-bit mode.

[ - ]
Reply by antedeluvianMarch 14, 2017

The Modbus protocol is 1/2 duplex and can run on RS232 or RS485 (or in fact on TCP/IP as well nowadays). It is really old, but there is quite a bit of documentation out there including implementations on the PIC, and PSoC (I know, I wrote that one myself) and there is quite likely one on the MSP430- just google it. It may provide you with enough structured information to allow you to proceed.

The Modbus protocol specification is in the public domain and can be found at