Last night I tried coding for the READ_I2C function (my sub) and ran into a fair amount of trouble. I’m not sure, but I think it revolved around the repeated hits to the ACK sub, where I originally wrote it for writes only (see where I toggle the port looking for the ACK from the SDA on the I2C) and my not understanding (while I was head-banging the problem) that the PIC issues the ACK if it is the receiver (reading the I2C).

It was late and I didn't give it a fair chance. I'm sure I get it figured out. Still, I'm up for suggestions as to what 'should' be the I2C functions that I make. I think I've got things so fractured that it's both getting hard to follow the loops and I maybe re-writing code unnecessarily. I was thinking that I should write the functions (subs) like this:

OPEN_I2C with a R/W bit set for read/write keeping all aspects inside the sub, and I2C stays open after address until...

CLOSE_I2C will send a stop command to end single or serial byte reads and writes.

WRITE_I2C simply sends out a byte with ACK back from the I2C, I2C stays open for next WRIET_I2C.

READ_I2C simply reads in a byte with ACK from PIC, I2C stays open for next READ_I2C.

Does this sound like a logical way to breakup the I2C subs so that I can read/write both bytes and serial strings?

This would be easier if PBP had an open-ended I2C function (like CCS's C does) for long reads and writes. Not all EEPROMS have page write buffers and all EEPROMS have unlimited serial reads (less you roll it over). Think I should put a note in the suggestion box?