Touchscreen #883
Replies: 2 comments
-
Posted at 2016-09-11 by @allObjects Here it is, the calibration, resulting in a new module and a calibration function:
Related console output:
The calibration goes as follows:
Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-09-11 by @allObjects XPT2046.js module code:
Application using the (minified) module code from local Web IDE sandbox/modules folder. Note the touchscreen module
Related console output (tapping on markers on screen). NOTE the last 4 lines which lay outside of the display, because the touch screen has a pretty sizable porch at the bottom.
Note: This module is used in Modular and extensible UI framework and ui elements conversation. Attachments: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Posted at 2016-09-11 by @allObjects
In many previous projects I used a 2.8" TFT 262K Color LCD display with resistive touchscreen. Since the display had no touchscreen controller, I implemented one on Espruino (Resistive Touchscreen directly (no touch controller)). Recently I wanted to use the display again, but for whatever reason it turned out to be dead not only like a possum, but really really dead. So I ordered some cheaper ones of 2.2" size, since I needed them only to verify code for the ILI9341 display controller.
Surprisingly, the cheap(er) 2.4" display showed up with a integratred XPT2046 touchscreen controller from XPTEK TECHNOLOGY CO., LTD, SHENZHEN. After consulting the data sheet it seems that the XPT2046 is functionally equal to the Burr-Brown's / TI's ADS7843 and thus Espruino's ADS7843 module works... at least, it returns coordinates... dodged that bullet... even more easy...
But from there on in went tricky to say the least... and unfortunately ended with the conclusion: module useless (from the point of usable values,.. and more), because even though the user's touch accuracy is about +- 2..3 pixels, the module error is up to a horrible 32pixels... just not useful for a touch UI.
Why?
Below code and and attached shot show why. The code below sets up the display and the touch screen, then draws calibration markers in all corners and the center and then logs values for calibration.
The issues are:
ILI9341 initializes in portrait with x=0..239 - 240 pixels wide - and y=0...319 - 320 pixels high - and 0 / 0 top left (see shot).
XPT2046 controller is wired portrait, but not in a twisted way... not just rotated by 90 degrees... It could be fixed with the some additional calculation: with or hight - coordinate touch value.
it is not good enough to have an x and y offset for the controller function to calculate the actual x and y for a given display size. The offset helps with the touch screen not aligning with the display, but it messes up the scaling: if the low value is ok, the high value is too much off and vice versa. This can be seen in the output generated by above code when touching the calibration points from top left to bottom right.
Because many touch screens are larger than the display because they show fixed, printed buttons in the overhang area. For touching in the overhang, proper calculation returns values beyond the screen coordinates.
Produced output (aligned and with headings added):
Looking at x coordinate, the low value is about correct, but the deviation for higher values goes linearly up by about 10 per 120 pixels (half screen width). The 'balconies' or 'porches'
(screen vs display sizes and alignments) impact the calculation beyond what an offset can handle.
Same can be said for the y coordinate: after adjusting with an offset, the error is even worse.
Since the issues are hardware - wiring, size and alignment dependent, a module has to provide an option to pass a calculation function that takes minimum AND maximum touch values into account to scale properly with the display size. I'll take a stab at it and will publish in a next post.
Attachments:
Beta Was this translation helpful? Give feedback.
All reactions