Closed GithubuserSRL closed 4 months ago
This "problem" is more or less known. The point is, that using wiringpi on modern linux platforms is more or less obsolete and users are suggested to move over to the official new GPIO tools which directly interact with newer kernels. Therefore wiringPi is also more or less flagged obsolete and the original author does not release newer versions anymore (cf. https://hackaday.com/2019/09/18/wiringpi-library-to-be-deprecated/). Thought, there are third party developer which try to keep up for some more time. Nevertheless it would be IMHO a better option to move over your use-cases to use the new official gpio tools (cf. https://github.com/brgl/libgpiod) which are part of RaspberryMatic already. Thus, use commands like gpiodetect
, gpioset
, etc. to interact with GPIOs in future.
Nevertheless, I will try to see if I can integrate a newer version of these wiringpi forks which try to keep up. But in long term you should better switch over IMHO.
FWIW: WiringPi is back since Feb 2024 in version 3 and going strong on all current kernels and supported through all Raspberry Boards from V1 to 5 😉
See the current Releases
Already integrated wiringpi 3.2 for the next release, see https://github.com/jens-maus/RaspberryMatic/commit/bc1e1ecb218d5d9971bb8c47ddeb20f10dbaa38a
However, I am still not sure if it would not be better to use the native libgpiod tools since wiringpi still performs direct kernel access and therefore does not allow to lockdown a kernel. That's why I had to loosen the kernel security a bit to get it working again (see https://github.com/jens-maus/RaspberryMatic/commit/16850f74d119d56634431ab319a450308176de59)
"third party developer"? - I prefer the term open source developer. The interface of libgpiod is already included into wiringpi library and will be released very soon .
The interface of libgpiod is already included into wiringpi library and will released very soon .
That would be great of course if wiringpi could even be used on a locked down kernel like the native libgpiod tools. Looking forwarding so that I can enable kernel lockdown per default again...
Version 3.4 was release https://github.com/WiringPi/WiringPi/releases/tag/3.4 When wiringPiSetupGpioDevice(WPIPinType) is executed, the new Kernel GPIO Device is used. (examples 1-4: https://github.com/WiringPi/WiringPi/tree/master/wiringPi/test ) No need to change anything else. _pinMode(PMOFF) can release the line, if needed after using it.
gpio -v is testing kernel/system for access possibility's. But I'm not sure if it's accurate, shows strange behavior on Ubuntu 24.04.
Describe the issue you are experiencing
Mit der neuen Version 3.75.6.20240316 und der Hardwareplattform Raspberry Pi 5 lassen sich die GPIO´s nicht mehr ansprechen.
Describe the behavior you expected
Ich nutze zur Zeit einen RPI 3b+ mit 3.75.6.20240316 und kann die GPIO´s ansteuern. Mein Ziel war ein Hardwarewechsel von RPI 3b+ auf 5. Bis auf das ansprechen der GPIO´s scheint alles zu funktionieren. Da die Ansteuerung der GPIO´s für mich sehr wichtig ist, bin ich wieder auf die alte Hardewarekonfiguration zurück gewechselt. Auch mit dem aktuellen Firmwarerelease 3.75.7.20240420 hat sich das noch nicht geändert. Eine GPIO Readall Abfrage über Putty bringt beim RPI 3b+ das übliche Ergebnis mit der Konfiguration der GPIO-Pins. Beim der gleichen Abfrage unter dem RPI5 erscheint folgende Meldung : WiringPiSetup: Unable to open /dev/mem or /dev/gpiomem: No such file or directory. Aborting your program because if it can not access the GPIO hardware then it most certianly won't work
Steps to reproduce the issue
What is the version this bug report is based on?
3.75.6.20240316 und 3.75.7.20240420
Which base platform are you running?
rpi5 (RaspberryPi5, ARM64/aarch64)
Which HomeMatic/homematicIP radio module are you using?
RPI-RF-MOD
Anything in the logs that might be useful for us?
Additional information
X