I2C slave driver

[okhsunrog]

Are there any plans for I2C slave driver? I only found embassy example for I2C slave for rp2040 https://github.com/embassy-rs/embassy/blob/main/examples/rp/src/bin/i2c_slave.rs
Checked the i2c driver in esp-hal and it seems like there isn't any slave driver.

[jessebraham]

While we would like to have this eventually, we have no plans to work on this feature at this point in time. Likely this will need to be a community contribution, but perhaps one of the maintainers will have time in the coming months if not.

If this feature generates enough interest we can definitely re-evaluate and prioritize this, but you are one of (if not the) the first people to ask :)

[okhsunrog]

Okay. Maybe I'll open a draft PR in the next month if I have free time 😅

[marcpabst]

I was a bit surprised to see there’s no I2C slave driver in esp-hal. This would be a great addition!

[hcabel]

I agree, +1 for i2c slave driver

[cyril-marpaud]

+1

[turgu1]

+1

[turgu1]

I decided to work on a I2C slave driver. At this point in time, it works fine for the esp32C6. As I have in hands both ESP32 and ESP32S3 devices, I will complete the tests on these devices before making it available as a PR. You can find it here in folder esp-hal/esp-hal/src/i2c/slave. The effort is being done with the help of Claude Sonnet 4.5 .

[mbehr1]

+1 need this as well :-)

[mbehr1]

@turgu1 I think I found a bug in your slave driver (btw: thx a lot for working on it!). Issues are disabled on your fork so let me describe it here:
I have a use-case where I want to simulate a PCF8570 256 byte i2c RAM.
The register mode doesn't really fit for that use-case (as e.g. the ram does automatically increase the addr after each read.
So on the master I use a combined write_read(..., add, buffer) (with varying buffer length. E.g. sometimes just 1 byte, for some addresses 2 bytes and sometimes 13 or 16 bytes).

So on the slave side I do: read (with a e.g. 16 or 31bytes buffer). and if read length == 1 I treat it as the address and start a write with max (16) bytes.
The data arrives at the master but:
As I write more data than the master usually reads the following bug seems to happen: the last byte that from prev. write (the one where afterwards the master ends the transaction) gets sent on next write again.

So e.g.
master does write_read (0x10, <buf with len 2>)
slave sends/writes data from simulated ram addr 0x10..0x10+16
master receives two bytes from 0x10, 0x11
master does write_read (0x20, <buf with len 2>)
slave sends/writes data from simulated ram addr 0x20..0x20+16
master does receive data from address 0x11 (wrong!) and then 0x20...

Any idea how to fix that? Or is there a better way to support this write_read scenario with unknown expected write length?
(Btw: I'm still using the non async version as I had troubles with the async. Will investigate a little further there first.)

@okhsunrog any idea from your side? (as you wanted to work on a PR as well)

[turgu1]

@mbehr1 : Hello Matthias, I've been away from that code for the last 3 weeks and I'm not expecting to look at it before January. Here are my idea on that:

• Is it possible for the master to try to read a larger size of data even if it receives less amount? Normally the slave would indicates the end of the transmission end the master would then be able to access the data.
• If that is now a working solution, a possible issue could be that the i2c fifo on the slave side needs to be cleared before writing again.
• For the async issue, I have been trying to get it work without success with the i2c/slave folder version. A bit normal as the I2C is synchronous by definition. I started to work on a second interrupt based version but it still not in a working state. You may find it in the i2c/slave_async folder.

[mbehr1]

@turgu1 sadly I cannot change the master behavior.

[mbehr1]

@turgu1 I found a fix for the issue (fsm state machine needs resets as well). But your driver approach had quite long latencies (plenty of ms instead of us). So I implemented a fully interrupt based i2c slave driver with a different api (callback instead of read/write). See here: https://github.com/mbehr1/esp-hal/tree/feat/i2c_slave.
The code avoiding the "last tx fifo byte being transmitted first" is handled here: https://github.com/mbehr1/esp-hal/blob/495aa328ca6a36e6bc8de9c7f1d6b79362485bb0/esp-hal/src/i2c/slave/mod.rs#L431 I reset the tx fifo incl. fsm on the "NACK" interrupt that comes ones the master stops reading from the slave.