Unclear how to use pico as a I2C slave

[davidedelvento]

According to https://raspberrypi.github.io/pico-sdk-doxygen/group__hardware__i2c.html the pico can set itself as a slave device. In such a mode, one would guess that something like the following would work:

while(true) {
    if (i2c_get_write_available(i2c1) > 0) {
        i2c_write_raw_blocking(i2c1, data, 1); 
    } else {
        tight_loop_contents();
    }
}

Instead it doesn't. The master (in my case another Pico), who has posted a corresponding i2c_read_blocking() call, does not receive anything and everything hangs. Note that one cannot use i2c_write_blocking() instead of the raw variant, because the master has no address.

According to generic I2C documentation something like this should work... It is curious that there are so many (basically identical) examples of using the Pico as master, and not even one example of how to use it as slave. Proving even a single one, simple working example would really be helpful.

[lurch]

I dunno much about I2C myself, but perhaps this might help? raspberrypi/pico-sdk#508

[davidedelvento]

Thanks for the suggestion. That one does not help much. If anything, #145 helps a bit, but it cannot work as is for me since I have only the two picos. My slightly modified version of #145 does not work. I am running the bus scan on one pico (controller) and the following code on another pico (worker), connected to the first.

while(true) {
    ret = i2c_get_write_available(i2c1);
    printf("Can write %d bytes", ret)
    if ( ret > 0) {
        i2c_write_raw_blocking(i2c1, data, 1); 
    } else {
        sleep_ms(1000);
    }
}

What happens is that the worker always sees 16 bytes available and keeps writing one byte of data. On a separate debug session (I cannot debug both at the same time) running the same code on both, the controller never receives any data and hangs forever once its bus scan hits the address of the worker. The fact that it hangs on the correct I2C address hints that the hardware connection (e.g. pins, cabling, pull up resistors) are ok. I also checked all of that several times and everything seems correct but of course one cannot be 100% sure.
Having an authoritative software example known to work is essential, IMHO.

[lurch]

I dunno much about I2C, but I believe it's a request-response protocol, i.e. the master sends a request to the slave-device, and the slave-device reads the request and then sends a reply. Whereas your code above just seems to be sending a response, without waiting for the request? 🤷‍♂️

[davidedelvento]

You understanding of I2C is correct.

The code in my previous comment was just the code running on the worker (formerly known as slave). There is a corresponding code on the controller (formerly master), which is the one hanging. The worker happily keeps sending data which goes nowhere.

If I exchange the role of the controller and worker (namely, the controller writes and the worker reads) everything works correctly, so I have a proof (besides visual inspection) that the wiring is correct.

Code that works as expected:

#ifdef WORKER
  i2c_read_raw_blocking(i2c0, packet, PKG_LEN);
#elif defined CONTROLLER
  i2c_write_blocking(i2c0, I2C_ADDRESS, packet, PKG_LEN, false);
#endif

Code that hangs (in the controller, the worker is oblivious of the problem)

#ifdef WORKER
    i2c_write_raw_blocking(i2c0, packet, PKG_LEN);
#elif defined CONTROLLER
   i2c_read_blocking(i2c0, I2C_ADDRESS, packet, PKG_LEN, false);
#endif

This is extremely frustrating.

[lurch]

What I meant with my previous comment, is that perhaps the controller is hanging, because it's getting a response from the worker, when a response wasn't expected yet (because the controller hasn't sent out a request). But I'm obviously just wildly guessing 🤷 (IIRC I2C is a half-duplex protocol)
You might be able to get more help from the forums ?

[davidedelvento]

Thank you for that suggestion. It is a little strange, because the controller is in charge of the bus and the worker function name has suffix "blocking" -- so a non-requested response should not be sent. However, among the many things which I tried, there was that too, with a sleep (and corresponding blink of the LED to get a visual confirmation that the worker did not send anything before the controller asked). Still same: worker happily continues after the call, controller hangs in that call.

I am indeed also planning to ask on the forum, but I think that at least one simple, standalone example of slave/worker operation should be included in this repository. If for hw simplicity only one pico board is desired for such an example, perhaps the i2c0 can be used as controller and the i2c1 as worker (if so, necessarily using the second core, but that is so easy, so no big deal)

Isn't it strange that the official pico-example repository contains zero slave/worker examples and whopping 11 master/controller examples all of which are basically copy cat of each other, besides the differences of the attached device?

[davidedelvento]

Ok, so I re-read much more carefully this forum post before posting my own. For the sake of others coming here, the tl;dr; version is i2c_write_raw_blocking is broken and does not work. One must instead use a low level hardware approach (accessing the raw registers) to have a worker send data to the controller.

So the example must be much more complex, and hence more important to have. Perhaps that's the reason why PR #145 has not been merged, since I don't think it can work?

I will open an issue in the https://github.com/raspberrypi/pico-sdk about it (unless there is one already)

[kilograham]

there is a i2c_slave example and a library in the SDK, so closing. if the comments here capture another issue, then please open that separately.