Arduino Nano Rev 3 as I2C slave and master

Hello everyone!

I would like to use an Arduino Nano (Rev 3) as a slave device for a STM32 MCU and then use the Arduino as master for a OLED Graphics Display. Is there any option to set an another communication line on this board other than A4 and A5?

Use another communication channel for the connection to the STM32 (p.e. SPI). A system where an Arduino is master and slave at the same time will never run reliably!

pylon:
Use another communication channel for the connection to the STM32 (p.e. SPI). A system where an Arduino is master and slave at the same time will never run reliably!

STM will address NANO as I2C Slave during which there will be no communication between NANO and OLED. While NANO will be communicating with OLED Slave using the same I2C Bus, there will be no communication between STM and NANO.

Based on the above propositipn, I have tested the following setup; where, MEGA requests NANO to send temperature signal of MPU6050 sensor over I2C Bus; MEGA receives the temperature and shows it on its Serial Monitor.

The communication looks like working for a while and then just halts - why? So, it does not work reliably as @pylon has observed. Is it possible to do something to make it reliable?
i2c-Mega.png

Sketch of MEGA:

#include<Wire.h>
char myTemp[6];
byte i;

void setup()
{
  Serial.begin(9600);
  Wire.begin();
  Wire.beginTransmission(0x20);
  byte busStatus = Wire.endTransmission();
  if (busStatus != 0)
  {
    Serial.print("Salve not found.");
  }
  Serial.println("Slave found.");
}

void loop()
{
  Wire.beginTransmission(0x20);
  Wire.write(0x13);
  Wire.endTransmission();
  //-----------------------
  Wire.requestFrom(0x20, 5);
  for (byte i = 0; i < 5; i++)
  {
    myTemp[i] = Wire.read();
  }
  myTemp[++i] = '\0';
  Serial.print("Received temp from MPU6050 via NANO: ");
  Serial.print(myTemp); Serial.println(" *C");
  delay(1000);    //test interval
}

Sketch of NANO:

#include<Wire.h>
#include <MPU6050.h> //device address 0x68 keyed in the library
MPU6050 mpu;
float temp;
volatile bool flag1 = false;

void setup()
{
  Serial.begin(9600);
  Wire.begin(0x20);
  Wire.onReceive(receiveEvent);
  Wire.onRequest(sendEvent);
  while (!mpu.begin(MPU6050_SCALE_2000DPS, MPU6050_RANGE_2G))
  {
    Serial.println("Could not find a valid MPU6050 sensor, check wiring!");
    while(1);
  }
  Serial.println("MPU6050 is initialized.");
}

void loop()
{
  if (flag1 == true)
  {
    Serial.println("Code recived.");
    mpuTemp();
    flag1 = false;
  }
}

void receiveEvent(int hoeMny)
{
  byte x = Wire.read();  //read the received byte
  if (x == 0x13)    //be sure that 0x0A is coming from MEGA
  {
    flag1  = true;
  }
}

void sendEvent()
{
  Wire.print(temp, 2);
}

void mpuTemp()
{
  temp = mpu.readTemperature();
  Serial.println(temp, 2);
}

Screenshot of MEGA:
smmega.png

i2c-Mega.png

smmega.png

STM will address NANO as I2C Slave during which there will be no communication between NANO and OLED. While NANO will be communicating with OLED Slave using the same I2C Bus, there will be no communication between STM and NANO.

How do you enforce that? Do you install two additional wires that the master or the slave may pull high to signal the bus usage? Without such extra hardware I repeat above statement: This will not run reliably.

This is doable however there is software and hardware overhead if the OLED Graphics Display is controlled with a multimaster and not on the I2C buss between microprocessors.
This is Directly from: MultiMaster - I2C Bus
"MultiMaster
There are I2C environments where multiple masters are driving the bus.
In such case each device needs to be able to cooperate with the fact that another device is currently talking and the bus is therefore busy.

This translates into:

a) Being able to follow arbitration logic. If two devices start to communicate at the same time the one writing more zeros to the bus (or the slower device) wins the arbitration and the other device immediately discontinues any operation on the bus.

b) Bus busy detection. Each device must detect an ongoing bus communication and must not interrupt it. This is achieved by recognizing traffic and waiting for a stop condition to appear before starting to talk on the bus.

If you plan to use a multimaster device on a bus it is essential that all masters are multimasters. A single-master is simply a device, which does not understand the above mechanisms. If a singlemaster and a multimaster are connected, the singlemaster may well interrupt the multimaster causing unpredictable results."
Good Luck & Have Fun!
Gil

The Wire library does not support bus arbitration (yet).