atmuc wrote: ↑
Fri Nov 13, 2020 7:21 pm
I didn't understand the solution from your link. Do I have to use soft I2C?
kevinkk525 wrote: ↑
Fri Nov 13, 2020 10:13 pm
If you check the changes in ports/esp32/modmachine.c from that commit you can see that before this commit the I2C() was the SoftI2C so your code returned false because with id 0 you created a hardware I2C. After that commit I2C() is a HardwareI2C so your code returns true.
The other commit that explains this is https://github.com/micropython/micropyt ... 7232b2d101
Kevin's right but just to elaborate a bit to hopefully make the situation a bit clearer.
Before this change, machine.I2C was a soft I2C implementation, however it had some special magic (not very Pythonic -- you could only do this with metaclasses) that if you created it with an ID, then it actually gave you back an instance of the port-specific hardware I2C implementation. (There's no way from Python to get this type, other than to use type() on an existing instance).
So in v1.13
Code: Select all
i = machine.I2C(sda=, scl=, ...) --> software i2c, i is an instance of machine.I2C
i = machine.I2C(id, ...) --> hardware i2c, i is an instance of a hidden hardware I2C type
This is why instanceof returns false. Despite being constructed via machine.I2C, it's actually a different type.
The commit I linked to, followed by the one Kevin linked to makes it so that the behavior is inverted (and v1.14 onwards) and adds a new "machine.SoftI2C" (replacing the old machine.I2C), and then "machine.I2C" is now that port-specific hardware i2c type.
Code: Select all
i = machine.I2C(sda=, scl=, ...) --> software i2c, i is an instance of machine.SoftI2C
i = machine.I2C(id, ...) --> hardware i2c, i is an instance of machine.I2C
So... you don't need to change your code to use software I2C. But now (as of soon-to-be-released v1.14) you have the ability to tell the two types apart.