Getting access to the 'tick' from pigpio for use in the DigitalStateChangeEvent #156
basil-dsouza
started this conversation in
Ideas
Replies: 2 comments
-
Have attached a patch with the changes i suggested above. "mvn clean package" completes successfully. |
Beta Was this translation helpful? Give feedback.
0 replies
-
@basil-dsouza why don't you send a PR, and then we'll check it out. The diff seems to now break existing code, but we should first try it out. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
TL;DR: There currently is no support for using the "tick" from pigpio in the digital state change event.
PiGpio sends a "tick" for any notifications of pin state changes (among other things I assume). The Pi GPIO plugin consumes that and adds it to the "PiGpioStateChangeEvent", However when converting that back to a "DigitalStateChangeEvent", the tick is lost:
I checked the create of this state change event, and it is done in 2 places, one is the above for input and another in: DigitalOutputBase for output.
For Input: You can simply set the tick in the code block sampled above. If you are worried about compatibility with other interface (not sure which) then you could set nanoTime() for those.
For Output: The best option here would be to set it to nanoTime(), since the output event originates in the calling system anyways, and not on the Pi. This does mean that you cant do a diff between input and output events (perhaps either a new flag, or a determination based on source to know if the ticks are comparable). The alternate would be to call the pigpio interface to get the tick after the write, not too keen on this. Wouldve been ideal if pigpio returned with a tick as part of the response to the write, but that is a much bigger change and would involving getting pigpio to make it as well.
The background is that I was reading through the code for the ultrasonic sensor in the crowpi examples and found it would be much simpler if it could just listen for state changes and then find the difference between the 2 tick events. Right now it has to go through all sorts of threading gymnastics and even then is prone to inaccuracies due to scheduling issues or general socket latency:
https://github.com/Pi4J/pi4j-example-crowpi/blob/62977aa4564bef6edd4fc50fa6c5feeafaadc0b0/src/main/java/com/pi4j/crowpi/components/UltrasonicDistanceSensorComponent.java#L240
Beta Was this translation helpful? Give feedback.
All reactions