@microdev1 Could you comment on this? Thanks.

I remember that i2ctarget wasn't completely implemented and the PR was merged as is.

I took a look at this issue to see what may be missing. The issue is the current IDF does not support getting the status of the request to the target device. The IDF intends you to fill the "write" buffer if you have something to write and read the "read" buffer if you need to read. As requests come in the hardware either reads/writes from those buffers.

CircuitPython's API is designed to provide an I2CTargetRequest object if a request has come in, but with the IDF we do not know when a request arrives, not if it is a read or write.

According to this issue the ESP32 does not support any information about an I2C target request but newer chipsets can access it via registers.

There was work done to implement this in Arduino but it is not trivial as it involves a lot of lower level hardware calls to achieve the result. I did not look at it close enough to find out how easy it would be to integrate to what CircuitPython would require.

Another (maybe bad?) option would be to create a new I2CTargetESP32 port specific API that works closer to how the IDF works. Probably an object that you can initialize with the address, and poll to read and write data the Target receives or wants to send.

The I2C API has been revamped in ESP-IDF 5.2: see https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides/release-5.x/5.2/peripherals.html. But I'm not sure it helps solve the above.

Let's turn I2CTarget off for now since it doesn't really work if it can't read data. I'll turn it off, and then make it long term.