answer about short I2C responses

[tlyu]

This is not exactly an issue (except maybe of documentation in a comment), but more of a possible answer to a question that @obra indirectly posed in wire-protocol.c:

                // Nothing in the ring buffer is the same thing as all keys released
                // Really, we _should_ be able to return a single byte here, but
                // Jesse is too clueless to figure out how to get I2C to signal
                // a 'short' response

I think the short answer is that you're not clueless: a target transmitter doesn't have a conforming way to shorten its responses beyond what the controller expects.

A target can maybe prolong a response by violating the I2C protocol and continuing to transmit after the controller NACKs a byte, if it can prevent the controller from asserting a STOP or repeated START condition. (The AVR TWI hardware module doesn't seem to support doing this.) If the target is honoring the I2C protocol, the controller determines the length of the response. (If the target stops transmitting early, the controller will receive 0xFF bytes until it gives up and NACKs and then sends a STOP or repeated START. The controller has no way to distinguish this from the target deliberately transmitting 0xFF bytes.)

I guess a target could also cause a bus error by violating the protocol in some other way (maybe by asserting a STOP or START before the bus is free?) and force a short read that way. Again, I think the AVR TWI hardware module doesn't support doing that.

Does this explanation seem to fit the observations? (I might be able to do some testing to confirm the finer details, if you have additional questions.)

[obra]

That absolutely jibes with my now slightly more experienced understanding of I2C. I’ll leave this ticket open as a reminder to myself to update the comments.

…

On Jul 26, 2022, at 5:46 PM, Taylor Yu ***@***.***> wrote:  This is not exactly an issue (except maybe of documentation in a comment), but more of a possible answer to a question that @obra indirectly posed in wire-protocol.c: // Nothing in the ring buffer is the same thing as all keys released // Really, we _should_ be able to return a single byte here, but // Jesse is too clueless to figure out how to get I2C to signal // a 'short' response I think the short answer is that you're not clueless: a target transmitter doesn't have a conforming way to shorten its responses beyond what the controller expects. A target can maybe prolong a response by violating the I2C protocol and continuing to transmit after the controller NACKs a byte, if it can prevent the controller from asserting a STOP or repeated START condition. (The AVR TWI hardware module doesn't seem to support doing this.) If the target is honoring the I2C protocol, the controller determines the length of the response. (If the target stops transmitting early, the controller will receive 0xFF bytes until it gives up and NACKs and then sends a STOP or repeated START. The controller has no way to distinguish this from the target deliberately transmitting 0xFF bytes.) I guess a target could also cause a bus error by violating the protocol in some other way (maybe by asserting a STOP or START before the bus is free?) and force a short read that way. Again, I think the AVR TWI hardware module doesn't support doing that. Does this explanation seem to fit the observations? (I might be able to do some testing to confirm the finer details, if you have additional questions.) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.