I’m running snapd on a Debian Jessie (armhf) and my snap needs to access to the GPIO interface. Unfortunately the core snap does not offer the gpio interface and my daemon is not allowed to write in /sys/class/gpio/*. Interesting here is that /sys/class/pwm/ works perfectly, without interface. Is there any possibility to get access? Any workarounds so I can continue the development?
$ snap version
snap 2.24
snapd 2.24
series 16
debian 8
kernel 4.4.13
PS: also the serial-port and i2c interface is missing.
As we don’t have hotplug support yet and thus cannot discover them at runtime we rely on all-snap images that use the gadget snap to declare such interfaces statically. As we start working on generic hotplug you can expect to see them work better in classic as well.
Is there any difference between accessing pwm and gpio from the snap perspective? Would a gadget snap on a classic image make sense just for offering the hardware access without the boot part?
Yes, I think they have different sysfs interface. The rule of a thumb is that if the way your software talks to something is different then it is a different interface.
we do not have support for gadget snaps on classic installs (yet) so this is a moot point, it would not work currently …
that said, there is support for gadget snaps planned in the future, and there is the dynamic interfaces that zyga mentioned …
but today, you have to create an all-snap image to get access to these interfaces.
Yes, the sysfs interface is different, but from a security perspective accessing low level hardware I don’t see any difference? Or is the pwm unhandled in the core and that’s the reason why I can use it? Just for understanding/bug finding
The security difference is not relevant. If I wrote a motor fan driver that requires PWM and I offer it for general use on any system that has PWM control it doesn’t matter that the particular security language that happens to describe PWM and GPIO is similar. When the user installs my snap they should be offered a choice to connect sensible PWM slots to the plug my snap understands.
That’s a good point and makes sense to me! So building a native ubuntu-core image for my platform would solve the problem using a gadget snap with pwm, uart and gpio definitions.
Is that possible to build an image on ubifs?
I don’t know. I don’t think anyone tried yet. From snapd point of view that’s all fine, as long as the bootloader can mount ubifs and mount stuff from there. You will have to see how the bootloader and snapd interact. Snapd sets bootloader variables and a special boot script in the bootloader, in the gadget snap interacts with those to set up the expected boot behaior.
The snap declares the gpio plug:
apps:
gpio:
command: gpio
plugs: [ gpio ]
Connect the interfaces like so:
snap connect mysnap:gpio pi3:bcm-gpio-7
snap connect mysnap:gpio pi3:bcm-gpio-8
After which the directories are accessible for programmatic control, for example you can set the pin direction file to "in"or “out” on this path:
path := “/sys/class/gpio/gpio” + pinNum + “/direction”
And set and read the value on this path:
path := “/sys/class/gpio/gpio” + pinNum + “/value”
I used a voltmeter to verify. On the Pi3, one voltmeter connector touches a pi3 ground pin, the other touches the bcm number of the gpio pin, and I see the changing value.
