I2C master-master communication

thomnik · 2022-02-01T12:21:39.749Z

Hi, I want to communicate between two Arduino's DUE with I2C, so both have to be master. I read a lot that this was difficult, but I also read that it was easy to install, for example with de following code:

#include <Wire.h>

void setup() {
 Serial.begin(9600);
 Wire.begin(1);
 Wire.onReceive(receiveI2C);
}

void loop() {
 delay(100);
 Wire.beginTransmission(2);
 Wire.write("hello world from 1 to 2");
 Wire.endTransmission();
}

void receiveI2C(int howMany) {
 while (Wire.available() > 0) {
  char c = Wire.read();
  Serial.print(c);
 }
 Serial.println();
}

This is the code for both Arduino's, I just switch the addresses. If I run this, I want it to print out "Hello" from Arduino 1 to Arduino 2 via I2C and vice versa, but it does not print it on the serial monitor. Also if I plug in the logic analyzer it does not trigger on a rising or falling edge and if I run a I2C scanner script it triggers one time and then it says "unknown error". Does someone know if it is doable and if so how I can fix this?

GolamMostafa · 2022-02-01T12:31:30.817Z

If you say that you want communicate between Master and Slave using I2C Bus , then the communication is possible. Both DUEs cannot work as Masters on the I2C Bus at the same time.

DUE-1 is Master when DUE-2 is Slave. When DUE-2 is Master then DUE-1 is Slave.

thomnik · 2022-02-01T12:49:03.640Z

Ok that is clear. Is it possible to switch master and slave in the same code or do I have to reupload the code in order to switch master and slave?

DrDiettrich · 2022-02-01T12:58:42.524Z

thomnik:

if I run a I2C scanner script it triggers one time and then it says "unknown error".

The other station should not send anything while scanning. Remove the code in its loop().

Also use I2C addresses above 8.

GolamMostafa · 2022-02-01T13:12:16.235Z

thomnik:

Is it possible to switch master and slave in the same code or do I have to reupload the code in order to switch master and slave?

You can do through some hardware handshaking; but, is it really needed? You can complete full data exchange in a single Master-Slave network

DrDiettrich · 2022-02-01T13:23:41.836Z

thomnik:

Ok that is clear.

No, it's not clear.

An I2C device becomes master as soon as it begins a transmission. If multiple devices try to transmit at the same time only one of them is finally accepted (arbitration), the others must retry later. At any other time all I2C devices behave as slaves, waiting for some input.

thomnik · 2022-02-01T14:40:43.280Z

I think it is needed, I will tell a little bit more what I want to achieve. I want to build a system connected in a 3 by 3 matrix form (later expand this to 5 by 5 or even bigger), each node is then an Arduino and every Arduino has to send and receive data. So for example I want to send data from Arduino 1 to the last one in the matrix, Arduino 9. It has to do this in the shortest path available and if a connection between Arduino's is not available the system has to rearrange and it has to take another route to Arduino 9. I already made a simulation in Python and wanted to test my findings with Arduino's, because they are versatile and quite "easy" to program. I thought that I2C was a good option, because I think that every node has to send and receive data. The picture maybe gives a better idea of what I am talking about.

Arduino overzicht1586×1022 312 KB

I think that I have to reconsider the communication protocol, if you have any suggestions please let me know.

DrDiettrich · 2022-02-01T14:52:26.129Z

thomnik:

The picture maybe gives a better idea of what I am talking about.

Do you really want to use multiple I2C buses?
In an ordinary I2C bus you can send a message from master1 directly to slave9.

Koepel · 2022-02-02T03:27:21.610Z

Sorry to spoil the fun, but that will never work. The I2C bus is not that kind of bus.
Even with two Due boards, it will not work reliable, not even when one is the Master and the other the Slave.

The Teensy 4.0 board and the Teensy 4.1 board have many Serial ports (with RX and TX). That should work for your project.

If you use a I2C bus or Serial bus, don't forget that the GND wire is part of the bus. The GND wire is actually the most important wire.

An other solution is to run everything on a single board and use tasks with queues between the tasks instead of wires.
It is possible to have 9 displays, so each task can control some output.
There are libraries for some kind of multitasking on a Arduino Uno. The Arduino scheduler works on the Arduino Zero, the MKR Zero and other boards. The Mbed/rtos (Raspberry Pi Pico) and FreeRTOS (ESP32) are preemtive multitasking systems.

The Wokwi simulator can not run multiple boards yet, but it can simulate the Mbed/rtos (Raspberry Pi Pico) and FreeRTOS (ESP32) multitasking systems.

The RadioHead library has a routing/mesh possibility for transceivers.

thomnik · 2022-02-02T09:35:10.407Z

Thank you for your answer, but why it will never work? If every Arduino is configured as a master in theory it should work right? And why it doesn't work reliable with two Arduinos?

I will check the other solutions you provided!

Koepel · 2022-02-02T12:42:07.459Z

Don't get me started ! O, wait, you just did. Well, I will try very hard to restrain myself.

