Tom,
        Perhaps not all PIC part are created equal.  But I have implemented
the I2C slave using the PIC14000 and it has worked flawlessly.  It does
run under interrupt control, and as I recall there was one queer interrupt
at the end of each transmission where looking at just the I2C status bits,
you make the wrong conclusion as to what state you are in.  To fix this,
I set a flag to let me know that the next I2C interrupt is at the end of
a transmission, and then everything worked great.

Dave Reinagel
daver@cisco.com

> From tmariner@OPTONLINE.NET Fri Mar 26 06:39:20 1999
> Subject:      Re: PICs and I2C Specification
>
> The hardware module is better, but there are still a few pitfalls. We just
> ran into a condition in a Pic 16C77 where the SCLK is held low in the
> hardware slave RECEIVE mode. In the transmit mode, the Pic slave hardware
> holds the clock low to give time to retrieve the data to be transmitted, but
> no such feature is needed or specified for the receive mode. We think that
> the problem is caused by a combination of getting a succeeding transaction
> byte piling on top of one in SSPBUF, causing an overflow. The only way we
> could fix it was to either a) master clear the Pic or b)set the SSP module
> out of I2C hardware slave and then back in.
>
> Since the Pics are involved in intercity high volume data transport of data,
> in central offices, a hanging of the entire I2C bus is not all that funny!
>
> Two questions:
>
> 1. Has anyone run across this problem? and what exactly causes it (So we can
> stay out of those places.) We have a fix, but I really want to understand
> the mechanism.
>
> 2. Is there a less drastic way of curing the problem?
>
> Tom
>
> > From: Andy Kunz
> > Sent: Thursday, March 04, 1999 8:14 AM
> > Subject: Re: PICs and I2C Specification
> >
> >
> > >Beware : I2C slaving on the PIC is not a walk in the park.
> >
> > It isn't too bad if you are using the slave hardware, though.
> >
> > Andy
> >