I2C can run into deadlock / has no timeout

[nicolai86]

I struggle to use this crate to execute basic I2C requests with timeouts.

Can you provide an example on how to use the I2C abstraction with timeouts to ie scan the I2C bus for available addresses?

I'm using v0.4.3.

Thanks

[Sh3Rm4n]

Sorry for the late answer. How far have you come with your problem? For more responsive answer to questions like these I would like to point you to the official rust-embedded matrix channel. :)

But it seems like our i2c does block, if the slave does not answer. The Timeout error is also commented out, which is a strong indicator, that we do not provide a possibility to get out of this loop.

This is the part, where we need a timeout capability.

The reference manual RM0316 rev8 at 28.4.15 does not reveal any possibility to leverage the internal i2c hardware-periphery, which means we have to provide a method per software to stop the endless loop, when the slave is not responding.

I can only think of really hacky interrupt-trickery to work around this issue, so clearly, this is an oversight on the current implementation.

[Sh3Rm4n]

I've labeled this as bug and reworded the issue title, to make it more clear, that there is some modification of the current code needed to cover your usecase.
If you want to take a try solving this issue, PRs are always welcome! :)

[nicolai86]

I started looking into ways of solving this since async/ await doesn't rely on std anymore since 1.44, and then ran into issues getting an executor to run on cortex-m; is adding a dependency on an a crate providing an executor even an option if I wanted to explore the async/ await option?

[Piroro-hs]

Maybe simple counter based timeout (decrement the timeout counter value in busy_wait! loop and exit when the value reaches zero) is enough?

At least this is what ARM Mbed OS does.

[Sh3Rm4n]

NRF-HAL has a read_timeout() method for it's UART. Maybe we can do something similar here?