Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I2C can run into deadlock / has no timeout #119

Open
nicolai86 opened this issue Jul 21, 2020 · 5 comments
Open

I2C can run into deadlock / has no timeout #119

nicolai86 opened this issue Jul 21, 2020 · 5 comments
Labels
bug Something isn't working feature-request

Comments

@nicolai86
Copy link

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
Copy link
Member

Sh3Rm4n commented Jul 28, 2020

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 Sh3Rm4n added the bug Something isn't working label Jul 28, 2020
@Sh3Rm4n Sh3Rm4n changed the title Request for Guidance: I2C with timeouts I2C can run into deadlock / has no timeout Jul 28, 2020
@Sh3Rm4n
Copy link
Member

Sh3Rm4n commented Jul 28, 2020

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Member

Sh3Rm4n commented Mar 4, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working feature-request
Projects
None yet
Development

No branches or pull requests

3 participants