Hi Kat,

appears to be working.

Welcome to Armbian 22.02.1  with Linux 5.15.32-sunxi64

System load:   19%              Up time:       0 min
Memory usage:  22% of 482M      IP:            192.168.1.37 192.168.100.1
CPU temp:      53°C             Usage of /:    24% of 29G
RX today:      39.5 MiB

[ General system configuration (beta): armbian-config ]

Last login: Wed Apr  6 11:04:11 2022 from 192.168.1.31
hk@orangepizeroplus:~$ uname -a
Linux orangepizeroplus 5.15.32-sunxi64 #trunk.0038 SMP Thu Apr 7 15:18:59 UTC 2022 aarch64 GNU/Linux
hk@orangepizeroplus:~$ ll /sys/class/gpio
total 0
-rwxrwx--- 1 root gpio 4096 Apr  7 20:56 export
lrwxrwxrwx 1 root gpio    0 Apr  7 20:56 gpiochip0 -> ../../devices/platform/soc/1c20800.pinctrl/gpio/gpiochip0
lrwxrwxrwx 1 root gpio    0 Apr  7 20:56 gpiochip352 -> ../../devices/platform/soc/1f02c00.pinctrl/gpio/gpiochip352
-rwxrwx--- 1 root gpio 4096 Apr  7 20:56 unexport
hk@orangepizeroplus:~$ echo 6 > /sys/class/gpio/export
hk@orangepizeroplus:~$ ll /sys/class/gpio
total 0
-rwxrwx--- 1 root gpio 4096 Apr  7 20:59 export
lrwxrwxrwx 1 root gpio    0 Apr  7 20:59 gpio6 -> ../../devices/platform/soc/1c20800.pinctrl/gpiochip1/gpio/gpio6
lrwxrwxrwx 1 root gpio    0 Apr  7 20:56 gpiochip0 -> ../../devices/platform/soc/1c20800.pinctrl/gpio/gpiochip0
lrwxrwxrwx 1 root gpio    0 Apr  7 20:56 gpiochip352 -> ../../devices/platform/soc/1f02c00.pinctrl/gpio/gpiochip352
-rwxrwx--- 1 root gpio 4096 Apr  7 20:56 unexport
hk@orangepizeroplus:~$ gpiodetect
gpiochip0 Permission denied
Segmentation fault
hk@orangepizeroplus:~$ sudo gpiodetect
[sudo] password for hk:
gpiochip0 [1f02c00.pinctrl] (32 lines)
gpiochip1 [1c20800.pinctrl] (224 lines)
hk@orangepizeroplus:~$ gpio readall
+-----+-----+----------+------+-Orange Pi Zero 2-+------+----------+-----+-----+
| H5  | wPi |   Name   | Mode | V | Physical | V | Mode | Name     | wPi | H5  |
+-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+
|     |     |     3.3v |      |   |  1 || 2  |   |      | 5v       |     |     |
|  12 |   8 |    SDA.0 | ALT3 | 0 |  3 || 4  |   |      | 5V       |     |     |
|  11 |   9 |    SCL.0 | ALT3 | 0 |  5 || 6  |   |      | 0v       |     |     |
|   6 |   7 |   GPIO.7 | ALT3 | 0 |  7 || 8  | 0 | ALT3 | TxD3     | 15  | 198 |
|     |     |       0v |      |   |  9 || 10 | 0 | ALT3 | RxD3     | 16  | 199 |
|   1 |   0 |     RxD2 | ALT3 | 0 | 11 || 12 | 0 | ALT3 | GPIO.1   | 1   | 7   |
|   0 |   2 |     TxD2 | ALT3 | 0 | 13 || 14 |   |      | 0v       |     |     |
|   3 |   3 |     CTS2 | ALT3 | 0 | 15 || 16 | 0 | ALT4 | GPIO.4   | 4   | 19  |
|     |     |     3.3v |      |   | 17 || 18 | 0 | ALT4 | GPIO.5   | 5   | 18  |
|  15 |  12 |     MOSI | ALT3 | 0 | 19 || 20 |   |      | 0v       |     |     |
|  16 |  13 |     MISO | ALT3 | 0 | 21 || 22 | 0 | ALT3 | RTS2     | 6   | 2   |
|  14 |  14 |     SCLK | ALT3 | 0 | 23 || 24 | 0 | ALT3 | CE0      | 10  | 13  |
|     |     |       0v |      |   | 25 || 26 | 0 | ALT3 | GPIO.11  | 11  | 10  |
+-----+-----+----------+------+---+---LEDs---+---+------+----------+-----+-----+
|  17 |  30 | STAT-LED |  OUT | 0 | 27 || 28 |   |      | PWR-LED  |     |     |
+-----+-----+----------+------+---+-----+----+---+------+----------+-----+-----+
| H5  | wPi |   Name   | Mode | V | Physical | V | Mode | Name     | wPi | H5  |
+-----+-----+----------+------+-Orange Pi Zero 2-+---+------+---------+-----+--+
hk@orangepizeroplus:~$

