This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

I2C Comms Interruptable?

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.

  • Should my boiler plate bit-banger I2C C code be able to be temporarily interrupted by other tasks at any point during communication?

    Certainly. But don't you have a peripheral to do it for you...?

    Does the I2C standard permit brief pauses in bus activity, whilst the processor attends to more pressing duties?

    Do notice that timing constraints are generally device specific. Check your data sheet.

  • Certainly. But don't you have a peripheral to do it for you...?

    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.