• Re: I2C - Master generates NAK on last byte of read from slave - why?

    From Tim Chantor@21:1/5 to Tony Williams on Thu Nov 11 17:22:43 2021
    On Thursday, February 11, 1999 at 3:00:00 AM UTC-5, Tony Williams wrote:
    In article <79trv8$gql$1...@owl.slip.net>,
    Myron Tuttle <mtu...@slip.net> wrote:
    That is correct. During the 9th bit the master sets SDA high
    for a NAK. At this point the slave lets go of control of SDA.
    Then the masster pulls SDA low, lets SCL go back high, waits
    5us and then lets SDA go high to generate the STOP. Remember
    that the I2C bus can only assert a low. The highs are
    generated by letting the pullup do it.
    Yes thank you. Useful things, newsgroups. :)
    --
    Tony Williams.

    It is not exactly obvious why the i2c spec requires the NAK on the last byte of a read sequence.
    There are two reasons, one directly related to bus state:

    1) After a read ACK, a device will prepare to shift out the next byte. If the first bit of this byte is a
    zero, the device could drive the bus while the host is attempting to signal a stop condition. This
    would only happen if the device drove the next bit shortly after the clock's rising edge (the edge
    that latches the ACK/NAK) instead of waiting for the the next falling edge. Strictly speaking, this
    is not a violation of the protocol since the device knows when it has received the ACK/NAK, and
    driving opposite the host ACK/NAK for part of a clock phase is not an electrical collision given
    the open-collector implementation of the drivers. So, the host must NAK to indicate to the device
    'I do not want to hear from you anymore,' clearing the way for a STOP condition.

    2) If a device implements auto-increment of register address (or sub-address) on read, ACK on
    last read can cause the device to falsely advance its internal register address - all depending on
    the device's specific implementation. Usually not a big deal since the next read transaction can
    reassert the register address.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tim Chantor@21:1/5 to Tim Chantor on Thu Nov 11 17:37:20 2021
    On Thursday, November 11, 2021 at 8:22:48 PM UTC-5, Tim Chantor wrote:
    On Thursday, February 11, 1999 at 3:00:00 AM UTC-5, Tony Williams wrote:
    In article <79trv8$gql$1...@owl.slip.net>,
    Myron Tuttle <mtu...@slip.net> wrote:
    That is correct. During the 9th bit the master sets SDA high
    for a NAK. At this point the slave lets go of control of SDA.
    Then the masster pulls SDA low, lets SCL go back high, waits
    5us and then lets SDA go high to generate the STOP. Remember
    that the I2C bus can only assert a low. The highs are
    generated by letting the pullup do it.
    Yes thank you. Useful things, newsgroups. :)
    --
    Tony Williams.
    It is not exactly obvious why the i2c spec requires the NAK on the last byte of a read sequence.
    There are two reasons, one directly related to bus state:

    1) After a read ACK, a device will prepare to shift out the next byte. If the first bit of this byte is a
    zero, the device could drive the bus while the host is attempting to signal a stop condition. This
    would only happen if the device drove the next bit shortly after the clock's rising edge (the edge
    that latches the ACK/NAK) instead of waiting for the the next falling edge. Strictly speaking, this
    is not a violation of the protocol since the device knows when it has received the ACK/NAK, and
    driving opposite the host ACK/NAK for part of a clock phase is not an electrical collision given
    the open-collector implementation of the drivers. So, the host must NAK to indicate to the device
    'I do not want to hear from you anymore,' clearing the way for a STOP condition.

    2) If a device implements auto-increment of register address (or sub-address) on read, ACK on
    last read can cause the device to falsely advance its internal register address - all depending on
    the device's specific implementation. Usually not a big deal since the next read transaction can
    reassert the register address.

    and.. regarding (1), above: even if the device waited for the next falling edge to drive out the next
    [potentially low] bit, this can still be a problem because a host often issues a falling clock edge after
    the ACK/NAK phase in order to prep the data line for STOP. Imagine that, after ACK/NAK, clock
    is high and data is high. A STOP needs to affect a data low-to-high transition while clock is high. If
    the host were to simply bring data low and then back high, it would actually be signaling a repeat
    START followed by STOP. So, it would need to being clock low, then data low, then clock high,
    then data high in order to avoid the unintended repeat START. It is this additional clock low
    transition that invites a new, potentially low, data bit to be driven onto the bus.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to Tim Chantor on Fri Nov 12 20:14:21 2021
    On 12/11/2021 02:22, Tim Chantor wrote:
    On Thursday, February 11, 1999 at 3:00:00 AM UTC-5, Tony Williams wrote:

    <snip>

    Please look at the dates above.

    While it is good that you want to help the poster with an answer, it is unlikely that he has been sitting quietly waiting for help for the last
    22 years.

    If you want to join this Usenet group (and I hope you do - it's been a
    bit slow in recent times), I recommend you use a real Usenet client and
    server. Thunderbird is free, and works on any system, and news.eternal-september.org is a free server (there are many other
    clients and servers if you prefer). Usenet works far better with a
    decent client rather than Google's broken "Groups" interface. But if
    you do use Google Groups, check the data of the posts you reply to!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)