I’m trying to use the Adafruit_Blinka Python library in order to get readings from one of Adafruit’s IMU products. My goal with this post is to understand if sudo is required in order to simply read from the IMU; ideally I can run a python script without sudo to get readings. The IMU itself isn’t relevant here, but rather using the Adafruit_Blinka library.
@RobertCNelson even weighed in and it looked like this particular issue was solved for Debian Buster images. However, I have a BeagleBone Green with the Debian 12.2 Bookworm image.
I was eventually able to run python -c "import board" successfully (no sudo) but it took some digging. I had to make a modification in order to run import board without a PermissionError to read the nvmem file. I found this comment here
I guess I’m troubled by having to do this just to run all this without sudo. I have a solution now, but it felt icky. Should I not have to make this change? Perhaps this deserves a new PR to the Adafruit_Python_PlatformDetect library? Or should I just suck it up and find a way to live with sudo in this case?
I just looked at their site, very impressive sensor, have not worked with that one. It is i2c. It says the sensor has absracted out the math using an arm core. That would imply to me it is sending out positional data that can be implemented as is. You might have to do some homework on this and find out how its framing up the data and just write your own code in c++ then convert it into a python module.
page 102 has the i2c info
$groups
If your board has an i2c group add it to your user.
You can also set the permissions to test it.
$sudo chmod 666 /dev/i2c-1
FYI, 666 is testing only, change it back after testing.
Yes, and that’s what I’ve done. The adafruit platformdetect library needed to read /sys/bus/nvmem/devices/0-00501/nvmem, and the udev rule I made changed the owner group to gpio with the default user is a part of. That worked in order to get past the permission issue. But now I seem to have a new problem where the nvmem device “address”—for lack of a better term—has changed to 0-00502. I have no idea why this has happened, and haven’t changed the underlying kernel nor any u-boot configuration or settings.
debian@BeagleBone:~$ tree /sys/bus/nvmem/devices/
/sys/bus/nvmem/devices/
|-- 0-00502 -> ../../../devices/platform/ocp/44c00000.interconnect/44c00000.interconnect:segment@200000/44e0b000.target-module/44e0b000.i2c/i2c-0/0-0050/0-00502
As a result, my board cannot be detected as a BBG by the library like I would expect. I can read the EEPROM just fine:
My hacky idea is to add a symlink to the 0-00502 nvmem device. But so far it hasn’t worked. Another way to get around this issue is to edit the library code itself to also check 0-00502. But both seem unnecessary and feel like band-aids.
If that is what it takes go for it. This stuff is complex, its not even worth thinking about how to get a solution. So many hours are lost trying to make things “right”, its not good. Main thing is if it works, and works to your systems design expectations. Be sure to test it more than you normally would and hopefully the true reason for that change will become visible. You don’t want surprises after the product is delivered to the customer. At the end of the day that is what matters the most.
This is pure conjecture, it might be some enumeration protocol in the kernel, what ever is generating the 0-00502 that is changing.