SOLVED! I2c driver weirdness that wasn't the I2C driver..
A little history:
This is for a tester for an electromechanical device that communicates by I2C.
I had this working with Basic_I2C_Driver, but I was asked to get the I2C clock to 410 Khz to match 'real world' conditions.
So I found I2C PASM driver V1.8.od. which can be set to this clock.
I fixed a little bug in the readNext routine (Line 204), adding the low bit for 'read' to the device ID. And then I don't use this routine because of the DUT's nonstandard I2C usage.
I end up using the 'arbitrary' function for reading, and it works.
Now the problem:
The i2C driver seems to go into some mode randomly, sometimes writing, sometimes reading, where it 'paces' the individual bytes about 5 mS apart!
The attached Saleae 'logic' capture has one write where this happens, and one read, with some 'normal' exchanges in between. The read at the end caused my I2C program to miss a Cnt, with the customary 54 second 'freeze'.
The ACKs seem timely, it then just waits to send the next byte...
I have increased all my stacks to ridiculous sizes, and then doubled them, to no avail.
Any ideas? perhaps a different 'driver' (Although this one seems well-written...)
I have included the .sal file in the archive