Is it critical to interrupt i2c operations by INTs?

[40inD]

Is it critical when i2c operations are interrupted by INT_RB with buttons debouncing delay or by INT_RDA with filling ring buffer? Will be i2c readings/writings correct?
i2c is HW at 100 kHz and quartz is 20 MHz.

The same question i have for 1-wire operations.

[Ttelmah]

Which I2C operations?.
Master or slave.

Generally, on master transmit/receive it has no effect at all. On the transmit, you as 'master' are timing the bus. If using the hardware, the data rate, clocks etc., are all controlled by the hardware, and an interrupt makes no change at all. The worst that will happen, is a tiny extra delay between individual transactions. The same applies when receiving as a master.
Using software I2C, an individual clock can be slowed, but again this makes no difference. I2C, does not have a 'minimum' speed for the clocks, and slowing one does not matter at all. If using SMBUS, then there is a minimum speed, so if another interrupt delayed things massively, then there could be a problem, but this would involve another interrupt taking hundreds of times the time that should be needed for basic tasks like serial handling (remember the mantra, that all interrupt handlers should just handle the job the interrupt is signalling, and exit ASAP).
You talk about 'debounce delay'. There should _never_ be a delay in an ISR (except for possibly a few machine cycles). If you want a debounce delay, disable the INT_RB, enable a timer, exit INT_RB, and re-read the keys when the timer interrupts.

On a slave, things are potentially different. Here the hardware must be used, and the master is timing things. This is where 'clock stretching' must be used. Though the master controls the basic timing, and the hardware receives the byte, when INT_SSP triggers, the _master_ is expecting a response. As a slave, the slave hardware will (with normal settings), 'hold' the clock line low, until the slave has handled the transaction, and read/loaded the buffers. Hence if there is a delay in this handling, there is not a problem (provided clock stretching is used). However try to work without clock stretching, and there could be problems...

Which particular one wire protocol?. Maxim?. Here timing does matter, and the PIC does not have hardware to handle this. Whether an interrupt will cause problems will depend on how fast the processor is and so just how long the other interrupt takes. However because of the CRC if the driver is properly written and the transaction does not complete successfully this will be 'known', and you can just retry. The alternative is to disable the serial interrupt, but unless the data rate is low, this risks problems with the serial. A lot depends on the 'nature' of y9our serial comms. So (for instance) you will see systems that deliberately handle one wire transactions immediately 'after' completing receiving a serial packet, since they 'know' that another will not come at this point.

[40inD]

yes, i2c is hardware master and 1-wire uses Maxim protocol.
Thanks.

[Ttelmah]

The one wire might give problems, but primarily do look at getting rid of any delays in interrupt handlers, these are not really good practice. I don't actually consider INT_RB to be a good way to handle keys. Better to just use a timer at a short interval, and poll the keys. INT_RB can trigger so many times on most keys that it can cause problems.