You have just 8 clocks in READ_EEPROM().

In MAIN_READ() you call READ_EEPROM() and then just finish with STOP. No 9th clock support there....

In MAIN_READ_FLOAT() you call the READ_EEPROM() repeatedly and then have kludged in a 9th clock which you only do on the first three bytes and then you just finish with STOP....

I see that STOP() has been kludged up with an extra pulse of the clock which may cover some cases but it does not assure the SDA level during this clock pulse....

And in MAIN_WRITE_FLOAT() you call repeatedly to WRITE_EEPROM() which does in turn have a call to ACKNOWLEDGE() but then you have the ending STOP() call that gives you that pesky extra clock pulse.

----------------

You would do well to restructure this code to turn your byte shift routines each into routines that handle 9 clocks and deal right there with the ack bit. In the write routine (shift out) fetch in the ACK bit at the 9th clock and return it from the routine so the higher level can see if the write was accepted or not. In the read routine (shift in) use an additional entry argument to specify the value of the ACK bit to send out and pass that from the higher level caller.

Take out that confusing extra clock in your STOP() routine and purge the routines ACKNOWLEDGE(), and I2C_CLOCK_CYCLE(). It would be better to simply put the clock cycle pulse logic right into the shift out and shift in routines that do 9 clocks each.

I would also encourage you to consider passing the full address as a 16-bit entity from the highest level routines and then separate that into the low/high bytes in the called routine. This will make the calling process much easier to understand instead of seeing two separate bytes of address hard coded into the subroutine calls.

Lastly you really need to re-think several issues.

1) There is no logic here which deals with the fact that the multi-byte routine MAIN_WRITE_FLOAT() may experience address wrap around when the start address is near the end of a page in the EEPROM. Data will end up not where you expected it.

2) Placing the delay to cover the 10 millisecond Write time at the highest level of code is going to come back and bite you every time you try to re-use the lower level routines for storing a series of bytes and you forget about the need to wait after writing. I would either go the extra step to implement the Write Completion polling that these parts support or put the delay somehow into your EEPROM driver. It can be a performance hit to certain programs to always wait for write complete each time you write something since that time can be put to good use elsewhere in your program. So there is a scheme that takes care of this as follows. At the end of each write process you set a timer interrupt counter to a non zero value of say 10 or 11 or 12. In a separate timer interrupt ruunning at 1 millisecond period you decrement this timer if its current value is not yet zero. Then each time you go to the routine that will write a sequence of bytes you check this timer. If it is non zero you then hang in a wait till it is zero thus letting some previous write complete. So if you write one block and then go off to do other things you have no wait penalty. You end up waiting in those instances where you come back to do another block write within the 10 millisecond write completion time.

Michael Karas