Request: Resistive touch debounce filtering

[ImpulseAdventure]

As mentioned in #96 it may be helpful to add support for touch debouncing on the simple 4-wire resistive touch control mode (DRV_TOUCH_SIMPLE). I would still need to review the STMPE610 and XPT2046 touch driver modules/datasheets to see if they too might benefit (in my testing so far it didn't appear necessary).

@rrroonn wrote:

Also, have you considered adding a debounce algorithm to your touch events? I may just have a crappy test display, but it was a common one on eBay. It definitively needs some debouncing to make it useful with touch (button) input.
something like ..

is button being touched?
  has it been touched continuously for DEBOUNCE_TIME?
    then fire button TOUCH event
  else wait
else was button TOUCH event fired
  then fire button RELEASE event
end

I did a bit of experimentation and found that a debounce delay of 35-50 mSec is effective - at least for my test display.

[ImpulseAdventure]

For reference: touch debouncing was implemented in the diag_ard_touch_test diagnostic sketch. The filtering is currently implemented in a FSM within DoDebounce() and has a parameterizable filtering delay. I believe it should be relatively straightforward for me to integrate this into the core library, likely at the TrackTouch() function where touch transition events have been detected, and could be applied to any touch driver or device platform (not just 4-wire resistive touch overlays).

[JoshBeckmann]

I am also encountering substantial input glitches with a XPT2046 resistive touch display that I think would be resolved with debouncing. I see the DeDebounce() function you mention in diag_ard_touch_test. What do you think is the best way to get something like this up an running for a simple interface? Is the feature any kind of priority at this point for the core library?

Thanks again for your generous tool. And, thank you for your patience with my elementary questions!