Hardware I2C

[skimask]

I need to interface a PIC18F4550 to a 24FC512 EEPROM chip which uses an I2C.
The 18F4550 has hardware based I2C capability, but reading through that section of the data sheet has got me fairly confused.
Does anyone have any advice on using the hardware based I2C capabilities?

I2C is a bit of a pain in hardware. http://www.nxp.com/acrobat_download/...8/39340011.pdf
explains the inner working of I2C relatively easily.
Why hardware I2C vs. PBP's I2C handling?

[Kamikaze47]

This is for the same project that I was having difficulties with my interrupts interrupting SEROUT commands. I assume the I2CREAD and I2CWRITE would have the same problems when interrupted?

[skimask]

This is for the same project that I was having difficulties with my interrupts interrupting SEROUT commands. I assume the I2CREAD and I2CWRITE would have the same problems when interrupted?

I2CRead/I2CWrite can be as fast as the PIC and/or device can make use of them...
Same thing with SerIn/SerOut...if the PIC is set up to run fast and the device can run just as fast, they don't take up much time.
The I2C commands won't get interrupted by ON INTERRUPT but they would get interrupted by DT's fast interrupts.
I would think you could easily go into the I2C macro's and add a couple of lines to turn the interrupts on and off before and after the I2C command (or do it manually each time an I2C command is executed).

Forget that other link. I think this one is better:
http://www.i2c-bus.org/I2C-Primer.520.0.html

[Kamikaze47]

I am using ASM interrupts, as some of them are time critical. I also would prefer not to turn off the interrupts during I2C usage, as I don't want to miss any interrupt events.

I just found this on MicroChip's site. It looks helpful: http://ww1.microchip.com/downloads/e...tes/00989A.pdf

[skimask]

I am using ASM interrupts, as some of them are time critical. I also would prefer not to turn off the interrupts during I2C usage, as I don't want to miss any interrupt events.

I just found this on MicroChip's site. It looks helpful: http://ww1.microchip.com/downloads/e...tes/00989A.pdf

Looks helpful, but I'd suggest reading that other site on I2C and learn a bit about what has to happen behind the scenes for an I2C transaction to be successful.
I2C isn't like serial. You can't really just 'plug a byte' and assume the receiver got it (well, you can for a few things). There's a few steps involved (start, control, address, data, stop/ack/nak, etc). Some under PIC control, some under user control.

How time critical are those 'time critical' interrupts?
Keep in mind that I2C is a lot faster than 9600 baud serial...

[Kamikaze47]

Thanks skimask, i'll give it a read.

I guess when I think about it, they aren't extremely time critical. My main worry was about missing interrupt events. But I guess as long as the interrupt does trigger - say a millisecond late, that shouldn't impact the performance.

[skimask]

I guess when I think about it, they aren't extremely time critical.

It happens...more often than not.
You hear 'I need sub-nanosecond accuracy to time my slot cars!'...come on...do you really?

My main worry was about missing interrupt events. But I guess as long as the interrupt does trigger - say a millisecond late, that shouldn't impact the performance.

Well if I knew what the trigger and the items involved were, I might have a better idea laying in the back of my head on how to compensate...