Hello Boys and Girls,

A few more things about this question of ACK/NACK:

> > Unfortunately I have never gotten reliable NACKs,
> > most of my slaves never seem to NACK, which can be a pain since I can't
> use
> > that method to detect if they are there, but that's OK. I am also working
> > through a PC interface. TTYL

The usual sequence is for the master to send a slave address (read or
write), the ACK/NACK of that address byte tells you whether the
device is present.

If it is, then when the data is transferred, each byte is ACKed by
the receiver.  As Rudy said, most slave-only devices e.g. EEPROMs,
always ACK data bytes written by the master, and always supply the
"next" byte when read, defining something reasonably sensible to do
with them (like a wrap around).

A master, when reading a slave, is SUPPOSED to not ACK (ACK bit is
high=NACK) the last byte it is reading to signal the slave that it is
done.  However, since the next event is either a stoP or Start bit,
most slaves will work fine if the master doesn't NACK the last byte,
because the transaction is aborted by the P or S anyway.

To be robust, one must handle the cases where the master is reading
more bytes then the slave transmitter is expecting to supply.  Most
notably, if your PIC SSP module is doing a slave transmit, it WILL
LOCK SCL low while waiting for the next byte to be loaded into the
SSP.  Firmware MUST supply another byte if the master asks (by ACKing
the previous byte), even if the byte count is "wrong".  I got bit by
this when I had bus errors. The slave thought he sent all his bytes
then went back to doing something else and left the SSP holding SCL
low, locking up the bus.  The only way to get the SSP out of slave
transmit mode (short of resetting the SSP) is to have the master NACK
that last byte.

Regards,

Barry.
------------
Barry King
NRG Systems "Measuring the Wind's Energy"
http://www.nrgsystems.com
Check out the accumulated (PIC) wisdom of the ages at:
PIC/PICList FAQ: http://www.piclist.com/faq

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.