Open felipebalbi opened 1 year ago
You'll probably want to put the sht
in your locals, not i2c
. The shtc3
driver takes ownership of the i2c
.
This sounds like maybe an shtcx
issue. I've driven external i2c
devices in roughly the way you describe before, but have never used this crate.
It's weird that you're not seeing any activity on the external pins with a scope: especially since you're getting a NACK, which I think should only happen when a bus transaction was tried and failed.
Not sure how to help further without an SHTC device, I'm afraid.
You'll probably want to put the
sht
in your locals, noti2c
. Theshtc3
driver takes ownership of thei2c
.
I'll give that a go when I have some free time on a weekend.
This sounds like maybe an
shtcx
issue. I've driven externali2c
devices in roughly the way you describe before, but have never used this crate.It's weird that you're not seeing any activity on the external pins with a scope: especially since you're getting a NACK, which I think should only happen when a bus transaction was tried and failed.
If we have bogus pin-muxing, the I2C controller thinks it has driven the correct signals, but they have not propagated to external balls on the die. When waiting for an ACK, there was also no activity, then it signals a NAK and asserts interrupt signal. It can happen :)
Any status on this?
Does using TWIM1
rather than TWIM0
make a difference?
Hi,
I'm attempting to read from shtc3 sensor connected to microbit-v2 via i2c external pins. For testing, I'm using a minimal RTIC app with one task which received a local context containing the
Twim:<TWIM0>
instance which it uses to instantiate shtc3. When attempting to build the application, it results in unsatisfied trait bounds:If I move the code to
init()
, then it compiles fine, but there is no activity on the i2c external pins (checked with an oscilloscope) and every transaction results in a Nack.Is there anything else I need to do to get i2c_external to work? Here's a minimal version of my code: