Repository navigation
The future of this wiringPi fork #80
Description
I'm posting this an issue to state the goals for the wiringPi org with the hope that those qualified to help and those more invested in the wiringPi ecosystem might be able to help steer this project toward them.
It's important to me, despite my lack of personal investment in this project, that:
- This fork has some kind of future
- It's clearly communicated that this is an unofficial fork, but also the canonical public version of the sourcecode
- It's clearly communicated (perhaps in sweeping changes to the source headers) that this repository and the accompanying Discord are the canonical places to get help/support (not Gordon)
With respect to how this repository is maintained and organised, let's keep things simple and in order of priority:
- Tag releases to give ports a stable version to submodule/link against/etc
- Reduce busywork by adding continuous-integration and auto builds via GitHub actions
- Keep on top of bugfix PRs, new Pi versions, etc
- Consider new features and improvements
- Build & release new deb files, potentially replacing the rotting deb files - Drop wiringPi? It's bit-rotting RPi-Distro/repo#214
If you have a vested interest in keeping this wiringPi fork alive, and would like to join the org as a maintainer- let us know!
Activity
seamusdemora commentedon Nov 19, 2020
I'd like to see this wiringPi fork survive and thrive going forward. I have read Gordon's deprecation message - that's sad, but understandable. I wound up here because the
gitsources listed on Gordon's website don't appear to be functional any longer. I just have one question for now: what has happened to the GPIO Utility? Is it included in the sources here?merwok commentedon Nov 19, 2020
It is here: https://github.com/WiringPi/WiringPi/tree/master/gpio
The
buildcommand at the root of the repo runs make in all subdirectories, including gpio.seamusdemora commentedon Nov 20, 2020
@merwok: Thanks - I didn't spend enough time looking.
Another question: Apparently ver 5.5 of the Linux kernel will introduce new support for GPIO operations - it all sounds pretty nice (I've not tried it yet). Has the project team here made any decisions regarding the role these new 5.5 kernel features will play with WiringPi going forward? I've read at least one opinion that
wiringPiwill cease to be useful once 5.5 becomes "mainstream", but it seems to me there are always opportunities for software that makes hardware easier to use.seamusdemora commentedon Aug 8, 2021
A recent test posted on S.E. may add some impetus to maintaining and improving WiringPi. Briefly, the test results suggest that (by at least one measure) WiringPi's performance is an order of magnitude greater than the 2nd place library. Summarized briefly:
Gadgetoid commentedon Aug 9, 2021
Raw performance is useful in some cases, but doesn't exactly paint a fair picture with respect to RPi.GPIO which has to pay the cost of Python -> C on every single GPIO write. I'd venture that RPi.GPIO could attain speeds much closer to WiringPi if it implemented functions that kept the toggling entirely within the C domain.
Correct, cross-platform GPIO code should be written using libgpio and despite its performance WiringPi is largely an anachronism. If someone needs to toggle a pin at nearly 8MHz they're probably doing something enormously specific that shouldn't involve WiringPi at all.
WiringPi's USP was that it brought the Arduino-style of programming over to the Pi so that those users felt at home, and it does some pretty cool things with external devices mapped to virtual IO too. It clearly still has fans, users and software depending upon it and that's reason enough to keep it going.
seamusdemora commentedon Aug 11, 2021
When you need "raw performance" it doesn't matter if it's fair or not.
seamusdemora commentedon Aug 13, 2021
@merwok - my apologies, it was an error on my part.
joan2937 commentedon Sep 20, 2021
lgpio uses the new generic Linux /dev/gpiochip interface (libgpio to you).
pigpiod uses a client server model and each toggle requires a couple of network messages which accounts for the dramatic performance difference. It would be more sensible to compare against pigpio.
Gadgetoid commentedon Jan 19, 2022
P.S.A for stakeholders, the wiringPi package is now no longer included in Bullseye - RPi-Distro/repo#214 (comment)
A case could be made for re-inclusion with a build from this fork, but I don't have an opinion one way or another.
seamusdemora commentedon Jan 23, 2022
@Gadgetoid : Would love to see someone do that... I am so not-savvy on what makes open-source projects viable, but it seems to me that if there is no apt-installable package of WiringPi, it will, like the old soldier, "just fade away".
Gadgetoid commentedon Feb 9, 2022
More because I need them than for any other reason, I have tagged a release and uploaded 2.61 debs for arm64 (Raspberry Pi OS 64bit) and armhf (Raspberry Pi OS). Would appreciate anyone with the time to battle test these!
seamusdemora commentedon Feb 17, 2022
@Gadgetoid 👍 Where to find the debs & how do I install one - the RPi OS one. I've a fairly recently upgraded RPi 3B+ to use for testing.
FWIW, I'm certain my testing won't be thorough, but I have a few scripts that I can run.
Gadgetoid commentedon Feb 17, 2022
@seamusdemora sorry I'm too GitHub native and forget that the files get attached waaaaaaaaaaaaaaaay down underneath all the release notes.
Alternatively since you're probably 32bit
armhfyou can grab it from this link: wiringpi-2.61-1-armhf.debInstall with:
sudo dpkg -i wiringpi-2.61-1-armhf.debseamusdemora commentedon Mar 8, 2022
@Gadgetoid
The 2nd link - for the 32-bit armhf gets me only a 404. Also tried w/ curl on RPi with no luck??
It appears the 32-bit deb just isn't there??
25 remaining items
mwallner commentedon Mar 12, 2024
"as fast as it can be" => Not quite, but if that fits your needs ✔️
When aiming for control speeds above 20MHz, you'll most likely have to look at WiringPi again, though.
The whole point of keeping WiringPi maintained is that people do not have to migrate their projects to other libraries. We strive to support all hardware revisions so that you can take your project from Pi 1 all the way to Pi 5 without having to change the source code.
Also, think about all the other projects that have been created in the last 10+ years and rely on WiringPi. Without support for newer OS releases and the latest hardware revisions, those projects would become outdated or rendered broken.
rafael2k commentedon Mar 12, 2024
I don't get when you say "Not quite". It is indeed direct access to hardware. I read the code.
I still use WiringPi for legacy projects.
rafael2k commentedon Mar 12, 2024
Just a follow up of the last message, considering the source code for direct access to the BCM2835, BCM2712 and RP1 in gpiolib (below), how can WiringPi be "faster", as you seem to imply?
https://github.com/raspberrypi/utils/blob/master/pinctrl/gpiochip_bcm2712.c
https://github.com/raspberrypi/utils/blob/master/pinctrl/gpiochip_bcm2835.c
https://github.com/raspberrypi/utils/blob/master/pinctrl/gpiochip_rp1.c
GPIOLIB "top-level" interface implementation:
https://github.com/raspberrypi/utils/blob/master/pinctrl/gpiolib.c
I my head we'd use this to add support for Pi 5 to WiringPi... not somehow the other way around.
mstroh76 commentedon Mar 12, 2024
We are currently engaged in the process of developing additional documentation and conducting performance comparisons. However, it's important to note that our resources and time are limited, preventing us from parallelizing every aspect of our work.
mwallner commentedon Mar 12, 2024
Not implying, just stating what can be measured 😉
Even though two different libraries use the same method of DMA underneath, there may be still vast differences in performance based on the source layout of the library / branching topology etc.
(a little more detail in the corresponding blogpost)
Please note that these are preliminary results and we we're still in the progress of getting our head around things to consider, but as I stated above, when you're planning on doing some high-speed switching of GPIOs, WiringPi really is the go-to (at the moment of writing this).
rafael2k commentedon Mar 12, 2024
@ mwallner, if you could please read my message it would be nice. Yes, it can be measured, but none of the data you posted compares to gpiolib. Libgpiod has nothing to do with gpiolib, which is available at:
https://github.com/raspberrypi/utils/tree/master/pinctrl
If you need some high-speed switching of GPIOs, GPIOLIB is the way to go, not WiringPi.
rafael2k commentedon Mar 12, 2024
Btw, I really appreciate your work, I really like WiringPi and I think it is easier to use and it is really wonderful it is back (and I plan to contribute too, as I mentioned, as I was maintaining my own fork).
I recently ported a software from WiringPi to gpiolib (for the reference: https://github.com/Rhizomatica/sbitx-core/tree/gpiolib ), and I can not stand by the fact the WiringPi can be faster than Raspberry Pi's reference implementation gpiolib.
mstroh76 commentedon Mar 12, 2024
Thanks for the input, good to have a comparison to WiringPi implementation. I already did all the RP1 implementation by my self.
rafael2k commentedon Mar 12, 2024
Cool. I'll do a PR to your Benchmark repo with gpiolib code for testing.
Good stuff, thanks for the references.
rafael2k commentedon Mar 12, 2024
So, your implementation is indeed much faster! I did a quick and dirty port of the Benchmark to gpiolib:
https://github.com/rafael2k/Benchmark
While in Pi 4 the difference is not much, something is very slow in the Pi 5 gpiolib implementation. Now I got puzzled why. Will investigate further. Anyway... I'll revert to using WiringPi. Thanks a lot @mwallner.
mwallner commentedon Mar 12, 2024
I've realized that this issue will soon become too cluttered to be of any use, so I'm going to lock it down.
TLDR:
WiringPi is not dead. With version 3, a new group of maintainers took over, aiming to keep the arguably best GPIO library around for as long as possible.