-
Notifications
You must be signed in to change notification settings - Fork 232
I2C driver guidance/best practices needed #78
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
Comments
A simple but sort of gross solution might be to keep passing in the I2C reference to each method of drivers that might need to do IO. |
ah, I was looking for I2C in titles and missed that one... reading through it now :) |
Closing in favor of the other issue |
peckpeck
pushed a commit
to peckpeck/embedded-hal
that referenced
this issue
Nov 10, 2022
78: prep for v0.4.0-alpha.2 release (e-h 1.0.0-alpha.7) r=eldruin a=ryankurte Co-authored-by: ryan kurte <ryankurte@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
An I2C master instance can be used to address multiple devices, but all of the drivers effectively take ownership of the I2C object and prevent sharing it with other drivers to talk to other devices connected on the same bus.
LSM303DLHC , MCP3425 , SGP30 and HTS221 which are all listed first on the https://github.com/rust-embedded/awesome-embedded-rust list move in the I2C instance.
https://docs.rs/si5351/0.1.5/si5351/ takes a mutable reference.
I think we need some guidance/best practice recommendations to allow addressing multiple slave devices.
Does it make sense to advise hal implementors to build in some kind of interior mutability for this?
Do we need some other token/type to manage ownership of the I2C bus for the duration of some IO?
The text was updated successfully, but these errors were encountered: