Hans Kurscheidt Posted April 7, 2022 Author Share Posted April 7, 2022 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 0 Quote Link to comment Share on other sites More sharing options...
Solution schwar3kat Posted April 7, 2022 Solution Share Posted April 7, 2022 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). 0 Quote Link to comment Share on other sites More sharing options...
schwar3kat Posted April 7, 2022 Share Posted April 7, 2022 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. 0 Quote Link to comment Share on other sites More sharing options...
Hans Kurscheidt Posted April 8, 2022 Author Share Posted April 8, 2022 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?? 0 Quote Link to comment Share on other sites More sharing options...
going Posted April 8, 2022 Share Posted April 8, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
schwar3kat Posted April 9, 2022 Share Posted April 9, 2022 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. 0 Quote Link to comment Share on other sites More sharing options...
going Posted April 9, 2022 Share Posted April 9, 2022 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. 0 Quote Link to comment Share on other sites More sharing options...
usual user Posted April 9, 2022 Share Posted April 9, 2022 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. 0 Quote Link to comment Share on other sites More sharing options...
going Posted April 9, 2022 Share Posted April 9, 2022 @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. 0 Quote Link to comment Share on other sites More sharing options...
usual user Posted April 9, 2022 Share Posted April 9, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
Hans Kurscheidt Posted April 10, 2022 Author Share Posted April 10, 2022 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! 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.