Will interrupts interfere with I2C comms?

WARNING: This is probably a newbie question ..

Will interrupts, 1 x timer and 1 x hardware pin related, interfere with I2C communications?

I aim to do a POV which uses a hardware interrupt to determine revolution speed and a timer interrupt to divide into the necessary resoltion for refreshing the LEDs. I would however like to read new display data, 512 bytes per image, from an I2C EEPROM while all of these interrupts are firing. Will the 'code' just move to the interrupt when needed and return to the EEPROM reading function when done?

At this stage I am not really concerned with the speed needed to read data. It will be fixed images with a slow rotation, done in code, while the next image reads. So two byte arrays, one being read from EEPROM the other being displayed (hope there will be enough memory!).

Should I set a volatile 'flag' on the interrupts to prevent I2C byte read while interrupt is completing or is that unneccessary?

I don't know if it makes any difference but I am using SPI.transfer to do the shifting..

Much obliged. :)

Will interrupts, 1 x timer and 1 x hardware pin related, interfere with I2C communications?

Yes and no. Interrupts, if not disabled, will interrupt everything (except other interrupts) but they won’t significantly interfere if they are written correctly.

Will the ‘code’ just move to the interrupt when needed and return to the EEPROM reading function when done?

Yes, that is exactly how interrupts are designed to work. So if the interrupt service routine is really short it should not interfere with the reading of the EEPROM.

Should I set a volatile ‘flag’ on the interrupts to prevent I2C byte read while interrupt is completing or is that unneccessary?

Things are usually done the other way around. The interrupt service routine typically just sets a flag to indicate that something needs to be done and then exits. The main program checks that flag, perhaps between byte reads in your case, and if it is set takes care of what needs to be done.

Don

An interrupt will not disturb the transmission of an individual byte, since this is done in hardware. And as long as the interrupt routine isn't terribly slow it will have returned by the time the EEPROM is ready for another byte.

Thank you very much, that puts many concerns to rest. An 'itstimetodo x' flag set by the interrupt it shall be.

I'll also arrange the timing such to try avoid the timer firing at the same instant as the hardware interrupt to give the main loop as little as possible to do on each cycle.

:)