I went the smbus3 way.
After reading various libraries' documentations I must have messed them up and I was convinced they were using bit-banging. Oh, well.
It works, but I find it far more cumbersome compared to the much "cleaner" Micropython's machine.i2c.
A lot of I2C devices use some form of "register" and/or "memory" abstractions that are totally missing from the library. I ended up creating a Micropython's I2C-like wrapper around smbus3.
The missing async support is also annoying.
It's not like you need non-blocking kernel support for that, there are plenty of reactor-inspired solution to work around it.
Still I find it strange that, while we have "canon" GPIO libraries, the same does not apply to I2C.
After reading various libraries' documentations I must have messed them up and I was convinced they were using bit-banging. Oh, well.
It works, but I find it far more cumbersome compared to the much "cleaner" Micropython's machine.i2c.
A lot of I2C devices use some form of "register" and/or "memory" abstractions that are totally missing from the library. I ended up creating a Micropython's I2C-like wrapper around smbus3.
The missing async support is also annoying.
It's not like you need non-blocking kernel support for that, there are plenty of reactor-inspired solution to work around it.
Still I find it strange that, while we have "canon" GPIO libraries, the same does not apply to I2C.
Statistics: Posted by morci — Fri Mar 28, 2025 7:48 pm