When using Pi4J version 1.2, the installation of wiringPi is needed. wiringPi is a GPIO access library for the Raspberry Pi and is used by Pi4J to access the Raspberry Pi pins. wiringPi is used up until version 1.4 of the Pi4J framework. Since version 2.0 libgpiod is used to control the Raspberry Pi GPIO pins.
To install wiringPi on the Raspberry Pi, execute the command sudo apt install wiringpi. Version 2.50 of the wiringPi library will be installed. This is also the last official wiringPi library version, since this library is not maintained anymore by its creator Gordon Henderson. He has made another one for typical RPi4 changes but that never got distributed officially through sudo apt.
When using sudo apt install wiringpi, the libraries are installed in /usr/lib:
libwiringPi.so, which is a soft link to:
libwiringPi.so.2.61
libwiringPiDev.so, which is a soft link to:
libwiringPiDev.so.2.61
If you ever want to uninstall those libraries, run the command sudo apt --purge remove wiringpi.
In the meantime, as of this writing (2022/01/22) wiringpi is not even an installation candidate anymore. When I run sudo apt install wiringpi I get the following message:
pi@rb3bplus:~/mystuff/WiringPi (master)$ sudo apt install wiringpi
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package wiringpi is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'wiringpi' has no installation candidate
Strange to see that something that has been very useful in the past and that has taken a lot of effort and dedication of a person is so fast forgotten. A pity...
As said in the previous section, wiringPi is not maintained anymore by its original author Gordon Henderson.
In the meanwhile the source code has been picked up by other people and is having a kind of "second life". It's now available on GitHub using this link.
You can fork a copy of it to your GitHub environment and then clone this to your local environment. The following build commands are available:
./build: this builds all out-of-date targets and generates shared libraries (extension .so). The support for building static libraries is no longer available because of the following reason given by the original author:
wiringPi is no-longer shipped with the ability to statically link it.
Many reasons but the biggest issue is people who have statically linked
wiringPi into their product - for example a Pi UPS device or a Tetris-like
game and not subsequently shipped their modified sources. These people are
no better than common thieves with complete disregard to the conditions
of the LGPL that wiringPi ships with.
Additionally, many think it's a good idea to statically link wiringPi
into their favourite language - like Node, and Java and other itsy bitsy
little things. These people have a complete and utter disregard to what
happens underneath when e.g. the Linux kernel changes on the Pi then
wiringPi stops as it depends on some Pi kernel features, then the poor
user get in-touch with me and I've had over 10,000 emails so-far and
it's now beyond a joke.
DO NOT STATICALLY LINK WIRINGPI.
Gordon Henderson, March 2018.
This command will also implicitly install the libraries in the /usr/local/lib directory like so:
pi@rb3bplus:~/mystuff/WiringPi (master)$ lla /usr/local/lib | grep libwiring
0 lrwxrwxrwx 1 root root 22 Jan 22 10:09 libwiringPiDev.so -> libwiringPiDev.so.2.70
28 -rwxr-xr-x 1 root root 27844 Jan 22 10:09 libwiringPiDev.so.2.70
0 lrwxrwxrwx 1 root root 19 Jan 22 10:09 libwiringPi.so -> libwiringPi.so.2.70
72 -rwxr-xr-x 1 root root 69976 Jan 22 10:09 libwiringPi.so.2.70
Next to this, it will also install the application gpio into /usr/local/bin
The support for building static libraries is no longer available because of the following reason given by the original author (quite harsh...):
wiringPi is no-longer shipped with the ability to statically link it.
Many reasons but the biggest issue is people who have statically linked
wiringPi into their product - for example a Pi UPS device or a Tetris-like
game and not subsequently shipped their modified sources. These people are
no better than common thieves with complete disregard to the conditions
of the LGPL that wiringPi ships with.
Additionally, many think it's a good idea to statically link wiringPi
into their favourite language - like Node, and Java and other itsy bitsy
little things. These people have a complete and utter disregard to what
happens underneath when e.g. the Linux kernel changes on the Pi then
wiringPi stops as it depends on some Pi kernel features, then the poor
user get in-touch with me and I've had over 10,000 emails so-far and
it's now beyond a joke.
DO NOT STATICALLY LINK WIRINGPI.
Gordon Henderson, March 2018.
./build clean: this removes all generated objects but not the installed libraries in /usr/local/lib
./build uninstall: removes all installed libraries and applications (like gpio et all)
If you want to help to the development of wiringPi, the best thing you can do is clone the GitHub repository in the first place. Then do your modifications, push it to your forked repo on GitHub and ask for a pull request to get merged into the official GitHub repository of wiringPi.
I'm currently proposing the following changes:
By default, wiringPi is using only one /dev/i2c device: /dev/i2c-0 for older Raspberry Pi's and /dev/i2c-1 for most of the other Raspberry Pi's. However, when using an I2c mux like the PCA9548 on the Raspberry Pi, the Raspberry Pi has the ability to "detect" such device (built into the kernel, you only have to activate the functionality) and when present you get another 8 (!) I2c devices on top of the one existing.
Mostly, the extra I2c devices are numbered like so: /dev/i2c-11 ... /dev/i2c18.
So, to allow wiringPi to make use of those extra I2c busses I added a small mechanism to allow usage of those extra busses.
Therefore, I added a few extra functionsin the C code (unfortunately, C cannot overload methods):
wiringPiI2CSetupDevice() which takes an additional parameter dev pointing to one of the available I2c busses.
mcp23017SetupDevice() also taking an additional parameter dev.
Those changes do not break existing code. They will only be used in new code that wants to take advantage of the extra I2c busses. The existing functions will simply be forwarded to the new functions with a parameter that does not break original functionality. In other words, it's transparent to the current usages of the existing functions.