Yah, I'm trying to figure a clever way to test this as well..but one
thing at a time!

What you wrote makes sense to me.

Thank you very much, once again. :)

Daniel Najemy - Numaliine Power Systems

> -----Original Message-----
> From: Keith Howell [SMTP:keithh@ARCAM.CO.UK]
> Sent: Thursday, January 15, 1998 8:18 AM
> To:   PICLIST@MITVMA.MIT.EDU
> Subject:      Re: I2C Slave Funtionality
>
> Najemy, Daniel wrote:
>
> > ... about the R/W bit. Yep. You got it.
> The SSP interrupts the CPU when it has
> had either a byte come in or go out.
> So you need to know what to do next.
>
> IF( it is an address byte come in)
> {       copy the R/W bit somewhere.
> }
> ELSE    // either a data byte came in or went out.
> {       // the R/W bit in SSPSTAT may not be valid now
>         // hence you test the copied bit !
>         IF ( master is writing to the PIC)
>         {       take the byte from SSPBUF
>         }
>         ELSE // the master has finished reading the byte
>         {
>                 so stuff data in SSPBUF // see note below
>         }
> }
>
> > Why would you need to know about the ACK bit?
>
> So you know whether the master has had enough data bytes
> or you have to send more.
>
> > Did you try using the Data/Address bit (SSPSTAT<5>?
>
> I do use it, to check whether I need to update the copy of R/W.
>
>
> Man, debugging complex I2C systems is a pain.
> I tell you what I want: something that mimics an EEPROM
> but lets you see the contents through a display.
> And maybe modify them. It'd be damn useful!
> Sod this scrutinizing dual-channel storage scope traces.
>
> When I have time, I'll make one out of a spare front-panel.
>
> TTFN, KH