I installed the trial version of Dietpi for OrangePi zero 3. I installed Node Red and that’s it
https://flows.nodered.org/node/node-red-contrib-opi-gpio.
I followed the instructions as described but no result.
In the error console I get this message
Error: ENOENT: no such file or directory, open ‘/sys/class/gpio/export’.
Any ideas how to run and test the gpio?
mkdir: cannot create directory ‘/sys/class/gpio/’: Operation not permitted
/sys/class/gpio/ is deprecated and probably does not exists anymore on newer images.
you can check with ls /sys/class/gpio.
You would need to use a library like WiringPi or pigpio.
edit:
To make it work with node red you can do (untested):
apt install pigpio python-pigpio python3-pigpio
npm install node-red-contrib-pigpio
Once Dietpi is developed for orange pi zero 3 will GPIOs be supported?
I’m not sure this will happen.
They are supported, but not in the way you tried.
As I said, using /sys/class/gpio is deprecated, see: https://www.thegoodpenguin.co.uk/blog/stop-using-sys-class-gpio-its-deprecated/
In 2015, the /sys/class/gpio interface was moved from ‘testing’ to ‘obsolete’
This ABI is deprecated and will be removed after 2020. It is replaced with the GPIO character device.
There are more reliable ways today to achieve gpio communication.
What will you recommend?
Ping @MichaIng
1 Like
Try this:
WiringPi is actually deprecated as well. The Orange Pi “wiringPi” repo and node-red-contrib-opi-gpio likely works with their vendor kernel only (which we do not use). The modern generic GPIO library is libgpio. Not sure whether there is proper support for this SBC, but just test it:
apt install gpiod
gpiodetect
Not sure about node-red-contrib-pigpio and pigpio, whether it is generic or for RPi only? Actually based on the description of the source repository, it looks like Raspberry Pi only: GitHub - joan2937/pigpio: pigpio is a C library for the Raspberry which allows control of the General Purpose Input Outputs (GPIO).
Interesting that the sysfs interface is not there with the Armbian kernel builds. It is official deprecated indeed, but still widely used and somehow … simple to script etc, hence Armbian enables it by default. But kernel configuration is a per-SBC thing. I can check the and patch the config, and create a new kernel form this. Whether node-red-contrib-opi-gpio will then work is another question.
GPIO and its interfaces is always a difficult topic with mainline kernel, sometimes it works OOTB, sometimes not, sometimes after enabling some device tree overlays. With plain GPIO, sometimes the pins are falsely addressed internally, e.g. we know this from the Odroid N2 (if it was not fixed in the meantime). We are not kernel developers, and I am just starting to learn a little about and do kernel builds, rebasing sources and fixing conflicts which pop up. But when it is about internals, names and addresses of SBC/family-specific device nodes, I am pretty much lost.
1 Like
Or apply generic GPIO line names via an DTB overlay and start writing device agnostic code that can run unmodified on any device with similar used GPIO line names. This can be implemented by any system administrator without requiring a feature request from their distribution provider. But this is probably too easy and not hacky enough. Sorry, couldn’t resist.
I like to hear what’s wrongly mapped:
meson-g12b-odroid-n2-plus-con1.dtso.txt (1.6 KB)
1 Like
Oops, I’m not that good at this stuff.
I think this is a joke. If everyone starts writing, where does standardization go? I also want to share that each pin has its own opinion when loading Dietpi. Tested.
And why does everyone ask for libraries to be able to write new device-specific code for their application? Even you, and then complain that existing libraries are not portable.
It exposes the functionality to which it is wired in the DTB. It can vary depending on the use case for which a particular implementation is intended, and by default this is not always the one desired by any user.
And that’s exactly why the Devicetree exists, it allows the binary code to obtain the neseccary information for an use case without having to rewrite the code itself (generic code).
I think we have a fundamental different understanding about what is “simple”, especially for the average DietPi admin 
.
The main problem is not so much the syntax how to name GPIO lines, but to know which line refers to which GPIO pin (can be found out with tool and time, I know), and if even every pin is addressed. IIRC on Odroid N2, most pins were not addressed at all, so naming would not have helped.
Just to understand your overlay: the part of the name behind “con1-” is the pin number?
Did you think about contributing this as base DTB patch to Armbian? Any naming that gives a hint about which line is which pin, optionally even which purpose/interface (which can change and is not device-agnostic of course) is better than the current situation and cannot break anything, is it? 
1 Like
Do you really want to say that commands like:
fdtoverlay --input sun50i-h618-orangepi-zero3.dtb --output sun50i-h618-orangepi-zero3.dtb sun50i-h618-orangepi-zero3-con1.dtbo
or
ln -s sun50i-h618-orangepi-zero3-con1.dtb sun50i-h618-orangepi-zero3.dtb
are over the head of an DietPi admin?
This is all that is required for overlay management. And above all, it has no dependency on the firmware, everything takes place in user space. For recurring tasks and for NOOBs, this can also be packaged very well in scripts that allow an appealing operation.
For this purpose, there are schematics or connection assignments:
Of course, everyone uses their own labels, but amazingly, they all use pin numbers as a common denominator. They have a certain recognition value even without further prior knowledge.
Of course, all of them are wired to correspond to the currently active DTB, but without easy access to the corresponding DTS you can only guess what that is. And by modifying the DTB, the wiring can even be changed dynamically.
Exactly, and con1 stands for the first expansion plug, because there are also devices with more than one. Of course, everyone uses different label, but I address the connector with the Raspbery Pi layout with con1.
This means that such a command will address the same pin 8 on all devices:
gpioset --toggle 100ms,100ms,100ms,100ms,100ms,300ms,300ms,100ms,300ms,100ms,300ms,300ms,100ms,100ms,100ms,100ms,100ms,700ms --consumer panic con1-08=active
My system only scales for a few devices as you can see from the ls-dtb log of my kernel package. If you explain to me how this fits into the Armbian system with its single device per image concept, without ending in a maintenance disaster this can be maybe considered.
Meanwhile, I prefer a one image for many devices concept.
ls-dtb.log (22.2 KB)
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.