Enhanced version of touchscreen

[mstrens]

I made some tests with my device.
I had a lot of issues to detect if a key was pressed or not and to get reliable data.
Even if I had acess to the irq pin, I saw that I could not used it. I nearly always got a level LOW so there was no difference between pressed or not pressed.
I collected lot of raw data reading 12 time X, then 12 time Y, then 12 time Z1 and then 12 time Z2 and finally I asked for a transfert of command 0X80 (to force a power down).
I noticed that first read of X is always 4096 (because it follows a 0X80 cmd).
The second read of X is often 0 (but not always) when not pressed. So testing on this is not reliable.

I noticed that Z1 is a much more reliable way to detect a press.

• when not pressed, Z1 is always 0 or nearly 0
• when pressed, it is much bigger that 0 (value depends on position of pressed)

Finally I implemented the following principle.
I made a fonction to read just one axis in consecutive way.
First this function make 4 dummy reads (to let voltage stabilise) and then it makes 4 other consecutive reads. For this second run, it calculates min, max and sum.
If the difference between min and max is less than a parameter (e.g. 30) it assumes that the average is correct and exit. Else it makes a new run of 4 consecutive reads.

The main function to get a positon becomes very simple:

• first it get the Z1 value.
• if Z1 is lower than a thresehold (e.g. 40) , then it consider that there is no press and it exit false
• if Z1 is higher, then there is a press and it get the X and Y values

I made my changes based on the Bodmer original version (keep the same name for functions) so it is compatible with Bodmer example.
There i no need anymore for getValid(); so I had to make very small changes in the calibration function too.

This seems to work fine so far in my case (much better than other versions)
In most cases, reading the touchscreen takes about 100 microseconds when not pressed and 300 when pressed. Probably, it is even possible to reduce those delays if we remove the first 4 time reads (it seems - at least in my case- that the noise on the signal is anyway much bigger than the time to settle and so checking on difference min/max of 4 values is probably enough).

Here my version; hoping it can help.

Touch.zip

[achillhasler]

Thank you for the work. I think we don't have the same (touch) chip. Do you know whitch chip you have?
I will refactor the Touch sources when i have time for that. So i can also inspired by your code. My Display is a Raspberry 3,5'' display with 480*320 resolution from www.joy-it.net. Bud i dont kwow the chip and i have only this touch display.

[mstrens]

I use this model
https://fr.aliexpress.com/item/3-2-pouce-320-240-S-rie-SPI-TFT-LCD-Module-D-affichage-avec-cran-Tactile/32960934541.html?spm=a2g0s.9042311.0.0.799b6c37iCxsnC

I think it has a XPT2046 chip which is the same (as far I know) as a Texas Instrument chip.
I do not know why the IRQ signal is wrong.

[mstrens]

FYI, I removed the first "for" loop (4 times dummy reading of the chip) and it still works well.
So the delays to execute the getTouch is now divided by 2 (about 50 us when not pressed and 120 when pressed).

[Bodmer]

The zip file version above is not a direct replacement, it generates errors on compile. A new supporting header Touch.h is needed. Make sure the existing examples continue to run.

I have have marked as a development discussion and will close it to avoid confusion.

Do continue the discussions.

[Bodmer]

I updated the library a while ago to multi sample x sand y. It does seem to improve the raw touch read consistency but it apears to have no effect after filtering by getTouch(). YMMV.

[mstrens]

If I understand correctly the application note, when you perform multiple conversions, you should use commands with the last significant bit set on 1 (in order to keep power on and so getting more stable voltages to read).
So e.g. instead of sending a command "0xDO", you should send "0xD1" (except for the last command sent in the function).
In order to reduce the noise on the signal, the code I wrote does not only performs multiple reads (I make 4 successives reads for X and for Y) but it also calculates the min and max and check that the difference between min and max is less than a parameter. If not ok, it performs a new set of 4 reads. if ok, it calculates the average (using just sum >> 2 which is the same as sum/4).

[Bodmer]

I use the XPT2046 data sheet here. Page 24 and Table 8 indicate the ADC is available instantly and thus there is not need to control PD0.

