Thank you very much for this information. I had the same intentions
about reading the R/W bit. If I understand you correctly, after the
first interurrupt generated by the address read, I should save this
value off somewhere in memory, and update it only after address
information is sent the next time.

Why would you need to know about the ACK bit?

Did you try using hte Data/Address bit (SSPSTAT<5>?

Thanks in advance!


Daniel Najemy - Numaliine Power Systems

> -----Original Message-----
> From: Keith Howell [SMTP:keithh@ARCAM.CO.UK]
> Sent: Thursday, January 15, 1998 5:32 AM
> To:   PICLIST@MITVMA.MIT.EDU
> Subject:      Re: I2C Slave Funtionality
>
> Najemy, Daniel wrote:
> >
> > Could you clue me in on the gotcha's relative to the PIC slave code?
> > The literature leads me to believe that the slave functionality
> > is all implemented in hardware.
> > It looks like all I have to do is read the data in the SSPBUF
> register
> > after receiving an interrupt to do so (if I have interrupts enabled
> > - else I could poll for it).
> > Check out my previous postings.
>
> The things that really ticked me off:
>
> 1: I wanted the PIC to run as a read/write I2C slave.
> So I used the R/W bit in the SSP to branch to the appropriate code,
> after every SSP interrupt. It didn't work.
> Reading the data sheet, a sensible person could reasonably assume
> this bit is R/W until changed by a new I2C message.
> WRONG.
> Its only valid after the interrupt caused by the address byte.
> After data bytes, it remembers the ACK/NACK bit.
> You can see how this screws it up.
> So I just copied R/W somewhere less volatile, for later use.
>
> 2: There is no way to read the ACK/NACK bit,
> according to the data book. Not that it tells you so, you find
> this out when you've spent ages looking for it.
> Thankfully, knowing the fix for the problem above, you do know now.
>
> 3: The SSP interrupts you after each byte has been sent to the master,
> and won't let the I2C bus continue till you load the SSPBUF.
> So how do you stop the damn thing?
> I thought "I'll send a dummy byte and maybe the master won't bother
> to fetch another". Zero crashes the system, because the SSP starts
> to put it on the bus but the master doesn't collect it.
> So you have to use a dummy byte of binary 1xxxxxxx.
> The msbit is set up on SDA, which doesn't jam the bus traffic.
>
> I think this problem may not arise if your master obeys the
> I2C spec rigourously by NACKing the last byte.
> Maybe then the SSP won't interrupt you for more data.
> The guy who could mod the master gadget talking to my PIC
> is too busy to fix it right now though.
> I'll leave this code (send dummy bytes if run out of valid data)
> as it makes it more tolerant of other people's programming faults.
> But be warned that the code to read to your PIC I2C slave should
> be thoroughly checked.