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

Support different I2C addresses #40

Open
pkb-pmj opened this issue Aug 16, 2023 · 6 comments
Open

Support different I2C addresses #40

pkb-pmj opened this issue Aug 16, 2023 · 6 comments

Comments

@pkb-pmj
Copy link

pkb-pmj commented Aug 16, 2023

MPU9250 can have one of two I2C addresses: 0x68 or 0x69. That way you can use two MPUs on one I2C bus.
As far as I know, SPI doesn't have anything similar.
Is it possible to add this feature, given that the crate is built around SPI?

@little-arhat
Copy link
Member

This crate uses Device trait, and there are implementation of this for SPI & I2C. I2C Addr is hardcoded atm, but it's possible to make it configurable.

Feel free to add a PR (otherwise I'll take a look over the weekend).

@bofh
Copy link
Member

bofh commented Aug 16, 2023

Chip select signal is used to select device on SPI bus, so you need to have an output pin per sensor to choose to which to talk to.

@bofh
Copy link
Member

bofh commented Aug 16, 2023

But you right, we need to add AD0 support in I2C mode.

@little-arhat
Copy link
Member

Also, fyi, it's possible to share one i2c bus using smth like shared_bus: example.

@pkb-pmj
Copy link
Author

pkb-pmj commented Aug 17, 2023

I've just realized, it would have been hard if MPU9250 was also a trait, but since it's a struct impl, it can be different for I2C and SPI... and even already is.
So it's just a matter of adding address to I2cDevice and replacing i2c with i2c, address in all the "constructors", just like the existing spi, ncs.
I'll add a PR today.

@pkb-pmj
Copy link
Author

pkb-pmj commented Aug 17, 2023

Side note: I've never had a reason to read how nCS works, but that makes sense. You could also use AD0 in the same way xD
I would totally do that, but with 3 sensors on one bus it would require 5 pins, while two buses require 4.

shared_bus looks like it solves a different problem, which in Arduino/C++ doesn't even exist, you just pass Wire as an argument and don't worry about ownership as long as it does what it's supposed to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants