build_block_buffer() does not end I2C read sequence with NACK about libmpsse HOT 5 CLOSED

On further investigation, this could be fixed by a sequence of reads like this:
Read(any amount of data);
...
Read(any amount of data);
SetAck(1);
Read(less than or equal to I2C_TRANSFER_SIZE);
Stop();
The condition is that we don't Read() more than I2C_TRANSFER_SIZE bytes in the 
last Read() call, otherwise the build_block_buffer() will NACK the peripheral 
before all the data is read. It seems that for I2C transfers, Read() and/or 
build_block_buffer() should somehow be made aware that this will be the last 
read before Stop(), so that they can NACK the final chunk. One possible (ugly) 
hack is to increase I2C_TRANSFER_SIZE to a maximum value needed, so that there 
is only one chunk of data read and then NACK the last byte in chunk every time.

I'll double check this on the scope when I get a chance, but the following 
*should* work:

Read(all data except the last byte);
SetAck(0);
Read(1);
Stop();

Passing a 1 to SetAck enables ACKs, while passing a 0 disables ACKs (aka, 
enables NACKs). This is a bit confusing as it is the reverse of the logic 
levels used on the bus, so perhaps this should be changed.

Let me know if the above works for you, or if you still have problems.

Yes, that sequence is ok. Once I grasped the logic of it, it worked as 
advertised.

I think an update to i2ceeprom example would go a long way towards explaining 
this, including the ACK/NACK logic. As it stands now, the example reads in all 
the data and then attempts to Stop(), without toggling the Ack before the last 
byte. This does leave peripherals in a rather unfortunate state of still trying 
to clock out data.

Thank you for your assistance and a very good library!

Yes, EEPROMs are pretty forgiving while other I2C devices aren't. Looking over 
this I also noticed that the documentation in README.I2C is wrong as well, so 
I'll be sure to update that. Sorry for the confusion!

Updated I2C examples and documentation. Also updated SetAck such that passing 
it a 1 sends NACKs and passing it a 0 sends ACKs; this corresponds with the ACK 
bit actually sent on the bus, as well as the ACK status returned by GetAck.

Thanks!