I2C support for short writes

[dhalbert]

I was told by word of mouth that the DW_apb_i2c hardware design licensed for the RP2040 does not work for I2C write transactions for 0 to 2 bytes of data (not including the address). MicroPython special-cases this by doing bitbang I2C for writes of length 2 or less, and we adopted the same thing in CircuitPython. It took a little painful experimentation to get it exactly right.

pico-sdk does not do anything special to handle short writes. Should it? Or should it be documented that they don't work, in the datasheet and/or the SDK doc? Or is this actually not a hardware issue, but a hardware-use that could be worked around in another way? I don't have access to the support info from Synopsys for DW_apb_i2c to clarify this. I know this is a commonly licensed piece of IP, but when doing webesarches I haven't found specific reference to this issue elsewhere. Thanks for any further info you may have on this.

[aallan]

We've discussed this internally and we're not aware of the issue. Can you provide a case that triggers the need to special case writes of 2 bytes or less? We can't do 0-byte writes (this is a known and intentional limitation, not a bug) but we're unaware of any issues with 1 or 2-byte writes.

[dhalbert]

(I was working up a simple example for 0-byte writes but then you edited your response. 🙂 )

We can't do 0-byte writes (this is a known and intentional limitation, not a bug)

I poked around some more and found this comment in i2c.c, which I had missed before:

    // Synopsys hw accepts start/stop flags alongside data items in the same
    // FIFO word, so no 0 byte transfers.

So that explains it. I think it would be good to have this noted in the SDK docs and the datasheet. I can open an issue in pico-feedback and/or here for that, if you'd like.

As for 1 and 2-byte writes, I apologize for the false alarm. @dpgeorge has chosen to do 0-2 byte writes as bitbang in MicroPython. I tried to vet his choice and thought I saw that 1 and 2 byte writes were not working, but I just retested and I don't see the problem. (This was in parallel with trying to get the TCS34725 sensor working on RP2040 I2C: it does not, for reasons I have not yet discerned, though it's fine on other ports. It does NACKS in cases where the data sent looks fine.). Thanks again.

[aallan]

I think it would be good to have this noted in the SDK docs and the datasheet. I can open an issue in pico-feedback…

Thanks, if you could do that, that'd be great. I'll close this one.

So that explains it.

Yup! :)

[fivdi]

I think there is actually an issue that might lead people to believe that 1 byte writes don't work. With pico-sdk v1.1, calling i2c_write_blocking to write a single byte will always return the value 1, indicating success, even if there is no device at the addr passed to i2c_write_blocking. See here.