1.8 KiB
sysfs
I2C
Byte order
All common libraries (smbus, digispark, firmata, i2cget) read and write I2C data in the order LSByte, MSByte.
Often the devices store its bytes in the reverse order and therefor needs to be swapped after reading.
Linux syscall implementation
In general there are different ioctl features for I2C
- IOCTL I2C_RDWR, needs "I2C_FUNC_I2C"
- IOCTL SMBUS, needs "I2C_FUNC_SMBUS.."
- SYSFS I/O
- call of "i2c_smbus_* methods"
The possible functions should be checked before by "I2C_FUNCS".
for further reading see:
- https://www.kernel.org/doc/Documentation/i2c/dev-interface
- https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/i2c-dev.h#L42
- https://stackoverflow.com/questions/9974592/i2c-slave-ioctl-purpose (good for understanding, but there are some small errors in the provided example)
Qotation from kernel.org: "If possible, use the provided i2c_smbus_* methods described below instead of issuing direct ioctls." We do not do this at the moment, instead we using the "IOCTL SMBUS".
Because the syscall needs uintptr in Go, there are some known pitfalls with that. Following documents could be helpful:
- https://go101.org/article/unsafe.html
- https://stackoverflow.com/questions/51187973/how-to-create-an-array-or-a-slice-from-an-array-unsafe-pointer-in-golang
- https://stackoverflow.com/questions/59042646/whats-the-difference-between-uint-and-uintptr-in-golang
- https://go.dev/play/p/Wd7hWn9Zsu
- for go vet false positives, see: https://github.com/golang/go/issues/41205
Basically by convert to an uintptr, which is than just a number to an object existing at the moment of creation without any other reference, the garbage collector will possible destroy the original object. Therefor uintptr should be avoided as long as possible.