|Then I had problems, I found these chips insist
|you follow the I2C spec rigourously. You must
|NACK the last byte you read, for example.

The requirement to NAK the last byte read is a function of physics
as much as of protocol.  Following an ACK, the EEPROM will drive the
data wire per the first bit of the next byte.  If that bit happens
to be zero, there will be no way to change the data wire while the
clock line is high other than by clocking data bits until the end of
the byte is reached or a "1" bit is encountered.

By the way, I've found that I2C works much more easily if the ACK
is regarded as an early part of the read command (i.e. generate an
ACK before each byte, rather than after).  If this is done, then
the read procedure doesn't have to know whether another byte is
going to be needed.

The write byte procedure is then:
  Assert data.  Raise and lower clock.
  Output first data bit.  Raise and lower clock.
  ...
  Output last data bit.  Raise and lower clock.
  Release data.

The read procedure is:
  Raise and lower clock.  Read first data bit.
  ...
  Raise and lower clock.  Read last data bit.
  Raise and lower clock.  Read ack/nak bit.

  Note that following a write operation, an ACK will be sitting on
  the data bus.

The start procedure is:
  Release data.
  Lower and raise clock until data reads high.
  Assert data.

  Note that at the end of the start procedure the clock is "high".
  This means that when the part is next written, the first "raise
  and lower clock" will merely assert the clock without generating
  a rising edge first.

The stop procedure is the same as the start procedure, except that
data is not asserted afterward.

I've found that restructuring the I2C start/write/read routines in
this way is a good way to simplify things.  The one potential dis-
advantage I've observed is that following any write operating the
data line will be externally held low until the next transaction,
and following any read or write the clock will be held low.  The
recommended pullups won't draw huge amounts of power, but in a bat-
tery-powered device it may be good to leave the I2C bus idle when-
ever possible (probably reduces the likelihood of glitches).


Attachment converted: wonderland:WINMAIL.DAT (????/----) (00024CA3)