Be careful when using these examples there are a number of errors
(especially in the documentation). The usage of ACK/NACK is incorrect. ACK
should refer to a positive response from the master to the slave when
receiving data from the slave. NACK should be a negative response from the
master to the slave when receiving data from the slave. All bytes received
from the slave should be ACKed except for the last byte which should be
NACKed. The NACK causes the slave to release the data line so the master
can send the stop signal (data line transition from low to high while the
clock line is high leaving both lines high).

The NACK function as written provides two functions.
  1> Clock in the status bit from the slave when writing. (but don't
actually read it!)
  2> Send an ACK to the slave when reading.

The ACK function as written sends a NACK when reading

Besides the obvious naming convention problems causing confusion when
comparing the code to the 24C(L)65 data sheet, the NACK(1) function doesn't
actually capture the status bit from the slave. This bit when = NACK (low)
indicates that the device is busy when initiating a command or that the
last byte sent was not accepted. When this status bit is used correctly,
the code is much smaller and more robust and can be used to determine when
the device write cycle is complete eliminating the 25ms write delay (which
is also incorrect). According to the 24C(L)65 data sheet, the device "page
size" is 8 bytes and the maximum write time for one "page" is 5ms. The
delay as written "should" work for upto 5 "pages" however, the write buffer
can hold 8 "pages" so when writing in buffered mode the maximum write time
is 40ms. Using a delay approach when Acknowledge Polling is available is
simply a waste of time.

The clock timing of course is system clock dependant, the data sheet
indicates the following minimums:

Low speed - High time: 4ms, Low time: 4.7ms
High speed - High time: 0.6ms, Low time: 1.3ms

Refer to the data sheet for the rest of the important timing information
like Start condition hold and setup timing.

The other area of the documentation that is flawed, is the discussion of
buffered writing. The write buffer is 64 bytes long, ANY number of bytes
may be written starting at ANY address. The only thing you need to be aware
of is that the buffer is always "page" aligned and when the 8th page is
full, the buffer wraps back to the beginning. As a result, if you start
writing at address 3, the 65th byte written will be placed at location 0 in
the buffer (equates to 0 in memory in this example). When the write is
committed to the EEPROM, the previous data at location 0 WILL BE OVER
WRITTEN! If you limit your writes to 56 bytes at a time you completely
avoid this problem and can write anytime to any location unhindered. You
can read any number of bytes up to the entire 8K using a single read
command. If you start at location 0 and read more that 8K, the address will
wrap back to the beginning, this is also true when writing past the end of
the device.

Other than being a bit on the fluffy side, the code is a good starting
point for someone new to I2C memories. I strongly suggest that you download
the 24C(L)65 data sheet. It provides an excellent description of the
interface.

Enjoy,

Mark Hellman
M.V.Micro
Real Time Embedded Systems -R- Us