It is my understanding that the SDA and SCL lines in the I2C protocol are open-drain, meaning that there is a transistor that pulls the lines LOW, but pull-up resistors are required to pull HIGH. It is also my understanding that the lines must not be actively pulled HIGH by the master or slave devices, because that would essentially cause a short-circuit between the transistor that is actively pulling HIGH, and the transistor that is actively pulling LOW.

This library implements the SoftwareI2C::sdaSet() and SoftwareI2C::sclSet() methods using a digitalWrite(), which would cause the microcontroller to actively pull HIGH if ucDta is HIGH. The use of digitalWrite(pin, HIGH) does not seem right.

The SDA line is a bidirectional line. When the master is sending data to the slave, the master sends 8 bits, then on the 9th bit, the slave sends the ACK (LOW)/NACK (HIGH) bit. If there is a bug in the software, or something goes wrong in the logic circuit on the slave, it may be possible for the master to pull the line HIGH at the same time as the slave device is pulling LOW for the ACK. If this causes more than 20-40 mA of current to flow, for a long enough time, then I think this could cause damage to the either the master or the slave device.

Almost every software I2C library that I have examined (8-10 of them so far) uses a digitalWrite(pin, LOW) for active LOW, but a pinMode(pin, INPUT) to transition into high impedance mode, which then relies on the pull-up resistor for the passive HIGH condition. I have found 2 exceptions: this library and one other.

Anyway, if your engineers say that this is not a problem, then I will have learned something new. Thanks for your consideration.

Scenario 1:

MCU1: ATMega328p
I2C Role: Master
Library used: Arduino_Software_I2C
Receiving 1 byte of data from slave (id 10).

MCU2: ATMega328p
I2C Role: Slave (Slave id: 10)
Library used: Standard Wire.h library
Sending 1 byte of data to master on request. Printing sent data to Serial monitor.

Result: Most of the cases received wrong/partial data at the master end.

Scenario 2:

MCU1: ATMega328p
I2C Role: Master
Library used: Standard Wire.h library
Receiving 1 byte of data from slave (id 10).

MCU2: ATMega328p
I2C Role: Slave (Slave id: 10)
Library used: Standard Wire.h library
Sending 1 byte of data to master on request. Printing sent data to Serial monitor.

Result: Always receive correct data at the master end

Probable issue: Bit receiving time-stretching due to heavy load at the slave end.

Slave Code:

#include <Wire.h>
void setup()
{
Serial.begin(9600);
Wire.begin(10);
Wire.onRequest(requestEvent);
}

void loop() {}

void requestEvent() {
byte x= B01010101;
Wire.write(x);
LED(x); //Dummy load at the slave end
}

void LED(byte x) //Dummy load at the slave end
{
pinMode(13,OUTPUT);
for(int i=0; i<8;i++)
{
bool a=digitalRead(13);
digitalWrite(13,!a);
Serial.print("Sent: ");
Serial.println(x,BIN);
}
}

Master Code (Scenario 1)

#include <Wire.h>

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

void loop()
{
Read_();
delay(1000);
}

void Read_()
{
Wire.requestFrom(10, 1);
byte a= Wire.read();
Serial.print(a,BIN);
Serial.print("\t");
Serial.println(a);
}

Master Code (Scenario 2)

#include "SoftwareI2C.h"
SoftwareI2C w;

void setup()
{
Serial.begin(9600);
w.begin(3, 2); // sda=d3, scl=d2
}

void loop()
{
Read_();
delay(1000);
}

void Read_()
{
w.requestFrom(10, 1);
byte a= w.read();
Serial.print(a,BIN);
Serial.print("\t");
Serial.println(a);
}

Output at the Master end (Scenario 2)

Expected data: 1010101 85

Received data:

10101 21
11111111 255

Note

If I remove the heavy load [ LED (byte x) ] from the slave end, then both the standard Wire library and your library work fine.
The problem happens when there is a load at the slave end while using your i2c library as a master.

Please resolve this issue if possible.
Thanks in advance.

Sincerely,
Manzar

The SoftwareI2C::sendByte() method does not contain a timing delay in the for-loop (e.g. a delayMicroseconds()). On very fast 32-bit processors, the digitalWrite() is so fast that the effective I2C frequency can exceed the capabilities of the slave device, causing the I2C data transmission to fail. The problem does not happen on slower 32-bit processors and 8-bit AVR processors.

I have observed the problem on 2 processors:

• ESP32: 1300 KHz observed
• Teensy 3.2: 680 kHz observed

I believe many I2C devices have a limit of about 400 kHz, although some of them may work at higher frequencies. Things do seem to get unreliable at the 680 kHz or 1300 kHz generated by this library.

Hi, I have the Seeeduino XAIO. How can I change the I2C clock speed (for example between 100kHz and 400kHz)?