Page 1 of 1

How can Java control GPIOs?

Posted: Wed Oct 23, 2013 4:29 pm
by b0b0b
Hi all,
I would like to know how can Java control RPi's GPIOs... I mean Java is actually running on JVM and obviously it has to interact with the operative system in order to access to in/out pins. Is this interaction entirely based on sysfs? Or are there other ways (for example making a system call)? And what if I must control a GPIO using Interrupt ad not a polling mechanism? Java itself does not provide interrupt.

What happens if I use PI4J? It seems that everything is based on sysfs.

Re: How can Java control GPIOs?

Posted: Thu Oct 24, 2013 1:58 pm
by clicky
Sorry for not replying earlier - completely missed it. Anyway, your questions are quite valid and I can answer some, to the some extent, from pi4j library perspective:

"Is this interaction entirely based on sysfs?"

I don't know. pi4j's (one, current) implementation is supposedly based on

"And what if I must control a GPIO using Interrupt ad not a polling mechanism?"

"What happens if I use PI4J? It seems that everything is based on sysfs."

But that doesn't necessarily mean that it will just pull values. My understanding is that the moment new value is available (interrupt serviced?) sysfs will have new value and return it to all streams reading from it (ref: ... nterrupt.c). Pi4j uses that behaviour and waits for read until timeout (10s) or new value supplied. If I am right (Robert S. can confirm or deny it) - pi4j does relay on interrupt for value changes, even if not directly servicing it.

BTW why would using sysfs be such a bad idea?

Also, as pi4j is nicely defined by interfaces I am sure we can have another implementation over time that could be more efficient and bypass sysfs...

Re: How can Java control GPIOs?

Posted: Sat Oct 26, 2013 6:14 pm
by b0b0b
Thanks clicky,
BTW why would using sysfs be such a bad idea?
Lets suppose that I have to handle 10 sensors connected to RPi, using only a polling mechanism would be a big waste of resources and maybe it can not guarantee to read all the sensor's value correctly. For example imagine to have a digital temperature sensor, if you miss reading a bit your measure will be inconsistent. As far as I know you can access to the GPIO x via sysfs only by open or close the file that rapresent the GPIO itself, so every time that I have to read a value I must access to it passing through the file system and (I think) this is not a optimal solution.

Look at the code ... nterrupt.c

Code: Select all

// attempt to access the pin state from the linux sysfs
// (each GPIO pin value is stored in file: '/sys/class/gpio/gpio#/value' )
snprintf(fn, GPIO_FN_MAXLEN-1, "/sys/class/gpio/gpio%d/value", edgePin);
fd=open(fn, O_RDONLY);
PI4J's interrupt mechanism seems to be based on sysfs too... so now I am curious to understand how OS maps every GPIO into sysfs. I know that RPi is not a microcontroller (as Arduino is), thus it will be interesting to understand its limits regarding I/O interactions.

Re: How can Java control GPIOs?

Posted: Fri Nov 01, 2013 3:11 pm
by clicky
From what I have understood from the pi4j native code, interrupts are handled somewhere deep in sysfs and state changes reported back all when they change. So, it seems, it is safe to rely on that mechanism instead of polling. You will get responses back only when state(s) change.

Polling large number of sensors through sysfs might be, as you said, a bit inefficient, but, on the other hand, you might be underestimating ARM processor on 800MHz (in comparison to AVR on max 20MHz).

It would be interesting to see comparison in CPU usage in both cases.

On slightly different note, I am quite keen to see pi4j re-organised in such way to GPIO support is just an interface where we might have several different implementations. As need arise (like what you are explaining here) we (all of us, here) might look in to more efficient implementations.

Re: How can Java control GPIOs?

Posted: Fri Nov 22, 2013 1:03 pm
by savageautomate
Yes Pi4J is using WiringPi and sysfs for determining GPIO pin change events. However, all this is happening at the native C layer and each pin being monitored gets its own monitoring thread. So it is much more efficient because all this work is pushed to the native layer and Pi4J/Java (via JNI) is only getting notification events when a GPIO state changes.

You can take a look at the native implementation for pin monitoring here: ... rupt.c#L79

Thanks, Robert