> Van: Barry King <barry@NRGSYSTEMS.COM>
> Aan: PICLIST@MITVMA.MIT.EDU
> Onderwerp: Re: 16C74A I2C-module woes ...
> Datum: dinsdag 12 september 2000 16:40
>
> Rudy said:
> > Well, it workes.  As long as
> > the master sends a known number of bytes.

[Snip]

> > Well, I can detect the Stop-condition all-right, but the combination of
> > bits in the SSPSTAT register for a Start-condition seems to be the same
as
> > when a NACK is send (well, I mean an ACK is *not* send :-)
>
> I don't understand.  There are seperate bits for START and STOP.
> What bit pattern are you seeing that tells you that the master sent a
> NACK?

The bit-pattern I'm referring to is the one in the SSPSTAT-register.  It's
used in the routine described in the 00734.PDF (Using an I2C in-SSP-Module)
document.

> I think the only way you know that the last byte was NACKed is
> that the SSP does not ask you for another byte, because the master
> NACKs the last byte to say it it done.

You are right.  But what happens if a Master does not really behave well,
and terminates the reception of data with a Stop-bit ?  There would be an
open send condition present in the slave.

And that's just one of the problems. The other problem is that I do not
know when a Master stops *sending* data.  Timing out is not a real option,
because the other side could be tied-up in something more important that
sending I2C-bytes.  A real end-of-transmission would be the arrival of
either a Stop or Re-start-bit ...

And that's where I am now.  I can't seem to be able to incoorporate those
two.

> You get an interrupt for the last data byte requested, then later get
> an interrupt with STOP set.

Right.  The problem is that I can't recognise a NACK and a Start condition
from each other.  The bit-combination in the SSPSTAT register is exacly the
same for those two ...

> The NACK of the last byte is not really indicated by the SSP (I wish it
was).

Yeah.  That was another funny thing I found out .....

Regards,
  Rudy Wieser

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu