We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Further in the series of dumb questions I am too embarrased to identify myself as having publicly asked, is the following:
Should my boiler plate bit-banger I2C C code be able to be temporarily interrupted by other tasks at any point during communication?
Does the I2C standard permit brief pauses in bus activity, whilst the processor attends to more pressing duties?
Boz.
Certainly. But don't you have a peripheral to do it for you...?
Do notice that timing constraints are generally device specific. Check your data sheet.
Certainly, there are peripherals that can do this, but on some micros they are worse than useless (cough STM32 cough).
The I2C spec states no minimum clock frequency (in fact, if I remember correctly, it states DC to MAXFREQ), so provided you don't glitch the I/O lines during your ISRs, then there should be no problem whatsoever.
"Does the I2C standard permit brief pauses in bus activity, whilst the processor attends to more pressing duties?"
Generally yes, although in a multi-master environment, I would try to prevent interruption while SCL is high. If you allow pauses in the middle of a transaction, it's best to do so while SCL is low.
If using other I2C-bus protocols like SMBus for example, bus timing is important. SMBus devices could time out if the bus is not running fast enough or SCL is held low too long.