On Thu, Oct 22, 2009 at 11:56 AM, Alan B. Pearce
<Alan.B.Pearce@stfc.ac.uk> wrote:
>>> According to the datasheet, in Master mode:
>>> R_W =3D 1 -- Transmit is in progress
>>> R_W =3D 0 -- Transmit is not in progress
>>
>>Hmm, I don't remember seeing that, but I just quickly grabbed
>>a old 18F datasheet and didn't look up your particular PIC,
>>whatever that was.
>>
>>In any case, "transmit in progress" sounds different to me from
>>"SSPBUF ready to accept another byte", which is how you apparently
>>are trying to use the bit. =A0Isn't there some xxIF bit in one of
>>the PIR registers that is specifically meant to tell you when
>>SSPBUF can take another byte?
>
> Sounds to me like the incorrect bit is being checked too - but I also
> haven't checked the datasheet.
>
> BUT what it does sound like is that the I2C hardware is waiting for the
> slave device to respond with the 9th bit which is the acknowledge bit, and
> if that doesn't happen, then the second byte won't get transmitted.
>

In Master mode, the BF and R_W bits go high on a write to SSPBUF. BF
goes low after the 8th bit is written. After the 9th (/ACK) bit is
clocked in, R_W goes low and SSPIF is set. Seems to me that either one
of these bits can be polled to determine when SSPBUF can be written to
again.

On my scope, I can see that the slave does ACK after the first byte is writ=
ten.

I also wrote an interrupt-based I2C routine that acts on the SSPIF
flag, and this works just fine. I'm still curious to know why polling
R_W once doesn't work, but polling it twice does work...

-Scott

-- =

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist