ESP8266 as a I2C slave

[gotfredsen]

Basic Infos

• This issue complies with the issue POLICY doc.
• I have read the documentation at readthedocs and the issue is not addressed there.
• I have tested that the issue is present in current master branch (aka latest git).
• I have searched the issue tracker for a similar issue.
• If there is a stack dump, I have decoded it.
• I have filled out all fields below.

Platform

• Hardware: [ESP-12F] XinaBox CW01
• Core Version: [2.5.0] Latest board file in Arduino
• Development Env: [Arduino IDE 1.8.8]
• Operating System: [MacOS ver 12.0.3]

Settings in IDE

• Module: [Generic ESP8266 Module]
• Flash Mode: [DOUT]
• Flash Size: [4MB]
• lwip Variant: [v2 Lower Memory]
• Reset Method: [ck]
• Flash Frequency: [26Mhz]
• CPU Frequency: [80Mhz]
• Upload Using: [SERIAL]
• Upload Speed: [115200] (serial upload only)

Problem Description

While ESP8266(I2C Master) to ESP8266(I2C Slave) works, with a pinch†, I cannot get ESP8266 to work as an I2C Slave towards Raspberry Pi, Micro:Bit and others.

The sketch below works perfectly as an ESP8266 I2C slave used with a ESP8266 I2C Master, but not otherwise.

I can detect‡, the slave on a RPi using i2cdetect -y 1, but can't communicate with the slave. I have tried frequency change, clock stretching in Arduino, 3 different libraries on the RPi, and I have tried in MicroPython on a Micro:Bit to no avail.

† In order to have the ESP8266 Master to work, I have to call the Wire.begin() with an address, like a Master address, that is not standard, but otherwise it won't work for me.
‡ i2cdetect -y 1 only works 80% of the time, and while seemingly high, it is not 100% of the time like with all other I2C slaves.

MCVE Sketch

#include <Wire.h>
void requestEvent() {
  Wire.write("At your service!");
}
void setup() {
  Wire.begin(2,14,0x08);           
  Wire.onRequest(requestEvent);
}
void loop() {
}

Debug Messages

Debug messages go here

More attempts: Just to make sure I haven't lost it, I tried with another WiFi board, the Arduino MKR1000, and the above code (except for the pin allocations), and it worked perfectly.

Here is the RPi code, btw:

import pigpio
pi = pigpio.pi()
handle = pi.i2c_open(1,8,0)
(count, data) = pi.i2c_read_device(handle, 16)
print(data)
pi.i2c_close(handle)
pi.stop()

[pat1]

Do you use in your circuit two pull-up resistors?

[gotfredsen]

I have external pull-up resistors (on SDA and SLC), which in any case I don't believe I need since there is only 2 devices on the bus, 1 master and 1 slave.

[r3na]

Hi @gotfredsen I have the same issue here. This driver works well between two ESP8266 (e.g. Adafruit HUZZAH ESP8266 Breakout - one being master and the other slave). But it does not work using one ESP8266 and another board (w/ different driver - e.g. Teensy 3.x). Anyone had success using 2 different boards/drivers ? I tried without pull-up resistors, then with (4k7, 2k2, 2k7, 10k) and also with different clocks... No success in any of these cases.

[rousir]

Hi, Is the problem solved?I have the same issue here. This driver works well between two ESP8266，But it does not work using one ESP8266 and arduino uno

[d-a-v]

per #5226 (comment)

This driver works well between two ESP8266

What is the maximum reachable & sustainable clock frequency between esp8266 hardware i2c master and software i2c slave ?

[jasondickert]

Hi, Is the problem solved?I have the same issue here. This driver works well between two ESP8266，But it does not work using one ESP8266 and arduino uno

I have the same issue. I can get the ESP8266 to work as a master with my Mega2560, but when I flip the roles where the ESP8266 is in slave mode it doesn't appear to respond to either request or receive event. Tried setClock at 50000, 100000, 200000, and 400000. Also, on the same bus I have a PCA9685 that responds to the mega when it's the master with no problem. Using a 5v/3.3v level shifter between the two sides (also skipped that and ran the mega at 3.3v too with no luck).

The ESP8266 in my case is Adafruit's HUZZAH.

Edit: after trolling through the related issue threads here on this topic I'll just stick with using this device and my mega as multi-masters where the esp can spam the mega as needed. Where the mega needs to get something to the esp it can do so when the esp asks (on some polling interval).

[nedoskiv]

I'm testing esp8266 (wemos DI mini) as slave with esp32 (micropython) as master, as far I can tell, esp8266 receive from ESP32 but cannot sent any data back. Micropython error is:

>>> i2c.readfrom_mem_into(48, 0x14, data)

OSError: [Errno 19] ENODEV
It is I2C timeout/IO error

>> > i2c.writeto_mem(48, 0x04, b'\x00\x00\x01')

execute without problem and my debug on esp8266 slave reports all correctly:

loop1
processevent: 4,0,0,1,

my ESP32 communicate with attiny without any problems.

[schliepi]

I have exactly the same issue like thread opener @gotfredsen.

I further investigated with a logic analyzer and sigrok's pulseview app.

From what I see is: esp8266 has - running at 80MHz - not enough performance for receiving at 100kHz with the current implementation.
Even at 160MHz there was no success at 100kHz.
atmega328p works like a charm - it encodes/decodes i2c in hardware. esp8266 does not.

For research I used master_writer and slave_receiver.
I tried two different Wire.begin() followed by Wire.setClock() for master_writer.
Of course for each test case only one steClock-line active

