Taming the Touch of a hot XPT2046 of ESP32-2432S028 - 2.8" LCD CYD Board #7509
Replies: 1 comment
-
Posted at 2025-02-02 by @allObjects When I created the touch directly w/o a controller on an Espruino Pico - see Resistive Touchscreen directly (no touch controller) - I for sure did not have this issue. I picked a scan rate suitable for the ui application - AND - for Espruino's way of doing things. That was 10+ years ago... Nowadays, almost all displays show up with a controller that makes live - for the most part - easier an for sure code for sure shorter. Looking at the handling of the XPT2046 in Espruino 2V25.40 build for CYD ESP32-2432S028 2.8 LCD board it is on the high side when a lot of JS should run between events. Also, picking up a noise free - or low noise - event stream seems to be an issue, nature of the type of resistive touch screen. For certain applications you may like the controller hot, and for others just nicely humming. To get to that without global configuration of the XPT2046 as one-size-fits-all, envision a configurable pip - or filter - that also can take care of other things, like:
In a 1st as a 1st step, I want to explore the short and longer touching of a point - no move / drag, like hovering. In a seconds step, I want to explore the impact of a tamed event stream. The filter 'ignores' small moves - up to (configurable) 5 pixels - but counts them and lets one pass after incurring (configurable) 20 of them. With that, a move of 'the center' is still passed on to the application when trying to adjust the touch position slowly. These are the results for hovering with untamed, tamed, untamed, etc. touch value streams. For the first untamed sequence I show all values - with max deviation of 4 - for the subsequent I did cut some out to save space, since it is most of the time also just + or - one pixel around the initial touch value. Notice the the time between the events, the xy change, and finally compare the first x/y with the last x/y: even though there are streaks in one or the other direction, the overall difference in the end is a fraction of it. Untamed begins and ends
compared to the tamed begins and ends:
with a reduction of more than 90%:
and
'moved' is though a bit apples vs. orages, because it is not normalized against the time spent touching, but is still well in the 90%+ / 10%- range (despite the 'Parkinson effect'):
Noteworthy is the fact that the sum of the ignored small moves - the number in square bracket [n] minus 1 when > 0 - are the same as for untamed. These small moves that anyway only run around in circles do not need to be handled by a potentially complex and lengthy application logic... such as figuring in which graphical object or ui element the hover point lays, perform actions tied to this object/element, recalculating and redrawing, all repeatedly with not relevant difference as, for example, for a slider. Such savings are for the benefit of other JS 'threads' started by events that show up in the event queue.
Posted at 2025-02-02 by @allObjects 2nd, looking at the RED - untamed - and BLUE - tamed - drawings, we notice practically no difference in the 'quality' of the line in regard of steadiness or jaggedness. The reason is that the Absolute comparison could be achieved by a robot... I'm definitively not one, even though I tried to do the same movements twice or four (4) times, as the attached pictures in Post #1 show. Conclusion: Even simple filter as above can greatly contribute to the smooth operation of a Espruino JS application by taming the touch event rate that makes it to the application and this saving a lot of cycles for what is more pressing.*** This is the data that goes with the 1st attached picture :
Last but not least the code that produced the numbers and pictures. It uses the the espruino.com/ILI9341.js module's initialization code to get the display properly working for the hardware at hand. It waits for the very first event to start the Watching and recordingof events keeps going until
Posted at 2025-02-02 by @MaBecker Wow, thanks for sharing! This should go to c-source code (line 30-36). Posted at 2025-02-02 by @allObjects thanks for pointing out that the low level code that creates the system-to-JS event queue entry is of type Yes, in deed: these few lines should go into the system layer, and the That's very good news, and I hope it is not absolute, same as my ignoring is not absolute. To throttle on busy JS engine is good... A good JS application should take advantage of setTimeout() to allow break-ins of events that can influence the execution. It would be nice to have something like a JS-CPU-usage-in% (range 1..10, or 0.1....1.0, or...) made available to the application so that the application can adjust... (since we do not have processes w/ different priorities... haha). Posted at 2025-02-02 by @allObjects forgot to mention that the When challenged 10+ years ago by the implementation of touch directly in Espruino, I did some calibrations w/ multiple units... and for the type of unit it was pretty constant... but across types, it is different... The touch controller xy calculation from raw xy code is something like that:
where the espruino.com/modules/XPT2046.js delivers the raw values rx and ry. The low-level implementation does not have to do all what XPT2046 module does (of which a lot has already been implemented into the Espruino binary). Posted at 2025-02-02 by @MaBecker Here is a small test sequence to check if the touch is working as expected.
Attachments: Posted at 2025-02-02 by @allObjects @MaBecker, nice work... going for the corners of the dislplay as well as the corner of critical squares helps to find the formula. Unfortunately also the parallax-error comes into play, because a display is never looked at perpendicularly. For that reason, it is usually a user function - as you may remember from the first palm tops... (with the gray LCD display and touch screen with pen). I have done that in this post Resistive Touchscreen directly (no touch controller). Posted at 2025-02-03 by @allObjects @MaBecker, attached pic shows a circle where I touched with the pen and an arrow with the tip at the coordinates that the the touch controller delivered, and the pixel is made red. To be as accurate as possible, I intentionally made sure that the parallax-error is not the issue. With taking the most bottom right touch as an outlier, the error decreases on the x-axis (horizontal) more than on the y-axis (vertical). Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2025-02-02 by @allObjects
An XPT2046 - controlling a touch screen - can be setup hot and floods the Espruino System-to-JS event queue to the point of drowning and failing of the application(s). Quickly can lagging behind turn into drowned. The flurry of events can have negative effect in an applications, but slowing it down in general (by re-configuring the controller) makes it lame for the application(s) or part(s) thereof that need them speedy... or an application that needs multiple, different speeds at times. Btw, it is not just CYD's touch challenge, but any
touchable
device raises the same concerns.In this conversation I explore options for handling touch with a tamer - like a tiller tamer - and make the event stream suitable for a ui application, and, I show the effect - or non-effect - on free hand drawings.
Bottom line, a good (configured) tamer filters out a lot of noise - up to 90+% - without impacting free hand drawing fidelity. In attached picture you seer RED and BLUE drawings:
Both show about the same line quality, the blue - filtered one -is in some areas even a bit smoother, counter intuitively, because less data points lead to less smooth lines (below a certain limit for sure).
Btw, don't get blind sided by the number of lines of code you find in Post #3... The relevant code is in lines # 30..35. Also, take a look at Post #5.
Attachments:
Beta Was this translation helpful? Give feedback.
All reactions