I’m trying to set SPI access in Torizon, I’m using Visual Studio with Torizon extension, and I’m using libsoc to access SPI. The container is built and run ok, but I’m getting the following message in the debug console after calling libsoc_spi_init:
libsoc-file-debug: Permission denied
libsoc-spi-debug: /dev/spidev0.0 could not be opened (spidev0.0, libsoc_spi_init)
I suppose I need to add permissions to the torizon user to access the spidev0.0 file. How should I set these privileges in the dockerfile parameters? Is it possible to set the privileged run mode in the dockerfile?
I’m also aware that libsoc is deprecated and it shouldn’t be used. If I try to follow this example, I have the same problem: the container cannot access the spi file.
So we are working on eventually publishing a how-to guide on SPI usage with Torizon. But for the time being I think I can describe what you need to do to get access. There are two configurations you should need here. First of all you need to allow the user that is running your application on the device access to the SPI interface. Then you need to specifically allow access to a the device that you want to access, /dev/spidev0.0 in your case.
To do this with the Visual Studio extension you need to do the following:
Right click your project → properties
In Configuration Properties, click on Torizon C/C++ Application, right-click on the Configuration item and then .
Add RUN usermod -a -G spidev torizon command to “buildcommands” property. This provides the container user the necessary privileges to access SPI devices.
Also add the corresponding SPI device you want to use by adding /dev/spidev0.0 to the “device” property.
Give those configurations a try and let me know how it works out.
It worked, thank you very much. I still have to do some more testing, but CS/CLK/MOSI lines are already visible in the oscilloscope.
One last question, in the buildcommands property, how do you add multiple privileges to a specific user (i.e. gpio and spidev)?
All of our Debian containers are derived from this base so these permission groups get inherited. If you ever create your own container with no relation to this base you’ll need to additionally create the group as shown in the base Dockerfile. Then you can add the user to this group. Also these groups are not arbitrary they actually exist on the base TorizonCore OS outside of the container as well.
