Connecting 2 Wemos D1 R2 through I2C never worked for me

Hi and congrats Great Arduino Community:

I bring you a doubt,
Working on a Wemos D1R2 board i followed this tutorial:

I adapted it to be sure the SDA and SCL pins are correct as this pic shows, (I think the pins are the same but i tested all possible options anyway)

I have tryed turning on the pull ups by software and hardware, tested some different code examples too and never worked.

Wire length (for tests) is between 6 and 9 cm .

When I worked on pic on i2c I always have needed physical pull-ups to make it work, i thought that would work with the current issue, but it doesnt. :frowning:

Can somebody tell me what is going on? Or any suggestion ?

Thanks

Or any suggestion ?

Are the grounds connected together?

Yes, they are.

Does the Arduino core for esp8266 support slave mode? Last time I checked, this feature had not yet been added.

Im not sure about the core, but there are alternatives...

So someone made a pull request, but it has not been merged.

Question to the OP: why do you want to do this?

PaulRB:
Does the Arduino core for esp8266 support slave mode? Last time I checked, this feature had not yet been added.

I've been struggling for a couple of hours, wondering why I couldn't connect an Arduino to my Wemos through I2C.
Thank you very much.

GrauchoMarx:
... wondering why I couldn't connect an Arduino to my Wemos through I2C.

Don't think "Arduino" and "Wemos". Wemos is an Arduino, even if not officially recognised by Arduino Corp, but that's the role it's fulfilling. Think "AVR-Arduino" and "ESP-Arduino". Of the two, the ESP is by far the more capable in 95%+ of applications, and does not need an AVR in the same circuit. The ESP is impoverished in terms of pins, but more can be added through i2c, and that's better done through using i2c expander chips etc, not through using an AVR as the slave, because that adds the complexity of needing a second sketch to run on the AVR. Two sketches means twice the bugs and debugging.

The big problem with communicating between two devices is the need for flow control. With I2C, this works just fine where the slave is capable of instant response as all it has to do is to set - or read - a register.

If the slave has to perform any more complex action, you have a problem as you need a mechanism to indicate to the master when - and if - the action has been completed in readiness for another, and either the master must wait until that action is completed, or it may not take note of the slave's readiness and simply continue issuing instructions which the slave is unable to execute. :astonished:

Neither of these is satisfactory, and to permit multi-tasking, there must be a primitive in the code to allow the master to determine whether the slave is ready for the next step and if not, turn its attention to an alternate task.