Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GPIOs too slow - RaspiGpioProvider.hasPin() needs improvement #158
I was able to toggle with a pin at ~600Hz on Raspberry Pi B+.
It is caused by expensive method RaspiGpioProvider.hasPin() that calls GpioUtil.isPinSupported() that calls isPinValid() that calls getEdgePin() that calls piBoardId() that opens file descriptors and is very slow.
I think we need different approach to check whether pin is available or not. Maybe the pin availability can be cached by some Hashmap or so.
Observed in 1.1-SNAPSHOT
Thanks for adding it to Release 1.1. I am new to Pi4J so I will have a not very clever question. Is method RaspiGpioProvider.hasPin() static or dynamic? I mean for for example Raspberry pi has a pin X and for this pin it returns true. But does it return false when I start using the pin X for let say PWM?
Just FYI: I got ~180kHz when I overriden hasPin() that now always returns true for my testing.
Here is the code that I used for testing:
Optimization now included in the 'develop' branch and in the Pi4J-1.1-SNAPSHOT builds.
On the Rpi2B ...
Before any changes. ~900Hz.
This is about as good as I have been able to get it with the current implementation without removing any safety valves. (checks for pin support, mode type, etc).
For users needing more speed out of the GPIO's form Java, I suggest using the WiringPi wrappers included in Pi4J. These static functions are direct calls to the JNI layer where WiringPi performs the actual work to change the GPIO pin state. This eliminates the overhead from the Pi4J GPIO interfaces. But note these direct JNI methods are far less forgiving if you make a mistake and may result in a program crash.
WiringPi example code: https://github.com/Pi4J/pi4j/blob/master/pi4j-example/src/main/java/WiringPiGpioExample.java
Later on, I added the