Java Garbage Problem for GPIO


4 posts
by Speed Plc » Mon Mar 13, 2017 3:48 pm
Hi!
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
Posts: 3
Joined: Mon Mar 13, 2017 3:27 pm
by princec » Thu Mar 16, 2017 8:08 pm
Seems a bit unlikely.

Have you profiled it?

Cas :)
Posts: 31
Joined: Fri Sep 02, 2011 11:01 am
by tnoradam » Wed Apr 05, 2017 3:42 pm
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 !

Thanks.
T
Posts: 1
Joined: Wed Apr 05, 2017 3:18 pm
by clicky » Thu Apr 06, 2017 7:57 pm
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?
Posts: 193
Joined: Thu Oct 25, 2012 7:34 am