Hi Tim, > If libraries are getting in the way
It is. A Python library, de facto standard for GPIO on the Pi, shipped with the Raspberian distro, is pretty hopeless in this area. When it returns to asking the kernel for GPIO changes, it turns that into calling the user-supplied Python function. Asking the kernel may be a long time after the change occurred, so one can't debounce in software in the callback function, and it doesn't supply the new state, so one assumes (hopes) the value alternates between 0 and 1. The library has optional debounce logic; it discards all changes it learns of within N ms of the one that triggered the callback, regardless of whether it's a transition to 0 or 1. This means when the callback is called again, it can't assume the switch is the opposite state to last time depending on the parity of "debounce" transitions. Reading the switch state in the callback is a race because it may be different to what triggered the callback, and that change is still in the pipeline to trigger the callback again upon return. Ditching the library makes the code require more expertise so Terry is happier removing the possibility of bounce in hardware. Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2017-04-04 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
