4
\$\begingroup\$

I am planning on building a system with one master and multiple slaves using MSP430 microcontrollers. The microcontrollers must talk with each other with serial interface using RS-485. I now need to decide how the messaging should be implemented. The microcontrollers are several meters apart and there must be a possibility for atleast 20 slaves. The slaves need to be able to send messages back to the master.

The current implementation is made using a single UART. Slaves can only send messages after they have received a message from the master. The system has an additional non standard polling signal (on/off) which tells other devices that the line is busy. This is non-standard and an awful way, but without it the system can't know if it is safe to send messages.

I am new to this area and i dont really know about the options? I have read about DMX512, but it can only send messages from the master. There are things like MODBUS, LIN, SMBUS, I2C etc. which can message to multiple devices, but are they what I am looking for?

Is the best solution to use CAN bus using MC2515 microchip? Or should I use two UARTS in one RJ45 cable where one is from master to slaves and another one is from slaves to master so I could pass a token between the slaves?

In general what kind of protocol should I be looking into? I would like the system to be as flexible as possible.

\$\endgroup\$
4
  • 2
    \$\begingroup\$ First you say that you must use RS485, then you ask about some other interfaces. If you must use RS485, you pretty much answered your own question. \$\endgroup\$
    – Klas-Kenny
    Commented Feb 29 at 14:57
  • 2
    \$\begingroup\$ I don't understand how there can be collisions if there's only one master, and a slave can only respond when asked to by that master. \$\endgroup\$
    – Simon Fitch
    Commented Feb 29 at 15:01
  • 1
    \$\begingroup\$ Not a recommendation, but DMX has an "Extension" called RDM which provides some amount of bidirectional communication. \$\endgroup\$
    – brhans
    Commented Feb 29 at 20:15
  • 1
    \$\begingroup\$ You should make these decisions during the design phase, long before you've picked MCU. Using CAN without built-in controllers is to be avoided. Apart from that, CAN would be more suitable than RS485 because of the bus arbitration feature. Using RS485 means you have to use a dedicated master and some manner of "ping pong" protocol with lots of overhead. \$\endgroup\$
    – Lundin
    Commented Mar 1 at 13:33

4 Answers 4

Reset to default
5
\$\begingroup\$

You can use UART with RS-485 physical interface. This is a bog-standard use for it.

It allows for half-duplex comms.

It also allows for more than 20 devices using standard transceivers. More if you use transceivers that are half-loads or quarter-load, etc.

Also you are mistaken, DMX-512 adds RDM support to send messages back from device to controller. It does not even use any weird busy signal. You send a messsage requesting a response, and then listen to some other transmitting the response, or continue if there is no response.

So contrary to the other suggestions, you do not need to switch to CAN as physical interface instead of RS-485, and you don't need to switch the bit-serial protocol to CAN instead of UART, and you don't need to switch away from the MSP430 to something else.

If you really want something CAN-alike as the physical interface, you can simulate dominant and recessive states on RS-485 bus too, by setting transmit data as '0' and sending data by using the transmit enable to send '0' or disabling it to let bus float at idle '1'.

\$\endgroup\$
5
\$\begingroup\$

Your "I want a mature multi-user bus with safe access methods and several meters of reach" really says "CAN".

Usually, these days, you'd simply pick a microcontroller that inherently has a CAN controller built in. I don't know whether the MSP430 series has such. But the MSP430 series is a bit of a special-purpose series of microcontrollers: It's heavily optimized for low power consumption, but I don't see how that optimization helps you with microcontrollers spread out this far which still are cabled up – this is not a really power-constrained application!

So, I'd probably look into more feature-rich microcontrollers that do have a CAN peripheral. The ATSAMC21 series has microcontrollers that integrate CAN, for example, and I prefer programming these cores much over programming MSP430. If you want to stay with TI microcontrollers fro some reason, the MSPM0G3 series also has members with CAN interfaces (but I have zero experience with them).

Note that even if you decide you want to stick with your MSP430 MCU: using a separate MCU to handle the CAN bus communication is still cheaper than the MCP2515!

\$\endgroup\$
2
  • \$\begingroup\$ Usually RS-485 has been used before CAN was available and if it is not available in currently selected MCU. CAN PHY could still be used with UART. \$\endgroup\$
    – Justme
    Commented Feb 29 at 15:59
  • \$\begingroup\$ true, but I really wonder why this is happening on an MSP430, as my answer stresses; not like CAN or RS-485 wouldn't need serious current even at idle. \$\endgroup\$
    – Marcus Müller
    Commented Feb 29 at 16:06
