Hi chaps & chap-ettes,

Has anyone else noticed this aspect of the PIC SSP in I2C mode:

1: When reading data from the SSP, it makes the bus wait
((by holding SCL low) until the CPU loads the data into SSPBUF
and then sets CKP. This is desirable behaviour.

2: When writing data to the SSP, there is no equivalent wait-state
insertion. This is not desirable.

This means that if you don't handle your interrupt and incoming data
byte pretty damn quick (c. 100 microseconds), the SSPBUF will overflow.
When it does this, it stops responding to its I2C device address.

Microchip have provided a hardware flag to indicate this condition,
(SSPOV, in SSPCON bit 6) but their engineer says there is no way to
clear this condition apart from reset.

Check out fig 11-18 and 11-19 in the PIC16C6X data sheet.

So let me get this straight: Microchip implement half the wait-state
hardware they should have done, implement hardware to tell you when
the lack of this hardware causes it to stop working, and this is
pretty useless because there is nothing the CPU can do to get out
of it?

This problem came to light when someone tried sending I2C data to
my PIC at the full I2C rate (100kHz). They have a Hitachi H8,
and tell me this has a properly designed I2C interface - i.e.
it wait-states the I2C traffic in either direction.

This is not the first time I've had cause to complain about
Microchip's half-assed product. If you sell a product, it
legally has to do what it claims. I'd like to know how they can say
they have an I2C interface. Where is the code they used to verify it?

Keith Howell, disatisfied PIC user who'll be recommending we use
some other chip for new designs. And we use a LOT of PICs... for now!
Are you listening Microchip people?