Is it absolutely necessary to use C? - I mean, if you are uncomfortable with it and you apparently are more comfortable with asm, you might better get rid of this one unknown in your task and concentrate on the I2C itself. Note also, that the code you have is an intermix of 4 cases - master transmitter, master receiver, slave transmitter, slave receiver - which you don't need to work simultaneously. And it's not easy to guess the purpose of all those pre-chewed empty function skeletons, so I would simply get rid of them first.

In fact, majority of statements in that code is filling and reading SFRs, which is the same in asm.

Now, the key of the whole I2C stuff is in I2C.C. You don't need to go for the interrupt necessarily, if you can burn processor time freely (i.e. there is nothing else to do in the mcu until transfer is finished) - it might simplify at least the learning phase to do all of the I2C stuff in the "main". In the master, you can simply set the control register so that I2C is enabled and start bit is requested, then wait (poll) for the interrupt flag to come true. If it does, check the status for the appropriate state (to be sure), write the slave address to data register, clear interrupt bit and wait (poll) to come true. You might want to make various checking printouts via UART, just to be sure. Repeat for all bytes to be transferred, then issue a STOP.

As Erik said, this is the best to do with a 24Cxx-series EEPROM, you certainly have one somewhere around (plus the devboard for the LPC9xxs, you might have as well).

You can then try to proceed with the a similar interrupt-less version for the slave. At the moment you will be comfortable with all this, you will naturally move to the interrupt-driven version.


JW


PS. You said this is not the mcu of your choice - can you please tell which one would be?