Best way to communicate between microcontrollers

Question

I am looking for the best (cheapest, smallest, least wires) way of communicating from my Raspberry Pi, to numerous inputs/outputs a few meters away (wired). For example, I will have a temperature/humidity sensor, and multiple motors powering a small "greenhouse." I will have dozens of these mini setups, so I would like a way to communicate with these small houses, in order to get the temperature/humidity readings, and control the servos based off that.

My initial idea has been to use some smaller "slave" microcontroller within each system. This way, I can use some form of communication "I2C" maybe to send a message to the "slave" which in turn, controls the I/O's.

I was thinking either a PIC10 or ATtiny for the "slave," but not sure what the best choice would be, and the best form of communicating. (Additionally, I will probably throw on a shift register to each units output, so multiple "slave" I/O pins isn't necessary.

As I will be making dozens of units, I would like this to be as cheap as possible.

Answer 1

In my experience when you shoot for cheapest you often get the least reliability along with it. You should really consider using RS485 which is a simple two wire differential interface that is interfaced to the UARTs in your MCUs. When properly implemented the RS485 operates reliably over long distances and in noisy environments.

The two wires of RS485 operate half duplex so it is suited ideally for a control MCU querying and monitoring a batch of slave devices with MCUs. A simple addressing scheme allows for a single pair of wires to be daisy chained to a large number of stations.

Answer 2

Additionally, I will probably throw on a shift register to each units output, so multiple "slave" I/O pins isn't necessary.

So, don't do that, just buy a bigger microcontroller: Shift registers aren't free, and getting a GPIO pin makes everything easier.

cheapest, smallest, least wires

I'll take this as the priority list! We can't optimize for three objectives at the same time, so first optimize for cost, then size, then number of wires.

I think the honest truth is that cabling is, no matter how minimal you do it, always a bit of a hassle, and a source of cost. Sure, if you don't aim for the cheapest microcontroller, you could use USB, as any medium-sized MCU has that built in this day and age, and USB hubs are cheap as dirt "on the internets".

But you'd end up developing USB devices. Honestly, not that hard if you only need to do it once, but hm, also not trivial. This might incur more cost – eval boards, non-working designs…

So, that leaves you with a wireless solution. RF is easiest to find ready-made solution for – Joshua mentions ESP8266 and ESP32, which are two microcontrollers that do wifi, out of the box. That's neat – you don't need an extra microcontroller just to do a few simple control/readout jobs, and the internet has incredibly cheap boards that already do all you need. Literally 2 to 4€. Forget about your PIC. But you need to do Wifi, which is not very power-efficient.

A lot of companies have such RF microcontrollers, and a lot of them have other things than just wifi. For example, the very cheap (even at reputable distributors!) ESP32-C3-WROOM-02 has wifi and/or bluetooth 5 – and bluetooth low energy might just be the tool of choice. For $1.95 + VAT, you get a full microcontroller board, which you only need to supply with 3.3 V. Talking to it via bluetooth might be the easiest way, after putting on some example firmware.

You might get away even cheaper. If your slaves are in the same optical environment, i.e. they have a direct line of sight to the controller, or at least a path with few reflections, infrared communications is pretty mature.

You can buy 36 kHz "TV-remote" receivers, and directly generate the necessary bitstream from the RPi/Arduino …, as that's just manchester-encoded bits, multiplied with a 36 kHz rectangular wave, directly fed into an IR LED.

To save that cost, just connect an IR photodiode to a single transistor stage for amplication, followed by a ca. 40 kHz cutoff RC filter (for anti-aliasing). Connect it to your MCU's ADC, which you let sufficiently oversample at maybe 100 kHz and digitally bandpass-filter out the 36 kHz, which means you have minimal hardware effort, with only cheap components. You do need a microcontroller with an ADC, but as mentioned above, your approach of least-cost microcontroller + shift register is probably more costly than a medium-range microcontroller, once you incorporate the shift register, decoupling and board costs.

Another approach would of course be acoustics. You don't need high data rates at all, so beeping a piezo buzzer with maybe 200 bd on-off-keying (UART!), maybe even in the ultrasonic ranges, and receiving the same with a matching piezo disk, amplification and a direct feed into the UART RX of your receiver MCU might do the trick. Don't forget to include a checksum in your packets – otherwise, your receivers have no chance of telling noise from data. You would need to design your own medium access control, though. For very low-occurrence communications, Aloha with ACKs might do, for anything substantial, you'd probably want your central controller to explicitly query each sensor individually.

Answer 3

I would use an interface designed to do this, I2C, SPI etc are not designed for this type of application and will give you a lot of grief. Although not the cheapest but probably one of the most reliable is CAN. You can put it on arduinos etc for less then $5.00. Modules such as the MCP2515 come assembled with the driver and CAN controller chip. The controller does the handshaking etc for you so from a software point you mainly tell it to send something to somewhere and you receive data from somebody.

The packets etc are all identified. You can prioritize your devices by using a lower ID number. If you get faults it will retry until a maximum number of retries has been reached then it will notify you. It will run up to a million bits a second and can extend 4000' or more depending on baud. Cory Fowler has a great library on the Arduino exchange. Take the send and receive source files and put in two units. It is a SPI so there are four wires and an interrupt or pole your choice.

Answer 4

---

One idea

Why use wire at all. It doesn't sound like the distances are too great and there doesn't appear to be any need for bidirectional comms (see below) so, use an off-the-shelf radio transmit module and a small MCU to blindly transmit every now and then (based on it's address that is set via a DIL switch). A centralized receiver can then collect the data from all the slaves. Yes there will be collisions but these will be few and far between if you do the sums.

Below For controlling the motors, why not let the local MCU do that?

---

Or maybe

If that sounds too revolutionary, use powerline communications to avoid the extra wires for data.

Answer 5

I am looking for the best (cheapest, smallest, least wires) way of communicating from my Raspberry Pi, to numerous inputs/outputs a few meters away

No contest, just use an ESP32 or Pico-W to provide a WiFi connection at each node, so the only wiring you need is the power distribution, or you could battery-power the units individually, to avoid all wires.

These devices are remarkably cheap, and they will provide the shortest development time, since they come with a ready-made network API (socket interface), and you can find numerous examples of C or Python code that demonstrate how to simply transmit & receive sensor data over a TCP/IP network.

It may seem a bit crazy to use wireless over short distances, but I do think you'll find it much easier than the (wired) alternatives.

Answer 6

Modbus-TCP

How I would go about this would be to host a Modbus-TCP Server on your Raspberry-pi using Node-Red.

For each "slave" Micro-Controller I would use a ESP8266/ESP32 that can connect to your Wireless network and poll data from your Modbus Server hosted on your Raspberry-Pi.

You can then map your IO to the Registers or Coils you choose.

EG:

In this example I am using Reading and Writing of Coils You can also use holding Registers

Controller 1 :

Using Coil 1001 & 1002

1001 --> DQ01 //Write the value of Coil 1001 to DQ 01

1002 <-- DI01 //Write the value of DI 01 to Coil 1002

Controller 2 :

Using Coil 1003 & 1004

1003 --> DQ01 //Write the value of Coil 1003 to DQ 01

1004 <-- DI01 //Write the value of DI 01 to Coil 1004

For Analog Data you have to use Holding Registers and you can go about mapping the Data the same way.

Once all your mapping of Registers and Coils to physical IO has been done, you can now go about writing your Control Logic on ANY device within your Network that can interface with your Modbus-Server including your Raspberry-Pi.

You will be able to Read the state of your "slave" controllers Inputs by reading the Register/Coil you have mapped to its input and you will be able to turn on or off an output by writing to the Register/Coil you have mapped to the "slaves" output.

If you have never worked with Modbus before I recommend getting familiar with it first.

Here is a link to a Modbus Client and Modbus Server Simulator.

https://www.modbustools.com/download.html

Answer 7

What about I2C port expanders and I2C sensors with a slow clock and I2C buffers as needed?

You could even wire it as a true bus with a single pair of wires going in a ring through the little greenhouses. Depending on the spacing you could put an I2C port expander plus I2C buffer in each greenhouse.

The advantage here is that all the logic would be in the central Raspberry Pi and you don’t have to maintain any firmware on the "remote" hardware.

Answer 8

The solution I would go for is Raspberry Pico W. Communication over wireless network protects against electrical problems. Additionally you may program safety shut down in the local controllers. The Pico W is slightly more expensive than a smaller PIC type controller, but when you add in things like relays, power supply and case the relative difference is smaller.

Avoid long wires on I2C and similar outside casing as they might induce electrical noise. Worst case is when signal ground differs due to different power supply which easily can destroy your microprocessors.

Using known buffers, say for RS485, is a valid solution for protection against electrical issues but when you add up the costs a Pico W is often less costly.

Answer 9

If you're going to have "dozens" of these units, you really need to think about a network topology. Does a hub-and-spoke topology make sense? Perhaps a ring topology with units connected together in series? For instance, for these relatively low speeds, daisy chaining units in a system similar to the old token ring networks might make sense. You could use microcontrollers with dual serial ports to do that e.g. the PIC15324/44.

Maybe you want hubs with a microcontroller spoked to dumb sensors, so using a microcontroller with lots of GPIOs for the sensors and short runs to connect them.

All this depends on your particular geography.

Answer 10

It makes sense to have a slave controller in each house which gets temperature and humidity readings and controls servo motors.

Temperature and humidity sensors usually have 1-wire protocol or I2C or SPI. 1-wire can be long distance upto 40 or 50m but SPI and I2C are short range (5m or less). Be wary of that. 1-wire bus has to be implemented manually with software on most MCUs.

Servo motors are controlled with PWM signals. This has to be done with a dedicated MCU.

If you want to do additional things such as reading analog voltages,the same MCU can do that too.

You might want to have a 8 bit or 16 bit processor as a slave controller and a 16 processor as the master controller with features such as Rs-232, I2C, SPI,PWM. 16-bit processor for master controller is enough as there wont be enough CPU load either in master or slaves in your application. Your raspberry PI might suffice to be a master in the application.

Since you have several of these controllers connected to one master in your setup, if you want the design and development to be cheap, you can try RS-232 and if you can spend some money, Modbus. I think RS-232 will suffice if the distance is not so great and is less than 20 or 40 meters and you don't have strong electromagnetic fields near your setup.

You might want to have a setup like this:

Master <------------------------------------------------->

      Slave   Slave    Slave  Slave   Slave

Answer 11

You may find that wiring up a communication bus between devices is more of a hassle than using a wireless communication scheme.

One wireless communication option I would suggest is the nRF24L01+ transceiver module. They can easily be ordered for cheap from Amazon ($1-$2 for a pack of 10) and allow for both sending and receiving data using one peripheral. When compared to Wi-Fi, the nRF24L01+ would be lower cost and lower power, while still allowing you to have multiple devices able to talk to other devices on the same network. Additionally, they are very popular, and there are libraries all over the internet for interfacing with them.