After backing out and rebuilding up to including the onDowntouch event and investigating how to detect an onUpuntouch event, I ended up with a code containing the core elements shown below as listen() and read xy() methods (code uploaded as touch4.js). The read xy() method is not just for reading the coordinates onDown, but later also for possible dragging while touching (onTrack), and - last but not least - for 'untouch' (onUp). Since with every event time is provided in addition to the x-y coordinates, touch durations can be used to determine short, long, very long, and dobule touches or taps.
The code incorporates the suggestions from @Gordon. The essentials in a nutshell:
detect a touch by hardware event using setWatch() in listen() method- rational: no continuous polling; enter polling mode only while touching for tracking
eliminate the setTimeout() for reading x and y in read xy() method - rational: execution of the JS code provides enough time for the pins to settle on output for powering plane one and on input for analog-reading of plane two.
The above data shows the trouble in the untouched stage: untouched values are in the range of touch min-max values. Elaborating on different items - even bringing in the reading of the xy from the old touch2.js code with the 1[ms] timeouts, which worked before for detecting the untouched state - did not help. Just having dropped the continuous polling and the timeouts for a faster and cycle/time-leaner execution, I did not want to go back and increase the timeouts to may-be have success.
The analysis of the data - untouched values are influenced by the previously touched area - and the difference between touch2.js and touch4.js code - unintended output-clashes - made me think that there is not enough time to 'discharge' the previously powered plane sufficiently to be ready for reading.
Adding very brief input with pull-down on the reading plane pin AFTER powering the powered plane provided the solution. Somehow, the lingering capacities between the planes in combination with the very sensitive, input-/sink-frugal ADCs lead to the 'misreadings'. Below the xy() method with the added lines to sink-away lingering capacities, and the new, related output data.
pt.xy = function(callback) {
this.t = new Date().getTime();
digitalRead([this.yn,this.yp]);
digitalWrite([this.xn,this.xp],2);
pinMode(this.yn,"input_pulldown"); // <--- extra lines to sink-away
pinMode(this.yn); // <--- ...lingering capacities
this.x = (analogRead(this.yn)+analogRead(this.yn)+analogRead(this.yn))/3;
digitalRead([this.xn,this.xp]);
digitalWrite([this.yn,this.yp],2);
pinMode(this.xn,"input_pulldown"); // <--- extra lines to sink-away
pinMode(this.xn); // <--- ...lingering capacities
this.y = (analogRead(this.xn)+analogRead(this.xn)+analogRead(this.xn))/3;
if (callback) { callback.call(this); }
};
The new data show now untouched values that are comfortably outside of the range of the touched values.
The pin-set sequence can now also be optimized towards the added lines. Looking at in what state the pins are left by the reading of xy(), I reduced listen() to just the pulling hight the second edge of the powered plane and call the xy() before the listen() at connect. But for some reason, this made the watch() to trip on a regular basis without a touch happening (and triggered xy() showed also an 'untouch'...). So I left the listen and optimized only the reading of xy(). Playing around while optimizing, I also noticed that keeping the pull-down had no adverse effect, so I eliminated its removal. (The complete code for the touch initialization and touch onDown event detection is uploaded as touch5.js file.)
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
After backing out and rebuilding up to including the onDown touch event and investigating how to detect an onUp untouch event, I ended up with a code containing the core elements shown below as listen() and read xy() methods (code uploaded as touch4.js). The read xy() method is not just for reading the coordinates onDown, but later also for possible dragging while touching (onTrack), and - last but not least - for 'untouch' (onUp). Since with every event time is provided in addition to the x-y coordinates, touch durations can be used to determine short, long, very long, and dobule touches or taps.
The code incorporates the suggestions from @Gordon. The essentials in a nutshell:
eliminate the setTimeout() for reading x and y in read xy() method - rational: execution of the JS code provides enough time for the pins to settle on output for powering plane one and on input for analog-reading of plane two.
This is the output for touching the four corners ( 240 (x) px horizontal x 320 (y) px vertical screen):
bottom-right corner (x=239, y=319)
The above data shows the trouble in the untouched stage: untouched values are in the range of touch min-max values. Elaborating on different items - even bringing in the reading of the xy from the old touch2.js code with the 1[ms] timeouts, which worked before for detecting the untouched state - did not help. Just having dropped the continuous polling and the timeouts for a faster and cycle/time-leaner execution, I did not want to go back and increase the timeouts to may-be have success.
The analysis of the data - untouched values are influenced by the previously touched area - and the difference between touch2.js and touch4.js code - unintended output-clashes - made me think that there is not enough time to 'discharge' the previously powered plane sufficiently to be ready for reading.
Adding very brief input with pull-down on the reading plane pin AFTER powering the powered plane provided the solution. Somehow, the lingering capacities between the planes in combination with the very sensitive, input-/sink-frugal ADCs lead to the 'misreadings'. Below the xy() method with the added lines to sink-away lingering capacities, and the new, related output data.
The new data show now untouched values that are comfortably outside of the range of the touched values.
The pin-set sequence can now also be optimized towards the added lines. Looking at in what state the pins are left by the reading of xy(), I reduced listen() to just the pulling hight the second edge of the powered plane and call the xy() before the listen() at connect. But for some reason, this made the watch() to trip on a regular basis without a touch happening (and triggered xy() showed also an 'untouch'...). So I left the listen and optimized only the reading of xy(). Playing around while optimizing, I also noticed that keeping the pull-down had no adverse effect, so I eliminated its removal. (The complete code for the touch initialization and touch onDown event detection is uploaded as touch5.js file.)
Next steps are now to bring back all the complete onDown, onTrack - track while touching and possibly dragging - and optional on onUp support.
2 Attachments