> Van: Herbert Graf <mailinglist@FARCITE.NET>
> Aan: PICLIST@MITVMA.MIT.EDU
> Onderwerp: Re: [EE]: I2C Question
> Datum: woensdag 3 januari 2001 17:28

Hey guys (& girls ofcourse :-) ,

> > When a slave is sending data to a master, I know the master is supposed
to
> > ACK every byte apart from the last one.  What I'm not sure about
> > is:  Should
> > the master not produce the 9th clock at all, or should it produce a
NACK?
> > I've read the Philips I2C guide and it's not very clear on this point,
it
> > says at one point:

The *Master* generates all clock's.  The *receiver* (either being the Slave
-or- Master) generates the ACK.  the *sender* (either being the Slave -or-
Master) provides the data.

> > "If a master-reciever is involved in a transfer, it must signal the end
of
> > data to the slave-transmitter by not generating an acknowledge on the
last
> > byte that was clocked out of the slave"
> >
> > However, a couple of pages later, a diagram clearly shows the master
> > generating a NACK at the end of the last byte.  Now, I have tried both
on
> > some master code I have on a PC, and when it's talking to my PIC slave
> > device, both methods seem to work ok.  Anyone know which is correct?

Look at the next :

The Master requests some data from a Slave.  The *request* is send to the
Slave, and therefore the Slave has to ACK every byte.  After that the
data-stream turns around, because the Slave send's the requested data to
the Master.  This means that the Master has to ACK every byte.  When it
does not want any more data, it just does not generate an ACK.

During all this time the Master privides the Clock-signals.


> 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

Well, the above get's me confused.  You're saying that "most of my slaves
never seem to NACK" .  That's quite normal.  If the Slave comes at the end
of it's data-space, *most* of them just wrap-around, sending you the very
first byte.

Why do you want to have a NACK from a Device ?  The presence of an ACK is
the proof that a Device is present.  A NACK can mean that there is no
Device present at the choosen address, or that the Device does not want any
more data ...  Take your pick. (meaning, it's not the way to go)

Send a Write-address, and see if it get's ACK-ed.  If so , there is an
Device present.  If not, ... well, you get the picture :-)

Regards,
  Rudy Wieser

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