That shell wrapper looks like an init script, but apparently it isn't (hence you need to use sudo there; scripts run by init would not require this).
This seems to be a very clumsy way to do this; the shell wrapper does not serve any purpose that could not be better served by the python program itself. Get rid of that; if you want an init script ...
Found the solution here.
What you want to do is write a trusted I/O enabling program in C that allows access to only the desired ports, then uses execvp() to execute your script at the caller's address space. You'll then setuid root to the compiled I/O enabler.
Here's some sample code adapted from the above source (be sure to use an address block you don't ...
I have not played with the GPIO pins this way but based on lgeorgets second comment and this article, you must first set the direction of the pin to "out". The direction node is owned by root, so:
sudo sh -c 'echo out > /sys/class/gpio/gpio18/direction'
sh -c is needed here to execute that command in a root subshell. This is because sudo echo out > ...
You could use the kernel isolcpus option in conjunction with the taskset command.
On the Raspberry Pi reserve the core(s) you want to use by appending the following to the line in /boot/cmdline.txt.
E.g. to reserve cores 2 and 3.
Then use taskset to assign programs to the core(s).
E.g. to launch the Python interpreter.
taskset -c 3 python
It's as simple as noting that there's no WantedBy setting in that section. You've told systemd to enable the service, but not actually described which target should want it when it is enabled.
It is not wise to do this as an everyday practice. Let standard output be logged until it becomes an actual ...
In general, GPIO pins are highly hardware specific. There are no systematic names, no systematic drivers, no systematic registers.
The only thing you can do is read the information you have, google, and guess.
As your motherboard manual says there is a GPIO header, we can assume that the GPIO pins are actually physically routed somehwere (that's not a ...
I suspect, based on some various research that the user on the 2nd Pi is not a member of the gpio group. Fix that with:
useradd -G www-data gpio
(substitute www-data for your actual user, of course)
By the way, running sudo echo 1 > ... ends up writing "1" (the echo 1 is run as sudo, pointlessly) to the file as your non-sudo user, since the redirection ...
There is a post in the Raspberry PI page which details the process. I know this is a different device, but it should help:
According to this link, there is an utility called "generich3/GPIO" to perform that task.
Disclaimer: I have not read the latest gpio_keys code, just skimmed over it. Yet, I believe that there is a good explanation for the separation of GPIO keys from IRQs.
A kernel has an IRQ event table, so different events can be given to known IRQs. The list of events (callbacks, well actually pointers) is written into a PIC (a separate chip or integrated ...
The compiler has to target your ARM-based system. It doesn't have to be a cross-compiler — you could be running the compiler on the same or another ARM platform. The name of the cross-compiler is somewhat variable, so the instructions can't cater for all the names that people have used out there. For the intended audience of this document, this is a no-...
As lgeorget mentions as a comment above,
/sys is a pseudo file system provided by the kernel, if the kernel requires the writer to be root then this is a fixed requirement by the kernel and can not be changed by fiddling with attributes and owners.
This is explained in more detail with this answer on question : How to set permissions in /sys/ permanent ...
You do indeed need to load the correct GPIO driver module for your hardware. You may also need to load it manually (by naming it in /etc/modules) if it doesn't get loaded automatically (some don't because they're not "plug-and-play").
Lack of GPIO modules loaded into your running kernel is the reason why you don't have a /sys/class/gpio directory.
From the ...
The GPIO interface seems to be built for system (uid root) use only and doesn't have the features a /dev interface would for user processes. This includes creation permissions.
In order to allow user processes (including daemons and other system services) access, the permissions need to be granted by a root process at some point. It could be an init script, ...