gpiod apparently cannot make use of the gpio group permission. WiringPi as usual.

 

I put it onto my "compiler engine" (Visual Studio 2022 CPP cross env w/ OPi0+ as target). I have a few long haul flights in Mai, so I don't want to risk messing things up. Therefore, I will stay w/ 5.10 on my production machine for the next 2 month. How will things move on from here? When and where will this become "regular" instead of nightly?

Thank-you very much to you and all the guys in the background (followed discussion on GitHub) for your swift action!!!!

Best Regards

hk

 

3 hours ago, Hans Kurscheidt said:

When and where will this become "regular" instead of nightly?

It should be in the next release cycle, which if I'm not mistaken could be scheduled sometime in May (I don't see a confirmed date in the documentation yet).

3 hours ago, Hans Kurscheidt said:

gpiod apparently cannot make use of the gpio group permission

I've not looked at permissions for gpoid.   The file would probably need to be tweaked to cover the device structure.

vor 10 Stunden schrieb schwar3kat:

I've not looked at permissions for gpoid.   The file would probably need to be tweaked to cover the device structure.

I just changed /dev/gpiochip* to group "gpio" as I did for sysfs, and gpiod now works w/out root priv.

Wouldn't it be a good idea to put the rules file for sysfs and /dev/gpiochip* into the normal distro??

Gentlemen, thank you very much for the topic raised.
I discovered libgpiod. Today I checked on orangepipc2. All the functionality described in the help for teams works. And I saw more advantages.

If the pin is configured as an input, then I get a timestamp about the event automatically.

Two different processes will not be able to access the pin at the same time.

There are more advantages.

19 hours ago, Hans Kurscheidt said:

Wouldn't it be a good idea to put the rules file for sysfs and /dev/gpiochip* into the normal distro?

Re:  /etc/udev/rules.d/99-gpio-group.rules and gpio group.

That idea seems sound, but it wouldn't be confined to a file and the security group for one SBC type or family and it would need someone to support it and document it.

I think that it would need to be supported by someone closer to gpio user space who is able to understand most of the possible supportable permutations and is closer to supporting and testing across all Armbian devices and families , possibly in the armbian-config space.   These are not areas that I am familiar with, and those developers that do work in this area are quite possibly  overloaded with higher priorities. 

My suggestion would be to craft a post in the feature requests forum, briefly describing the issue and how this was resolved for your user case, and suggest adding it as a feature or configurable feature, for Armbian build.   You could offer to get involved in the design/test process (or even get involved in development).  
Then see if it generates any interest. 

3 часа назад, schwar3kat сказал:

I think that it would need to be supported by someone closer to gpio user space who is able to understand most of the possible supportable permutations and is closer to supporting and testing across all Armbian devices and families , possibly in the armbian-config space. 

 

There are a lot of nuances for GPIO.
Example 1: In the documentation for orangepipc2 on the 40-pin connector, the 37 pin has different names. In the user description it is designated as PA20

and in the electrical diagram as PD11. I have a board and a voltmeter - the correct name is PD11.

Example 2: One of the advantages of libgpiod is the ability to refer to gpio by name, if implemented as described here: https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt

And the question immediately arises.

What names should I assign for pins if I describe a 40-pin connector in the device tree?

Some have a double or triple purpose.

 

In any case, I can only do this for orangepipc2, bananapim3, bananapia64. They are on my desk and I can attach a voltmeter and an oscilloscope to them.

1 hour ago, going said:

What names should I assign for pins if I describe a 40-pin connector in the device tree?

Maybe start reading this thread where I discussed it a long time ago.

If you then also create overlays for your devices with the same pin namespace, a repository for which portable GPIO programs can be written slowly arises, as long as the devices provide GPIO functionality on the same pins.

@usual user I must have asked a rhetorical question. I think there is no universal recipe. There is only a specific implementation for a specific task.

2 hours ago, going said:

There is only a specific implementation for a specific task.

The task of my discussion was to define a uniform GPIO naming scheme for the 40-pin connector of different devices, so that if e.g. user space addresses "con1-07", it does not matter on which device it is executed. It will always access pin 7 of the 40 pin connector. The mapping is done in an one effort via a devicetree-overlay and you get portable user space tools. However, this must be done in a collaborative effort, as no one has access to all devices to create the collection of overlays. Users can then reuse tools written for a specific task regardless of the current device and have no mapping problems like e.g. with WiringPi.

vor 19 Stunden schrieb usual user:

The task of my discussion was to define a uniform GPIO naming scheme for the 40-pin connector of different devices, so that if e.g. user space addresses "con1-07", it does not matter on which device it is executed.

This is in fact an excellent idea! the key word is UNIFORM

@going:

For the time being, gpiod can only handle PIO; why block something very useful for something which does not yet exist (UART etc. func. in gpiod) Today, Users have no chances to find the pin, they are looking for. One has to scroll through 645 pages of chip documentation to understand which logical pin is allocated in which chipset. After this, the user has to crawl through the schematics to understand which SoC-Pin is connected to which Pin-header. Names like con1-xy would make things clear right from the beginning!