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.

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.

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!