3
\$\begingroup\$

CAN bus offers the features you are looking for out of the box.
Unfortunately your MSP430 doesn't offer CAN bus.

Brainstorm:
You could also create a RS-485 bus with collision detect using half-duplex tranceivers. Software wise you would need to develop CSMA/CD and check if what you sent was put on the bus correctly by reading it back. (Like CAN bus does)

SN65HVD888
SN65HVD888

In short summary:
Your UART will always be in loopback mode through the transceiver.
Each byte sent will also be received when DE is enabled.
If it doesn't match, there was a transmit error and you should try again after a psuedorandom time. (let the other node speak)

\$\endgroup\$
3
  • 1
    \$\begingroup\$ You don't need to use CAN protocol and CAN physical interface simultaneously. You can use UART over CAN PHY. And you don't need collision detection, simply collision avoidance. Ask one device to send a response and wait for it, no other device sends a response. The listeners don't necessarily detect collision so they can't know what happened, only the two colliding transmitters can know it and then what would they do, send their responses again? Better not allow two senders. Also there is one master and multiple slaves so there can not be any collisions to begin with, if one slave talks. \$\endgroup\$
    – Justme
    Commented Feb 29 at 15:10
  • \$\begingroup\$ @Justme The problem with UART is that everything will have to go through a master, or otherwise some manner of "time slice" or "token passing" design where nodes get to speak up at certain points. It can be done for sure, but it is needlessly cumbersome. Also I think having no collision detection is unfortunate for UART, in case some node does not behave. It might perhaps override the various (blunt) error handling mechanisms of UART like overrun/framing errors. Also you'll have to implement and calculate checksum manually. And MSP430 is far from the quickest kid on the block. \$\endgroup\$
    – Lundin
    Commented Mar 1 at 13:42
  • 1
    \$\begingroup\$ My very personal opinion, having working with field buses more or less constantly for the past 20 years: CAN is bliss and UART is old, clunky, error-prone and annoying in general. But then I know CAN well and the learning curve for CAN is admittedly much steeper than for UART. \$\endgroup\$
    – Lundin
    Commented Mar 1 at 13:47
0
\$\begingroup\$

Some MSP430s have LINbus, which is a master-slave protocol targeted to vehicles. The LINbus, or Local Interconnect Network, is a less expensive network designed to work with CAN. It has a speed of about 19.2Kb/s and has 1 master and up to 16 slaves (requiring no bus arbitration), and is designed to work on top of a CAN backbone network, according to the Wikipedia article. I know that you need 20 slaves, and I don't know how one MSP430 can host two LINbus networks, but that's what I would try, though I have no experience with such.

\$\endgroup\$
4
  • 1
    \$\begingroup\$ Isn't LIN almost same as UART? In some MCUs the UART can be put into LIN mode which handles some parts of the protocol in hardware, but nothing prevents from doing that with UART and a bit of software handling (at least the break reception). \$\endgroup\$
    – Justme
    Commented Mar 1 at 15:25
  • \$\begingroup\$ @Justme Yeah, LIN is basically UART with some media access control on top. I have never seen it running on top of CAN (which doesn't mean it can't be done, I guess), but hardware support for LIN-on-CAN will definitely be much less widely available than LIN itself. \$\endgroup\$
    – TooTea
    Commented Mar 1 at 16:38
  • \$\begingroup\$ @TooTea -- So you've used LIN? Do you know what's the solution for 20 slaves would be without a CAN backbone? \$\endgroup\$
    – MicroservicesOnDDD
    Commented Mar 3 at 4:26
  • \$\begingroup\$ Re-reading your answer, I guess I just misunderstood what you meant by "on top of CAN". I thought that was about transporting LIN messages somehow over a CAN physical layer, but now I guess that's not what you meant. Looks like in automotive (which I know nothing about) a common combination is to use CAN for longer-distance communication between individual units, and then LIN for local communication within each of those units. I have very little experience with LIN, I have only used it in a hobby project with minimal requirements (a few MCUs, short distance, negligible bandwidth). \$\endgroup\$
    – TooTea
    Commented Mar 4 at 9:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.