stm32f4xx-hal icon indicating copy to clipboard operation
stm32f4xx-hal copied to clipboard

Let I2C blocking methods wait until STOP is sent.

Open zyma98 opened this issue 1 year ago • 1 comments

This commit brings back the while-loop waiting at the end of the blocking read/write methods on I2C. The while-loop waiting is necessary to ensure that the I2C interface has become idle before returning from the blocking read/write methods.

As an example, the following code might break without the while-loop waiting. Assuming that handle is a DMA handle to an I2C interface. After the first write method returns, without the while-loop waiting, the I2C interface can be generating the stop condition when the code reaches the second write method, which then fails the busy test self.busy_res()? and causes the second write to return WouldBlock.

handle.write(addr, buf); // Ok(())
handle.write(addr, buf); // Err(WouldBlock)

The added while-loop affects only the blocking methods and will not affect the non-blocking methods with DMA.

zyma98 avatar Feb 13 '24 00:02 zyma98

I am sorry that I introduced some bugs in pull request #737. The while-loops should not be removed.

However, we still face a dilemma whether we should also put while-loops in ISRs (handle_dma_interrupt) or not. If we do, then the ISRs will run for a longer time to wait for STOP to finish. On the other hand, if we do not put a while-loop, then an immediate following read/write operation through the DMA handle will return WouldBlock, even if no other party is using the I2C interface. This is pretty counter intuitive.

Which behavior is more preferable?

zyma98 avatar Feb 13 '24 00:02 zyma98