Hello All,

I would like to ask for a little clarification with regards to interrupts.

Say I have two methods, readValueA() and readValueB(), which execute I2C based routines.

Each of these methods contains an i2c.write() (the command) followed by an i2c.read() (the response).

Lets say readValueB() is triggered by an interrupt during the execution of the code in readValueA() and execution of readValueA() is in between the i2c.write() and i2c.read(). Under normal circumstances this gets interrupted if I understand correctly?

Along comes readValueB() which starts with an i2c.write() in essence killing what readValueA() was doing, is this correct thinking here ?

If this is the case am I to assume that these types of operations should be surrounded with an disbale_irq() / enable_irq() ?

Kind thanks, Serge

OK, I realize that readValueA() and readValueB() should always be executed in user land and not during the interrupt callback. Hence the above is probably a moot point ....

But just to improve my understanding of things is the thinking above correct?

Thanks, Serge

Yes you are right. Normally i2c write-read operations use the i2c repeated start which does not release the bus. This can be simulated on the mbed with an extra parameter causing the omission of a stop symbol(forgot the name). This is probably not the whole story because there are still two calls (write and read) and I don't know whether these are interruptible. Let's assume they are not, an interrupt occuring during write will keep pending until write returns. The interrupt will still start its own write because it uses the same i2c interface (other masters can't do this). The safe way is to make the write-read sequence atomic. The crude way is to disable irqs before write and re-enable them after read. That is however not a good idea because it will block all irq including the ones from i2c. So you need a semaphore (a busy bit if you like) that gets tested and set before write and released after read. As also this bit can be accessed concurrently you have to guard this bit as well with enable/diable irq or resort to special instructions like test and swap.