Block A withAddress
Wire.begin(SDA_PIN, SCL_PIN, I2C_MASTER);
//Wire.setClock(50000L); // this results in 30.8kHz - success
//Wire.setClock(100000L); // this results in 40.8kHz - success
//Wire.setClock(400000L); // this results in 58.8kHz - success

Block B noAddress
// patched core_esp8266_sic.cpp to accept setClock(25000L)
Wire.begin(SDA_PIN, SCL_PIN); // join i2c bus (address optional for master)
//Wire.setClock(25000L); // this results in 28.6kHz - success
//Wire.setClock(50000L); // this results in 54.1kHz - no success
//Wire.setClock(100000L); // this results in 90.9kHz - no success
//Wire.setClock(200000L); // this results in 166.7kHz - no success

Hopefully @pasko-zh finds time to finish #2055.

I could attach some screenshots of pulseview for the test cases above, if this is of any interest.

[devyte]

Unfortunately, @pasko-zh's code is licensed under GPL3, which is incompatible with our repo license. Unless that very nice implementation changes licensing, or we get an explicit exception, we can't integrate it directly here.

[earlephilhower]

I've looked at @pasko-zh's code, and while it looks really nicely built and organized (best comments in ASM I've seen in a long time), I don't think it really solves the problems here.

From what I read, brzo-i2c is a master-mode only implementation, and it's fully busy-waiting (i.e. 100% of CPU while running). For master transactions, that's probably fine and the most direct way to make it happen. His scope traces look really gorgeous this way!

But on a slave, you need to do IRQ triggered operations or else you can't use the 8266 to do anything else besides busy-waiting (i.e. no wifi, no anything).

The current slave code is slow because it probably spends >50% of its active CPU time in OS IRQ handling code before the ROM calls our IRQ handler (saving processor state, etc.) So it loses edges easily and that limits the slave clock rate it can work at. It also is going to be hit by IRQ disable windows when doing WiFi operations, increasing the required clock cycle for stable operation.

Something that short-circuits the OS IRQ handling and does the slave FSM immediately, with minimal register usage, and which makes the IRQs NMI if possible, might be able to move the needle. Or, a creative (ab)use of the I2S port might be able to do it.

There is a PR #6326 which focused on reducing IRAM usage, but which should also (because of using fewer instructions) run at slightly higher frequencies. @schliepi, would you be able to give it a try and see if it helps in any way (or if it busts slave mode completely)?

[schliepi]

Some further investigation later. Is it really OS IRQ handling that slows slave mode down?
Simple test setup how long it takes after input pin signal change until IRQ handler runs:
D1 directly connected to D2. Interrupt attached to D2. When called set lines D5 and D6 low.
So when I set D1 low, I expect some delay, an then D5 and D6 get pulled low.

This is the simple Arduino sketch:

#include <PolledTimeout.h>

#define D1_LOW()   (GPES = (1 << D1)) //Enable D1 (becomes output and since GPO is 0 for the pin, it will pull the line low)
#define D1_HIGH()  (GPEC = (1 << D1)) //Disable D1 (becomes input and since it has pullup it will go high)
#define D1_READ()  ((GPI & (1 << D1)) != 0)
#define D2_READ()  ((GPI & (1 << D2)) != 0)
#define D5_LOW()   (GPES = (1 << D5)) //Enable D5 (becomes output and since GPO is 0 for the pin, it will pull the line low)
#define D5_HIGH()  (GPEC = (1 << D5)) //Disable D5 (becomes input and since it has pullup it will go high)
#define D6_LOW()   (GPES = (1 << D6)) //Enable D6 (becomes output and since GPO is 0 for the pin, it will pull the line low)
#define D6_HIGH()  (GPEC = (1 << D6)) //Disable D6 (becomes input and since it has pullup it will go high)

void ICACHE_RAM_ATTR onD2Change();

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);           // start serial for output
  Serial.println();
  Serial.printf("getChipId     = %08X\n", ESP.getChipId());
  Serial.printf("getCpuFreqMHz = %8d\n", ESP.getCpuFreqMHz());

  pinMode(D1, INPUT_PULLUP);
  pinMode(D2, INPUT_PULLUP);
  pinMode(D5, INPUT_PULLUP);
  pinMode(D6, INPUT_PULLUP);

  attachInterrupt(digitalPinToInterrupt(D2), onD2Change, CHANGE);
}

void onD2Change() {
  D5_LOW();
  D6_LOW();
  D5_HIGH();
  D6_HIGH();
}

void loop() {
  // put your main code here, to run repeatedly:
  using periodic = esp8266::polledTimeout::periodicFastMs;
  static periodic nextPing(5);

  if (nextPing) {
    if (D1_READ() == 1) {
      D1_LOW();
    } else {
      D1_HIGH();
    }
  }
}

Measuring with logic analyzer at 24MHz:
Time for D5 going low after D1/D2 going high: 4us.
Time for D6 going low after D5 going low: 80ns.

4us until my code executes in iterrupt?
Am I measuring wrong?
Running at 160MHz the times getting halved.

I read this over at espressif
https://bbs.espressif.com/viewtopic.php?t=360#p1358

We test the normal latency is about 1~1.2us

[earlephilhower]

IIRC, there's not a separate IRQ vector for each pin change, only one general GPIO IRQ. That pin change IRQ then needs to figure out which callback to call, so I am pretty sure there's a reasonable amount of code being executed before the first insn of our callback gets executed. I would be happy to be proven otherwise, because if it's in our code we can try and do something about it!

A test you can automate would be to use ESP.getCycleCount(). That's an internal 80MHz counter (even when core is at 160) and you can copy it just before writing to GPIO-Set and grab it again right at the top of your callback. Then in the main routine after some hardcoded delay you can do a delta from end-start and get the "speed of light" for IRQs...