I find it more annoying that so many head down the SMBus route which is a subset of I2C, and users then complain when their I2C device won't respond to the SMBus commands.A lot of I2C devices use some form of "register" and/or "memory" abstractions that are totally missing from the library [edit: not true, let's say the lack of documentation isn't helping here].
In the kernel you do have regmap for I2C devices which does handle the address / data access pattern very well. I suspect that the I2C kernel devs look more at kernel drivers using I2C than the userspace side, and in truth kernel drivers are probably the right solution for many I2C devices.
Sorry, not a Python developer to comment on that side.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.
GPIO access from userspace was a bit of a mess whilst using sysfs, and that has only been cleaned up relatively recently with libgpiod.Still I find it strange that, while we have "canon" GPIO libraries, the same does not apply to I2C.
The I2C interface has been clean for a long time, so there is little need to add much extra stuff on top to make it usable.
And again, many I2C devices that get hacked from userspace would probably be better served as kernel drivers. You don't say what your clock generator and DAC are, but there are certainly a fair number of DACs supported in https://github.com/torvalds/linux/tree/ ... rs/iio/dac
Statistics: Posted by 6by9 — Mon Mar 31, 2025 10:20 am