[achillhasler]

I have done my work see https://github.com/achillhasler/TFT_eTouch for new tochscreen dirver. In the User_Setup.h of TFT_eSPI you have to disable
//#define TOUCH_CS 16 // Chip select pin (T_CS) of touch screen

This CS is now used by the constructor
TFT_eTouch<TFT_eSPI> touch(tft, 16);

If you need documentation install doxygen and graphviz and build the documentation with the Doxyfile in directory docs

have a try
ciao Achill

[Bodmer]

Thanks. looks good.

I will create a test setup, but it will be a while before I can test it.

[Bodmer]

I have tried the library with an ESP8266 and ILI9341 screen with an XPT2046 fitted.

The raw sketch runs fine and seems to generate sensible values.

At the moment the ESP8266 just keep rebooting on the watchdog when trying the calibration sketch.

I know there is a bug in the TFT_eSPI library which is stopping the built in touch controller from working so that is not helping. At the moment the TFT_eSPI library indicates the screen is being touched all the time.

I will sort the TFT_eSPI issue first and then come back to test the TFT_eTouch library again.

[Bodmer]

I have repaired TFT_eSPI (it was stuck in SPI write only mode on the ESP8266).

I have only tried the TFT_eTouch library with an ESP8266 and ILI9341 screen which is quite noisy for output position. The raw function works fine and gives stable outputs.

The calibrate sketch puts marker on the screen then the ESP8266 reboots on the watchdog. I do not have the Penirq wired.

Have you tested the library on an ESP8266?

[achillhasler]

I have updated TFT_eTouch to ver 00.05.00 but now i need a interface change in TFT_eSPI.
Add static getSPIinstance() function to TFT_eSPI class, for getting spi bus used by TFT_eTouch.
On SPI default config, (VSPI Port) do not create a new var, use the SPI var exported by SPI.h Header file.
TFT_eSPI.h

 void     getSetup(setup_t& tft_settings); // Sketch provides the instance to populate
+#ifndef ESP32_PARALLEL
+  static SPIClass& getSPIinstance();
+#endif
  int32_t  cursor_x, cursor_y, padX;

TFT_eSPI.cpp

#if defined (ESP32)
  #if !defined (ESP32_PARALLEL)
    #ifdef USE_HSPI_PORT
      SPIClass spi(HSPI);
    #else // use default VSPI port
+-      SPIClass& spi = SPI; // use the predefined SPI variable which is defined by SPI.h
    #endif
  #endif
#else // ESP8266
+-  SPIClass& spi = SPI; // use the predefined SPI variable which is defined by SPI.h
#endif
+#ifndef ESP32_PARALLEL
+SPIClass& TFT_eSPI::getSPIinstance() { return spi; }
+#endif

The Conways_Life example supports yours and my touch implementation to see the difference.
With the edit_calibration example we can adjust the configuration and store it in FLASH. only tested on 480*320 display.

[Bodmer]

I have mode the changes to my copy.

The calibrate sketch throws compile errors due to some instance naming errors. When corrected the ESP8266 keeps rebooting.

Conways_Life example compiles but the ESP8266 keeps rebooting immediately after the calibration screen is drawn.

raw example compiles but never reports anything to the serial port, again I am using an ESP8266 and ILI9341 screeen.

[achillhasler]

I test that on a ESP32. i dont have a ESP8266, but why does it rebooting. Difficult to test on ESP32 there is no reboot. I test with a RPI_ILI9486_DRIVER display.

If you define TOUCH_CS in TFT_eSPI User_Setup.h my touch implementation is not used in the Connways_Life demo. Does ist also reboot on ESP8266?

[Bodmer]

OK, I will create a setup with an ESP32 and touch screen in the next few days and see how it goes.

[achillhasler]

There is a new version of TFT_eTouch whitch support ESP8266 chips. Have a try

[xfdr0805]

There is a new version of TFT_eTouch whitch support ESP8266 chips. Have a try

achillhasler/TFT_eTouch#5

need your help ,tks!