defragster
Senior Member+
And the answer is . . . 42 . . . lines of code to activate interrupts on the Touch Driver.
UPDATED SAMPLE: onoffbutton3i/onoffbutton3i.ino
> Using PIN Interrupt results in NO POLLING when there is no touch, sets flag to allow reading/polling on next request.
> Using Timer Interrupt supports 'timed' POLLING to detect touch, sets flag to allow reading/polling on next request.
BOTH: Once touch detected the user code can call/poll as desired to track the touch while present.
Given Paul's dire warning - I really overthought this! When I took out the extra steps and checks - I don't see missed touches on T3.1.
Simplified:
> Use Pin Interrupt if specified (no time wasted to deactivate it)
> Or use Timer interrupt if specified
> Interrupt is either WAIT'ing or ACTIVE
> Two state flag for Interrupt: WAIT or ACTIVE
> no extra logic or code to slow the process
> This may explain why I never saw it until I plugged in a Teensy LC, will test again on LC.
> And on T_3.1 it explains why the more code and debug spew I added the worse it got.
Will post updated copy of driver lib code that handles this transparently [with edit to .begin()] to my Examples GitHub for testing ASAP.
UPDATED SAMPLE: onoffbutton3i/onoffbutton3i.ino
> Using PIN Interrupt results in NO POLLING when there is no touch, sets flag to allow reading/polling on next request.
> Using Timer Interrupt supports 'timed' POLLING to detect touch, sets flag to allow reading/polling on next request.
BOTH: Once touch detected the user code can call/poll as desired to track the touch while present.
Given Paul's dire warning - I really overthought this! When I took out the extra steps and checks - I don't see missed touches on T3.1.
Simplified:
> Use Pin Interrupt if specified (no time wasted to deactivate it)
> Or use Timer interrupt if specified
> Interrupt is either WAIT'ing or ACTIVE
> Two state flag for Interrupt: WAIT or ACTIVE
> no extra logic or code to slow the process
> This may explain why I never saw it until I plugged in a Teensy LC, will test again on LC.
> And on T_3.1 it explains why the more code and debug spew I added the worse it got.
Will post updated copy of driver lib code that handles this transparently [with edit to .begin()] to my Examples GitHub for testing ASAP.