Good MCU-MCU Protocol to use?

Status
Not open for further replies.

ksafin

Member
Hey all,

Currently working on developing a few boards that necessarily need to communicate to one another.

I can go into depth if anyone is curious, but I think a general image should suffice for getting your input -- we have one "main" board that does a lot of important data gathering from sensors, GPS, etc, and a few auxiliary boards that do a number of other things off the critical path.

We've been trying to determine the best way to establish robust communication between multiple MCU boards -- our first thought was CAN, which we are still looking into as of now but having problems with libraries (I'm sure we can sort it out, but wanted to post here in case someone thought CAN was totally the wrong way to go).

You can imagine we have 5 Teensy 3.2's among several boards, and those Teensy's all need to communicate somehow. Ideally, auxiliary boards can request data from the main board, receive it, act on it, and repeat.

CAN seemed like a good way to have this sort of communication. Another approach would be to have a bottom-up serial chain where the master MCU talks to the secondary MCU, which then could talk to both the master and the next auxiliary, etc, meaning master needs 1 Serial port, second board needs 2, third needs two, so on, until the last board which needs 1. Then commands can be send up from the bottom board to the top, and data send back down the chain. This seems unnecessarily complicated, however, and also is limited by the number of serial ports available on each board.

Any suggestions? If CAN is the best way, that'd be great -- if you all have other ideas we'd love to hear them.

Thanks!
 
I've not worked with the CAN bus so I can't speak to that but you could use SPI with the master being the SPI master and the rest SPI slaves, plus one additional line from each slave to the master so they can signal when they need to send data (or just periodically poll all slaves).

You didn't say how much data you need to send back and forth, but another option would be to use the 2 hardware serial ports on the master to talk to 2 of the clients, and the SoftwareSerial library to talk to the rest.
 
I've not worked with the CAN bus so I can't speak to that but you could use SPI with the master being the SPI master and the rest SPI slaves, plus one additional line from each slave to the master so they can signal when they need to send data (or just periodically poll all slaves).

You didn't say how much data you need to send back and forth, but another option would be to use the 2 hardware serial ports on the master to talk to 2 of the clients, and the SoftwareSerial library to talk to the rest.

Thanks or the reply!

We don't have to send too much data back and forth -- on each iteration of the main control loop (on the main board) we'd probably want to send down... lets say something along the lines of 5-6 8-bit ints and a float or two. This is just a guess, but you can imagine it won't be more than 2-3x that at most.

The reason we've been avoiding master-slave option is because we are hoping to find some good Master-Master option; although we know we could poll slaves or have then pull lines to indicate readiness, the former sounds like it'll take up more time on the main controller than it should, and the latter might make use of pins we don't have.

For the latter option you mentioned, maybe it's just us, but we recently were attempting SWS and had it not work -- and from what we read on the forum there was some mention of SWS for Teensy 3.2 being some sort of wrapper for the HWS and true SWS not being an actual option.
 
Looks like you're right about software serial, 4 is the limit:

https://forum.pjrc.com/threads/32563-teensy-3-2-software-serial?p=94014&viewfull=1#post94014

From what you say about wanting to avoid master-slave then CAN might be an option. For that small amount of data, however, it would be pretty simple to roll your own protocol. Here's an example based on I2C:

https://www.hackster.io/chipmc/arduino-i2c-multi-master-approach-why-and-how-93f638

Interesting -- we can definitely do that; we're also honestly trying to avoid software complexity by favoring hardware options with more software support (like CAN)
 
Another approach would be to have a bottom-up serial chain where the master MCU talks to the secondary MCU, which then could talk to both the master and the next auxiliary, etc, meaning master needs 1 Serial port, second board needs 2, third needs two, so on, until the last board which needs 1. Then commands can be send up from the bottom board to the top, and data send back down the chain. This seems unnecessarily complicated, however, and also is limited by the number of serial ports available on each board.
This is overly complicated indeed. Unless there is some specific need for daisy chaining you are better of using a multi-drop bus like RS-485. This way every slave only needs one UART, but is in stead identified by a (on the bus) unique address. Hardware support for RS-485 is built-in to TD, and there are many implementations to use such a bus, from something minimal to a full Modbus protocol. You can also easily implement something your own (I did it for a project where Modbus would be overkill).
 
From what you've said so far, personally I'd be looking at either I2C or CAN. Would need to know more about the project to weigh up the pros and cons though.

In any case you do need to think about addressing. I.e. how will you assign addresses for the different modules/information packets.
 
What sort of distances are you communicating over?
You mentioned the amount of data in each loop, but how often are you expecting this data to be transmitted? (what's you actual average expected data-rate?)
 
Hardware support for RS-485 is built-in to TD, and there are many implementations to use such a bus, from something minimal to a full Modbus protocol. You can also easily implement something your own (I did it for a project where Modbus would be overkill).

@Epyon, I'm pretty ignorant about RS-485. But your comments about it here and in other threads has caught my interest. I will do the learning but would you be so kind as to mention a few of the implementations suitable for the ARM based Teensies? And, specifically, you said

Hardware support for RS-485 is built-in to TD ...
Would you supply a bit more detail? Do you mean that there is a RS-485 library? I just scanned the list of Teensyduino libraries here but didn't find one that I could identify.
 
@Epyon, I'm pretty ignorant about RS-485. But your comments about it here and in other threads has caught my interest. I will do the learning but would you be so kind as to mention a few of the implementations suitable for the ARM based Teensies? And, specifically, you said

Would you supply a bit more detail? Do you mean that there is a RS-485 library? I just scanned the list of Teensyduino libraries here but didn't find one that I could identify.

Ok, I learned a lot just by reading this thread.
 
Would you supply a bit more detail? Do you mean that there is a RS-485 library? I just scanned the list of Teensyduino libraries here but didn't find one that I could identify.
Scroll down to Serial1.transmitterEnable(pin) on this page :) .

RS-485 is not the magic solution for everything, but thanks to the simplicity of Arduino Serial and the Teensy FIFO buffers on UART, it is very easily integrated for reliably communicating small data packets between multiple devices, even over long distances. If you need long, continuous transfers over (very) short distances, you're better of investigating SPI or even DMA transfers.
 
Status
Not open for further replies.
Back
Top