Page 1 of 1

Java Garbage Problem for GPIO

Posted: Mon Mar 13, 2017 3:48 pm
by Speed Plc
We produce PLC software for Raspberry Pi. Cycle time extends while doing java garbage. Also Pi4J library causes the frequent operation of the garbage. I checked digital input statu for each cycle(my cycle less than 1 millisecond). Run only this code "if(Input.isHigh())" and Garbage running each second. Garbage running each 20 second without Pi4j GPIO command. :x

Re: Java Garbage Problem for GPIO

Posted: Thu Mar 16, 2017 8:08 pm
by princec
Seems a bit unlikely.

Have you profiled it?

Cas :)

Re: Java Garbage Problem for GPIO

Posted: Wed Apr 05, 2017 3:42 pm
by tnoradam
I did not deep dive it, but I think I have a similar problem. Using the latest rPi3B /w the latest raspbian, installed eclipse and bound in the Pi4J libraries. I wrote a Java code that pulls data off a sensor (DHT-11) via a timed bit sequence. Since nothing ever worked right, I abandoned all further programming and inspected the data read in on one pin via gpio.
Basically, I initiate a data transfer by telling the sensor H->L, then it starts spewing out bits. Supposedly, the bits are preceded by a 50us low. A "1" is a 70us high, a "0" is a 27us high.
All I do these days is record 5,000 read-in events - format them - and stare/analyze them. I come to the following conclusions:

- only 50% of the time, everything is well behaved meaning all bits can be read, and all times in the sequence have the same us/readcycle (calculated by 50microsecond / number of "0" counted for every bit)
- every other time I read the block, I get a much longer us/readcycle. Some of these are ok as I can recalculate everything based on the 50us/numberof0s, but why the heck is it suddenly slowing down ?!
- a lot of times, the timing changes somewhere within the bitsequence block. Meaning it starts out well behaved with 1.6us/cycle and then suddenly slows to 3.8us/cycle, and then goes back to 1.6us/cycle. Unfortunately, these events mess up the bit timing correction. As a result, I get maybe a 60-75% hitrate on the validity of the bitsequence read.
- the worst failures are where the system slows down during the 50us low, but then speeds back up while I am trying to read the 70 or 27us of the bit.

What can I do to ensure that this one particular tiny little reading command does not get interrupted by anything ?
Is there anything I can tell Java in the code before and after that command ?
Is there a method/library that would read in data on a pin, but also timestamp it ? With enough speed to make out 27us vs 70us ?

by the way, I tried the same methodology in python and inspected the data blocks. Same issue there. Yes it is a little faster, but it still changes reading speed randomly.

any help would be greatly appreciated !


Re: Java Garbage Problem for GPIO

Posted: Thu Apr 06, 2017 7:57 pm
by clicky
Not saying this is the way forward, but I've seen people using System.gc() calls when they think it is 'safe' to do garbage collection for hope they won't occur when they don't want them. Maybe you should give it a go?

Re: Java Garbage Problem for GPIO

Posted: Sun May 21, 2017 6:49 pm
by Speed Plc
I did not fully solve the problem. I found bug in Pi4J.
This command cause memory leakage. "if(InputPin.isHigh())"

I changed to this "if(com.pi4j.wiringpi.Gpio.digitalRead( xxPin Numberxx )==1){"

Before my garbage was running every second. Now garbage running every minute. This is good news.

Now i'm traying serial garbage, maybe better for small memory.

Re: Java Garbage Problem for GPIO

Posted: Wed May 24, 2017 12:55 pm
by clicky
Did you, by any chance, log that issue on:
If not - I don't mind doing it for you :)