Should I2C Master ACK after last byte in read sequence?

I've never dived into the I2C protocol too much. However, I started doing a bit of a dive recently and noticed that I have some code in PropWare which is sending a NACK instead of an ACK after the last byte that a master reads. This seems crazy to me. Why would the master ever be coded to explicitly send a NACK? Here's an example:


And this read sequence returns 0x01 to the calling function, so the master is indeed reading the value from the slave correctly.
1157 x 89 - 8K


  • Yes, the chip misbehaves next time if you don't nak to say "no more, I'm done" whereas the stop has more to do with the bus protocol than the operation of the chip.
  • Interesting. Didn't know that. Thanks :)
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,614
    edited 2016-11-10 - 16:11:47
    Most chips don't care about the NAK, since the stop condition will reset the protocol engine anyway. In fact, the BASIC Stamps that support I2C send all ACKs: no NAK at the end of a read. This tripped me up, though, when I encountered an I2C sensor that required the NAK to function properly.

  • The PropWare I2CSlave is explicitly awaiting a NAK when the master is done reading.
    It will probably make problems when the master just sends a stop-condition, because the write method does not expect it.
  • FWIW Some Wii Nunchuck controllers won't behave properly if a finally NAK isn't included.

    Since this seems like a reasonable thread to grumble about it, I'll also add I've been surprised how often I seen clock stretching in Wii controllers.
Sign In or Register to comment.