Hans Kurscheidt

Members
  • Posts

    25
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Hans Kurscheidt's Achievements

  1. 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!
  2. Let me more precise; pse follow the following simple recipe w/ gpiod V1.65+ installed: Power up Connect 1 Pin of your choice to GND using a patch wire Exe: sudo gpiomon -r -n1 -Bpull-up <chip> <offset> // rising edge, pull-up, exit after 1 event expected behavior: cmd should "hang" and wait for rising edge @ Pin Pull the wire expected behavior: cmd should exit w/ event and timestamp Reconnect the patch wire to ground, then Exe: sudo gpiomon -r -n1 -Bpull-up <chip> <offset> expected behavior: cmd should "hang" and wait for rising edge @ Pin failure: cmd exits immediately w/ false event and timestamp although there was no rising edge (Pin was wired to GND) Exe the same cmd a 2nd time w/out having touched the wire: sudo gpiomon -r -n1 -Bpull-up <chip> <offset> expected behavior: cmd should "hang" and wait for rising edge @ Pin Now pull the wire expected behavior: cmd should exit w/ event and timestamp Leave the wire open (Pull-up will pull the Pin permanently up Exe: sudo gpiomon -r -n1 -Bpull-up <chip> <offset> expected behavior: cmd should "hang" and wait for rising edge @ Pin failure: cmd exits w/ false event and timestamp although there was no rising edge (Pin was permanently high) all subsequent calls to gpiomon will fail w/ false event (behavior as "Level" Interrupt) The issue is most likely related to initialization problems. Pins can be connected to various points internally in the SoC. UART, I2C, PIO... as well to pull-up/down, Highend/lowend FETS, etc. To do this, an internal microcode needs to be executed in the chip. In many uControllers, the Pin becomes unstable during the execution of the uCode. I expect that upon each execution of the gpiomon cmd, the pin is newly initialized. The new 2nd & ff initializations could lead to a false rising edge flag in the chip register, which will then trigger a spurious interrupt, when enabled. I suggest to consider, writing the chip config registers only after reading them before and in case that the new config would be different, from what was read back, before. Attaching the wire/button to a pin leads to line bouncing effects. The rising edge flag in the SoC may be re-triggered during the ISR execution of the 1st rising edge. The next execution of gpiomon, which will enable interrupts again, will then be trapped by the pending int flag. Enabling interrupts in the SoC PIO should always happen, after making sure that there is no pending int-flag, somewhere. RGDS hk
  3. Hello, again, Nobody feeling responsible for this?? When this issue would be solved, gpiod V. 1.65 +newer could indeed become an acceptable utility replacing the depreciated sysfs feature for future development. RGDS hk
  4. 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??
  5. 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
  6. Dears, I have recently posted several issues wrt. OPi0+. GPIO (sysfs), armbian-config (bug confirmed by Igor), WiFi AP, GPIO event handling. Except for GPIO, where high activity is going on, I cannot find anything in "GitHub-issues" about the other problems, I have raised. I therefore would like to know, what would be the right place to rise issues? Here in the forum, or in GitHub? I mean "issues", not "how tos"
  7. Cannot set internal pull-ups! Moreover I don't want to go on "somebodies" git page to look for solutions, which may be abandoned, tomorrow. If the Debian Kernel makers decide to stop and remove a widely used i/f by surprise, they have the obligation to provide a widely working and well documented new solution for USERS ! I don't see anything like this. Forcing users to search git up&down, retro-engineer code and .h files is no documentation. And distributing a version of e.g. gpiod of 3-4 versions behind is no solution as well!
  8. WRT dtb editing. May be I am old fashioned, but an APP for me is supposed to run on the designed HW "as is" i.e. it has to bring its own capability to configure the necessary i/f at user space, making eventually use of middleware. In my case, I achieve this by using sysfs and WiringPi. Apart from the fact that armbian-config has a bug and edits the wrong dtb, disasembling, editing & recompiling a dtb file is not for the average user and would my App put into the situation, where its not runnable on OPi0+ boards from the shelve, anymore. Or do you think that M$ Office would be so successful, if the users had to go into the BIOS of their MoBo to fiddle around w/ something??
  9. @usual user What & where is gpio-event-mon, and does it use the internal pull-up? And where is the documentation??
  10. @going No! I use the OPi0+ on a PCB as MoBo as an EFIS w/ an Arduino Nano as analogue concentrator and GPIO extender w/ RS232, I2C, SPI, GPIO and a handful of sensors. Shutdown was just 1 function of it, I picked it as example, because its easy. The important issues for me to switch to the new i/f are the ability to use the internal pull-ups, because I don't want to make a new PCB revision w/ external pull-ups and a working event monitoring, which is not the case for gpiod on the OPi0+, as I stated before. The shutdown is initiated electronically w/ a MOSFET and an R/C combination & Optocoupler, where the MOSFET keeps the power 30 secs alive when the avionic switch is pulled off to enable a proper shutdown.
  11. Hi, just go and write in your preferred method a shell script, for a GPIO Pin w/ pull-up and a button, to initiate shutdown, when the button is pressed. In sysfs & WiringPi its about 10 lines of bash; hence I hope I'm asking you not too much. RGDS
  12. Sorry, doesn't work for me. Tried to make it executable, but no cure. Welcome to Armbian 22.02.1 with Linux 5.10.60-sunxi64 System load: 18% Up time: 0 min Memory usage: 26% of 474M IP: 192.168.1.37 192.168.100.1 CPU temp: 57°C Usage of /: 24% of 29G RX today: 111.6 MiB [ 0 security updates available, 37 updates total: apt upgrade ] Last check: 2022-04-05 17:24 Last login: Tue Apr 5 17:24:18 2022 from 192.168.1.31 hk@orangepizeroplus:~$ ll /sys/class/gpio total 0 --w------- 1 root root 4096 Apr 5 17:28 export lrwxrwxrwx 1 root root 0 Apr 5 17:28 gpiochip0 -> ../../devices/platform/soc/1c20800.pinctrl/gpio/gpiochip0 lrwxrwxrwx 1 root root 0 Apr 5 17:28 gpiochip352 -> ../../devices/platform/soc/1f02c00.pinctrl/gpio/gpiochip352 --w------- 1 root root 4096 Apr 5 17:28 unexport hk@orangepizeroplus:~$ cd /sys/class/gpio hk@orangepizeroplus:/sys/class/gpio$ echo 6 >export -bash: export: Permission denied hk@orangepizeroplus:/sys/class/gpio$ cat /etc/udev/rules.d/99-gpio-group.rules SUBSYSTEM=="gpio*", PROGRAM="bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio /sys/devices/platform/soc && chmod -R 770 /sys/devices/platform/soc'" hk@orangepizeroplus:/sys/class/gpio$ ll /etc/udev/rules.d/ total 12 -rw-r--r-- 1 root root 70 Oct 12 17:33 10-wifi-disable-powermanagement.rules -rw-r--r-- 1 root root 3449 Oct 12 17:33 50-usb-realtek-net.rules -rwxr-xr-x 1 root root 285 Apr 5 17:23 99-gpio-group.rules hk@orangepizeroplus:/sys/class/gpio$groups hk tty disk dialout sudo audio video plugdev games users systemd-journal input netdev ssh i2c gpio
  13. Hi Kat, your effort is highly appreciated! But you can tell'em in my name the following: Depreciating a widely used i/f is BAU, but replacing it w/ something not backwards compatible is already doubtful! Even if it was announced before, just switching it off and forcing a bazillion number of users rewriting their code is NOT AKZEPTABLE! It not just hits the sysfs users, it affects as well the large community of WiringPi users. It is not akzeptable, especially because the new i/f is not widely accepted; most users are not even aware of it. What RPI users think about it, one can read here: https://raspberrypi.stackexchange.com/questions/136479/confusion-with-libgpiod-and-the-gpiod-user-tools there is no alternative to gpiod and no documentation for different levels of expertise the current Debian distributes gpiod 1.3, which is for all practical purposes useless, if you want to do more than just blinking an LED. The current stable version is at 1.6.5. Even the gpiod V 2.0 nightly cannot work, due to kernel-driver issues in the driver for the Allwinner CPUs, as I have stated here: https://forum.armbian.com/topic/20166-opi-zero-h5-gpiodmon-generates-spurious-interrupts-upon-invocation/ Hence, most users are left in Limbo! I would at least expect that they create a switch so that old/new can be selectable at user level. That behavior wasn't #Expert, more #Amateur RGDS hk I just powered up my RPI and found that they are still on kernel 5.10; there might ba reason for this! $ uname -a Linux raspberrypi 5.10.103-v7+ #1530 SMP Tue Mar 8 13:02:44 GMT 2022 armv7l GNU/Linux hk@raspberrypi:~ $ ls -l /sys/class/g* /sys/class/gpio: insgesamt 0 --w--w---- 1 root gpio 4096 29. Mär 17:45 export lrwxrwxrwx 1 root gpio 0 29. Mär 17:45 gpiochip0 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0 lrwxrwxrwx 1 root gpio 0 29. Mär 17:45 gpiochip100 -> ../../devices/gpiochip1/gpio/gpiochip100 lrwxrwxrwx 1 root gpio 0 29. Mär 17:45 gpiochip504 -> ../../devices/platform/soc/soc:firmware/soc:firmware:expgpio/gpio/gpiochip504 --w--w---- 1 root gpio 4096 29. Mär 17:45 unexport More over, compared to OPI/Armbian, pse take note that there is a Group gpio (not root) which solves quite some ACL problems w/ gpio uname -a Linux orangepizeroplus 5.10.60-sunxi64 #21.08.1 SMP Wed Aug 25 18:29:57 UTC 2021 aarch64 GNU/Linux hk@orangepizeroplus:~$ ll /sys/class/gpio total 0 --w------- 1 root root 4096 Jan 1 1970 export lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/soc/1c20800.pinctrl/gpio/gpiochip0 lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip352 -> ../../devices/platform/soc/1f02c00.pinctrl/gpio/gpiochip352 --w------- 1 root root 4096 Jan 1 1970 unexport