I2C Slave not implemented

[Curclamas]

Description

It seams that the I2C slave functionality from the Arduino Wire Lib is not implemented.

Code example

#include <Wire.h> 

void setup() 
{ 
 Wire.begin(0x03);
 Wire.onRequest(requestEvent);
} 

void loop() 
{ 
 delay(10); 
} 

void requestEvent() 
{
 Wire.send(0x13);
}

Error occured during compilation

exit status 1
'class TwoWire' has no member named 'onRequest'

EDIT: Fixed errror message.

[gryzli133]

did you find a solution for that issue?

[marcolettieri]

no news? i've done with esp-idf but arduino way is simpler and clearer

[lbernstone]

@stickbreaker is working on slave I2C (https://github.com/stickbreaker/arduino-esp32/tree/master/libraries/Wire). Not sure where he is at with it, but development is active.

[marcolettieri]

Found out  it... many errors in compile... Il 14/05/2018 15:14, lbernstone ha scritto:

…

@stickbreaker <https://github.com/stickbreaker> is working on slave I2C (https://github.com/stickbreaker/arduino-esp32/tree/master/libraries/Wire). Not sure where he is at with it, but development is active. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#118 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHSe24shLRHFJIzYM4QyD6lNilDrSxa3ks5tyYMagaJpZM4LbtDd>.

-- Marco Lettieri Head of Developments microBees Technology Ltd

[Nightreaver]

Updates?

[stickbreaker]

I've got a working Slave mode, but I am still working through coexistence with Master mode. Slave mode on ESP32 has to call onRequest() before the Slave is addressed. So the outbound data is always stale. Currently Slave mode exists in a separate task, and I haven't decide on the 'correct' design to refresh this data:

• never
• every time onReceive() activates
• manually controlled by application
• every time a Master transactions supplant Slave mode.
• so some combination of all of these.

It is base on a re-implementation of Wire() that is designed for multi-tasking support Multiple Wire() objects are create, each Object is designed as single threaded, The multiple Wire() Objects are safely multi-threaded and share the hardware. But, the Application must transactionalize their access if necessary. The transaction locking with MUTEX's can be abused to cause deadlocks. The 'simple' Arduino 'it just work' philosophy is tough to implement with complex interactions.

Chuck.

[Zhairgling]

Hi @stickbreaker , Any news ?
Can you share code ?
Thanks

[canDry]

BUMP! Anyone have a slave receive solution/fix/workaround?

[nockieboy]

BUMP! Surely there must be enough demand for this feature to warrant some serious development from those that know how?

[dpharris]

Update? How can we help?

[JAICHANGPARK]

Any Update This issues?
I'd like to use I2C Slave mode with arduino uno

[ameer1234567890]

@JAICHANGPARK i2c slave does work on the Arduino Uno. This issue is for ESP32.

[JAICHANGPARK]

@ameer1234567890 I already know.
I mean that I hope to use Esp 32 Slave Mode using arduino IDE

[yeckel]

Any updates? Or example how to workaround that issue?

[Tom5051]

Please help, I also need to use an ESP32 in slave mode but get this error:
(.literal._Z5setupv+0x8): undefined reference to `TwoWire::onReceive(void (*)(int))'

[stickbreaker]

@Tom5051 @yeckel No updates yet, I have a proof of concept, but it is not ready for prime time, (It requires a major change of existing code). Possibly Spring 2020 I might have code is releasable.

Chuck.

[netkruzer]

Thanks for your efforts Chuck. Another bump for i2c as a slave mode when you have a chance. Would be really useful.

[stickbreaker]

@netkruzer Not ready yet. It's not yet code that I want my name attached to. And, I do not want to even think of supporting it as is.

Chuck.

[ellensp]

Darn, I'm also wanting this feature..

[zamorae]

@stickbreaker Hi Chuck. Any date in the foreseeable future that you can provide to have a release of the I2C solution for ESP32? I have been dreaming for a while to use it for some projects I have. Let us know!

Thanks
-zamorae

[ameer1234567890]

It was reported on #1697 by @laercionit that "Someone had succeeded in putting as SLAVE?" Any details on this?

[laercionit]

I couldn't ... I don't think TwoWire is ready for that.

[gutierrezps]

I have made a workaround library not based on interrupts, but based on the only two slave methods currently available from ESP-IDF.

https://github.com/gutierrezps/ESP32_I2C_Slave

[me-no-dev]

If you are still interested, I2C Slave is on the way: #5746

[JAICHANGPARK]

@me-no-dev awesome

[zalexua]

Interesting - will it be proper implementation using ESP32 hardware or some workaround on software level?

[ianr34]

Yep - still very interested in having the esp32 as a slave - and it to be able to get a read request, then live get data and send it back - without polling etc etc. ie what the 328P can easily do.. It really should have been able to do it on the first release - as I said above, at least the serial port guys did it right...

OK, it is calling i2c_slave_attach_callbacks - which sounds promising.

It's in esp32-hal-i2c-slave.h

esp_err_t i2c_slave_attach_callbacks(uint8_t num, i2c_slave_request_cb_t request_callback, i2c_slave_receive_cb_t receive_callback, void * arg);

Which goes to https://github.com/espressif/arduino-esp32/blob/951c32056a562b08da956503db186fd4bd2f019c/cores/esp32/esp32-hal-i2c-slave.c

Which looks like it is doing something similar to the uarts - ie interrupts and queues, using some things I didn't know existed to do some of the i2c stuff ie
https://esp-idf-lib.readthedocs.io/en/latest/groups/i2cdev.html

This call looks interesting too i2c_ll_write_txfifo (out of components/soc/src/esp32/include/hal/i2c_ll.h)

So prob my fault, but I hadn't know some of these calls existed.. But using what's about to be committed as an example it looks like we might be able to write what is needed!
It will be interesting to see the speed it goes at given a fair bit is in software.

[me-no-dev]

So... the ESP32 I2C peripheral does not support clock stretching when in Slave Mode. Therefore, by the time that you get the event and fill the fifo, transaction has already been started and if there were bytes in the FIFO, those would have started sending, else NACK has been sent.

What you ask for DOES work on ESP32-S2 and onward, but not on ESP32.

[ianr34]

OK, so you are saying that the esp32 won't be supporting the full i2c slave model - but the s2 onwards will. That's grreat, as I could move to the s2 for the slave, and will prob be going to the s3 generally anyway (more pins!) - price willing.

Of course, I could just write a bit banging slave for the esp32 - looking at the above code late last night I was assuming that was what you had half done, otherwise you can't support Wire.onRequest(requestEvent); - as it of course generates the bytes to be returned to the master..

So is the above code only for the -s2 and onwards?

[me-no-dev]

it work on all chips, but on ESP32 it just behaves a bit differently. You need to pre-load the data that the master will be able to read. ESP32 as master is also not liking having the clock stretched for too long. Let's say you use S2 as Slave and ESP32 as Master. The slave needs to handle the onRequest as fast as possible to ensure that the ESP32 will not give up waiting for the clock to stop stretching.

[ianr34]

yes, so it doesn't work on the esp32.

Preloading the data IS the core issue and has been since the esp32 was released - preloading is no good for many many many things. No point the master getting data that might be very old..

And yes, onRequest (or whatever it is called as I don't use the ardunio wire library) is always done fast. Typically you just copy the data from somewhere safe, and then exit. You never do any work in it...

[me-no-dev]

I would not call it that big of an issue really... you can use one GPIO on the Slave to signal that there is new data (like many sensors work) and then release the IO in onRequest

[ianr34]

you're making a lot of assumptions with that ie 1) that there is a pin free (A real big problem..), 2) that you want the master interrupt driven (I agree sometimes useful), and 3) it might be the master knows when it wants a value, not the slave, and then (of course) it wants the most recent one. ie at times you want the master to be the master..

I'm putting another device into a product now that has interrupt pins, and I can i2c read it. I'm not using the interrupt pins.

[me-no-dev]

I'm giving you options. not making assumptions :D
ESP32 will not be able to magically start stretching out of this conversation. This is what the hardware can offer. There are other peripherals as well ;) and other chips that can do it. Even with this limitation, you can do almost anything.

[ianr34]

I'm just glad you fixed the hardware with the later versions - as it was a mistake with the esp32.

I could still do a software one for the esp32 - I just haven't had time. The esp32 is easily fast enough.