The software for the Arduino Due is no longer maintained by the Arduino Team, they focus on newer boards. That does not mean that the Due software is good and finished. The Due has troubles. No one should buy a Arduino Due board.
The Arduino Due has 1k or 1k5 onboard pullup resistors for the first I2C bus. If you connect two boards, then there is already too much pullup. The I2C standard allows a maximum sink current of 3mA (the current to pull a signal low). You should know everything about pullup resistors for the I2C bus if you are going to connect many devices.
If you do everything wrong, then the maximum length is about 20 cm for the I2C bus. If you do everything right, then it is 2 meters or more. You may assume that at this moment you do everything wrong. The 20 cm is the total length. That means with 10 boards, there can only be 10 wires of 2 cm each.
The onReceive handler (your receiveI2C function) runs in a interrupt. You should not process data in that function and only use Serial functions during testing, unless you try to use the SerialUSB port, that might crash the Arduino board.
The I2C bus is slow. The Wire.requestFrom() and Wire.endTransmission() wait until the I2C session has completely finished. That means that every board could be waiting 95% of the time. Just waiting, doing nothing. With Serial communication, no one waits.
I have never seen a reliable Multi-Master I2C bus with Arduino boards. I often say that it is a fairy tale. It does not exist yet. If you are smarter than everyone else, then you can spend many hours to make it, and I can see problems in just a few minutes. Only less experienced people try a Multi-Master bus, the advanced programmers stay away from it. That is for a good reason. The reliability of a project should not be compromised by something that has no guarantees that it will work well.
In your sketch, you do not show even the most basic check for a collision. You should check the return value of Wire.requestFrom() and Wire.endTransmission(). If there was a problem, you have to do a retry. That retry mechanism will fail in software with more than two Arduino boards (for example because they are all 95% of the time waiting). With only two boards, you should fully trust that the Arduino Wire library handles the collision correctly in all situations. I'm not sure about that.
I often say: "The I2C bus is not that kind of bus". I assume that you don't know that SDA should not be next to SCL and that SDA and SCL have no meaning without GND. Perhaps you are going to make a number of mistakes with just the wires.
The picture with the 9 boards shows four I2C buses for the board in the middle. The Arduino Due has only two I2C buses. Are you going to connect them all to the same I2C bus ? So everyone can talk to everyone ? That is way more complex than the goal of your project.

thomnik · 2022-02-02T13:16:59.508Z

Thanks a lot for the detailed answer, this helps a lot! I have to consider other options, thanks again!

DrDiettrich · 2022-02-02T15:17:02.089Z

Koepel:

The I2C bus is slow. The Wire.requestFrom() and Wire.endTransmission() wait until the I2C session has completely finished. That means that every board could be waiting 95% of the time

Did you really understand the implementation?

Both these methods do the entire transfer so that a controller is waiting only when it transmits data and only as long as the transfer takes.

And what's wrong with a controller is waiting (idle) for 95% of the time if there is nothing else to do?

Koepel:

The Arduino Due has 1k or 1k5 onboard pullup resistors

I accept your criticism concerning the Due, the rest IMO is up to the expertise of the project manager.

Koepel · 2022-02-02T18:45:08.662Z

@DrDiettrich If I say something wrong, I expect you to correct me, but you don't have to tell me how the Wire library works I will write a few things here, but that is only a part of the problems that I see.

If the Due board has nothing else to do, then the waiting is no problem. But then a Arduino Uno is just as fast.
The Due has two I2C buses, if both are used, then the waiting can be a problem.

When I visualize what is going on and compare that with Serial communication, the difference is very big. A sketch that uses Serial communication reads a byte from one stream, sends a byte to another stream, and so on. The interrupts take care of the rest and no one is waiting.

DrDiettrich:

the rest IMO is up to the expertise of the project manager

I just keep bluntly saying that a Multi-Master I2C bus with Arduino boards is a fairy tale, until someone proves me otherwise. If has seen all the efforts, with extra wires, and complex code for the retries. The more complex it becomes, the more things I see that can go wrong.
If someone should make a reliable Multi-Master I2C library, it could be me. But I stay away from it as far as I can.

DrDiettrich · 2022-02-02T20:16:11.065Z

Koepel:

The Due has two I2C buses, if both are used, then the waiting can be a problem.

I don't see a problem even with two buses. The master does not have to wait except for proper transmission, the slave handles the data transfer in asynchronous callbacks.

Koepel · 2022-02-02T20:33:47.501Z

With two buses and waiting, the Master can send data to one, then send data to the other and so on. In between data could be incoming. My feeling tells me that if the Master can not get rid of the data soon enough, it becomes clogged.

Suppose data is incoming that has to be passed on to Slave 1, but the Master has still some data for Slave 2 that is send first. That means some buffering is required. Add a layer on top of that with retries, and the buffering is out of control. Extra code is needed to keep things in control. That complexity will not make it better. I see dark clouds and hail storms and Due boards in heavy seas.

I guess I see different things that you

jremington · 2022-02-02T20:36:55.327Z

thomnik:

I want to build a system connected in a 3 by 3 matrix form (later expand this to 5 by 5 or even bigger), each node is then an Arduino and every Arduino has to send and receive data.

Use RS485 for that. RS485 serial adapters are available for Arduino. See RS-485 Serial Interface Explained | CUI Devices

I2C is for chip to chip communications on a single PCB.

DrDiettrich · 2022-02-02T21:06:49.244Z

Koepel:

My feeling tells me that if the Master can not get rid of the data soon enough, it becomes clogged.

That master can not receive faster than send, so a lockup is unlikely. Which other serial hardware will perform better than I2C?

Koepel:

I guess I see different things that you

Right. The Wire library buffers input and output so that output can be repeated after a conflict and input can be handled in an asynchronous callback.

We have not enough information about the actual project and don't know what can and what can not happen.

system · 2022-08-01T21:07:47.266Z

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.