Not so in most of my designs with MCUs!!

I put most of the real time "work" of the MCU into periodic state machine tasks that are sequenced off a timer interrupt activity. I2C access goes on in an independant manner when called as needed from the "main loop". In many designs the main loop's function rests with processing commands from the outside where a request/response type design simply has a short delay to the response if the command involves an I2C type transaction. All things such as managing timers, input scanning, flashing, sampling, PID control and even computational state machines are handled in the real time foreground.

Bit banged I2C works just fine to dumb parts like serial EEPROMs even if interrupted mid-stream of doing a transaction.

So it really comes down to a case of careful design ahead of time. If you have an I2C device that must be involved in a critical real time way with the overall function of the MCU algorithm then the hardware I2C engine can be useful. However, to be honest I have various times done bit banged I2C access to serial EEPROMs even when the MCU had an I2C engine because doing so was easier, quicker and fast enough.

Michael Karas