Let I2C blocking methods wait until STOP is sent.
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.
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?