06-24-2019, 07:12 AM
(06-23-2019, 12:55 PM)Tim Curtis Wrote: According to the (i) help below the first change detected on the pin will trigger the command to be executed then the code will wait for Bounce Time ms before checking for another change.
"Bounce time in miliseconds (ms). This parameter is used to ignore all subsequent changes for the bounce time after the first change is reported."
-Tim
Oei....
That can result in unpredictable system behavior!
Specifically with very fast processing devices, as they see everything on these GPIO pins..
For all the FPGA boards, PLC's and other stuff we design that incorporate human interfacing, we:
- check on first change (assume it goes from 0 --> 1)
- wait a few ms (lets say 5..10)
- confirm if input has still same level / stable, on which it triggered (should be 1 in this case)
- Then execute the code.
- If the pin does NOT have the expected level (so a 0 iso 1) the firmware/software will judge that this
was just a glitch, and will subsequently ignore the event.
- as there is nothing executed, the system is ready instantly for the next event, there is no delay in system response.
This kind of filtering is not noticeable for humans, as it allows input frequencies of 100Hz easily...
But it kills for sure all anomalies picked up by slightly longer wires etc.
In the pretty (EMI) noisy environment we are in, we are immune for even the ion-implanter / wafer transport located next door
![Tongue Tongue](https://moodeaudio.org/forum/images/smilies/tongue.png)
From my design philosophy, I believe its better to have this de-bounce delay/check as described above in the front.
As it does the trick equally good in preventing "race-track" kind of behavior, with the advantage to also deal properly with spikes etc.
Regards,
Jeroen