XPT2046 touch controller input - Anyone have suggestions on using it?

[KurtE]

Sorry in advance, I am semi new to the zephyr world, and especially using it natively. My first introduction to Zephyr was through the ArduinoCore-zephyr code base. For several years now I have played a lot with the Teensy (PJRC -> Sparkfun) boards such as the Teensy 4, 4.1, Micromod (and earlier the 3.2, LC, ...), During that time, I have contributed to several of the display drivers.

Some of my current Zephyr experiments are up in my github project: https://github.com/KurtE/zephyr_test_sketches

Current experiment: Try adapting part of my ILI9341 display drivers to work with Zephyr, that does not use LVGL.
I currently have one hooked up to an Teensy Micromod board. I am using one of the displays I purchased earlier from PJRC:
https://www.pjrc.com/store/display_ili9341_touch.html which uses an XPT2046 touch controller.
I have also purchased the same display on eBay. Amazon...

The display code is currently limping along. I thought as a test I might port over a version of a simple touch paint,
which was originally in the Adafruit_ILI9341 library. I have since adapted it to the XPT2046 driver instead of the touch
controller that was on the Adafruit displays.

Code is up at: https://github.com/KurtE/zephyr_test_sketches/tree/master/ILI9341_touchpaint_xpt2046

This sketch allows you to drag your finger on the screen and it should show dots where you were touching in the color
chosen. Touching one of the color squares changes what color will display...

Currently I am trying to use the XPT2046 input class, and having issues, questions, etc. with it and wondered if others
have successfully used this and have suggestions on the proper usage. I have an instance of the touch class defined
in my app overlay:

/ {
	chosen {
		zephyr,touch = &xpt2046;
	};
};


&lpspi4 {
	transfer-delay = <50>;
	status = "okay";	
	pinctrl-0 = <&pinmux_lpspi4>;
	pcs-sck-delay= <25>;
	sck-pcs-delay= <25>;
	pinctrl-names = "default";

	cs-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>,  <&gpio4 8 GPIO_ACTIVE_LOW>,  <&gpio2 17 GPIO_ACTIVE_LOW>, <&gpio1 30 GPIO_ACTIVE_LOW>;
...
	ili9341atp_spi_dev: ili9341atp_spi_dev@1 {
		compatible = "vnd,spi-device";
		reg = <1>;
		spi-max-frequency = <30000000>;
	};
...
	/* 26 is CS 27 is Interrupt */
	xpt2046: xpt2046@3 {
		compatible = "xptek,xpt2046";
		reg = <3>;
		int-gpios = <&gpio1 31 GPIO_ACTIVE_HIGH>; 
		touchscreen-size-x = <1000>;
		touchscreen-size-y = <1000>;
		min-x = <0>;
		min-y = <0>;
		max-x = <4000>;
		max-y = <4000>;
		spi-max-frequency = <1000000>;
		status = "okay";
	};
};

There is some callback code in my main source file:

static void touch_event_callback(struct input_event *evt, void *user_data)
{
  printk("TECB: %u %u %u\n", evt->code, evt->value, evt->sync);
  if (evt->code == INPUT_ABS_X) {
    touch_point.x = evt->value;
  }
  if (evt->code == INPUT_ABS_Y) {
    touch_point.y = evt->value;
  }
  if (evt->code == INPUT_BTN_TOUCH) {
    touch_point.pressed = evt->value;
  }
  if (evt->sync) {
    k_sem_give(&sync);
  }
}
INPUT_CALLBACK_DEFINE(touch_dev, touch_event_callback, NULL);

Which currently I do receive some events, which I currently just display in a loop:

    for (;;) {
      k_sem_take(&sync, K_FOREVER);
      USBSerial.printf("TOUCH %s X, Y: (%d, %d)\n", touch_point.pressed ? "PRESS" : "RELEASE",
        touch_point.x, touch_point.y);      
  	}

Note: the Arduino Code, that this is based on is up at:
https://github.com/KurtE/ILI9341_t3n/tree/master/examples/touchpaint_xpt2046

And uses the library: https://github.com/PaulStoffregen/XPT2046_Touchscreen

Issues/Questions:

Converting touch coordinates to screen coordinates:
I know my above stuff is incorrect within the overlay, but it is unclear to me what to do.

In many cases with these screens, the touch panel and the pixels man not be in the same orientations.

That is with these displays, the Screen is in portrait mode (240x320), but the touch is in landscape orientation.
And each sketch(app) might be setup to change the display orientation.

With the Arduino code base: The library simply returns the touch coordinates in RAW mode, and we convert. From the
Arduino sketch:

#define TS_MINX 337
#define TS_MINY 529
#define TS_MAXX 3729
#define TS_MAXY 3711
...
// Retrieve a point
  TS_Point p = ts.getPoint();
  // Scale from ~0->4000 to tft.width using the calibration #'s
#ifdef SCREEN_ORIENTATION_1
  p.x = map(p.x, TS_MINX, TS_MAXX, 0, tft.width());
  p.y = map(p.y, TS_MINY, TS_MAXY, 0, tft.height());
#else
  
  uint16_t px = map(p.y, TS_MAXY, TS_MINY, 0, tft.width());
  p.y = map(p.x, TS_MINX, TS_MAXX, 0, tft.height());
  p.x = px;
#endif

Note the above are somewhat rough, but gives the general idea.

Any suggestions on ways to do this with using Zephyr?

Receive data while dragging finger(pen)
Currently it appears like, I might get two events per finger pressed. The press event and maybe a release that gets sent
by a timer. During that time it appears like the interrupt is disabled. So wondering how this is supposed to work
for things like I am doing or, for things like scrollbars, etc?

Looks like the timer code maybe tries to recheck if the button is still pressed?
It might simply be that it is not being sampled fast enough. I believe the Arduino library he limits the
time between checks to be > 3ms and here the code is checking after 100ms.

Maybe this should be settable and not hard coded?

Other suggestions?

Thanks
Kurt

[KurtE]

I am guessing that there have not been very many others who have played much with this driver.
So far not much luck with it.

As an alternative to it, I hacked up a copy of Arduino library I mentioned in the first post by Paul Stoffregen.
This version is now also up in my zephyr test github project:
https://github.com/KurtE/zephyr_test_sketches/tree/master/ILI9341_touchpaint_xpt2046_teensy_library

For this pass I put some parts of it into the device tree. The code is not totally clean right now. And relies on polling the
chip to see when the user touches the display. I have not yet tried enabling the interrupt code in it. The only thing the
interrupt code does is to change the polling code, that is it simply remembers that an interrupt happened and in that
case the next poll will then check to see if flag is set and if not bail, else reads the SPI registers... Will continue to allow
the polling to continue to poll until it detects that display is no longer touched...

	xpt2046_spi_dev: xpt2046_spi_dev@3 {
		compatible = "vnd,spi-device";
		reg = <3>;
		spi-max-frequency = <2000000>;
	};

So far the code is working reasonably well:

Not sure what I will do with it after this? Not sure if it makes sense to try to update the current built in code?
Things that I think maybe should be changed include:
a) way to configure how X and Y of touch maps to X, Y of screen....
b) Maybe option for RAW values
c) Maybe better control of timing? 1/10th of second is not sufficient for dragging your finger around.

Not sure if Paul's way of reading the registers is better or not, but I am getting good readings for pressure and the like.
I had to hack his way up some as there were several either transfer and transfer16 spi calls, and my quick hacked up
versions of these appeared to transfer the wrong number of bytes.
So I now do it in 2 or 3 transfers, always 8 bit per item...

	// lets try doing the first part with one transfer
	static const uint8_t upd_tx1[] = {0xB1, 0, 0xC1, 0, 0x91};
	uint8_t rx[10];

  struct spi_buf tx_buf = {.buf = (void*)upd_tx1, .len = sizeof(upd_tx1)};
  const struct spi_buf_set tx_buf_set = {.buffers = &tx_buf, .count = 1};
  struct spi_buf rx_buf = {.buf = &rx, .len = tx_buf.len};
  const struct spi_buf_set rx_buf_set = {.buffers = &rx_buf, .count = 1};

  spi_transceive_dt(_pspi, &tx_buf_set, &rx_buf_set);

	int16_t z1 = (int16_t)(((rx[1] << 8)	| rx[2]) >> 3);
	z = z1 + 4095;
	int16_t z2 = (int16_t)(((rx[3] << 8)	| rx[4]) >> 3);
	z -= z2;
	if (z >= Z_THRESHOLD) {
		static const uint8_t upd_tx2[] = { 0, 0x91, 0, 0xD1, 0, 0x91, 0, 0xD1, 0, 0x91};
		tx_buf.buf = (void*)upd_tx2;
		rx_buf.len = tx_buf.len = sizeof(upd_tx2);
  	spi_transceive_dt(_pspi, &tx_buf_set, &rx_buf_set);
  	// first number noisy...
		data[0] = (int16_t)(((rx[2] << 8)	| rx[3]) >> 3);
		data[1] = (int16_t)(((rx[4] << 8)	| rx[5]) >> 3);
		data[2] = (int16_t)(((rx[6] << 8)	| rx[7]) >> 3);
		data[3] = (int16_t)(((rx[8] << 8)	| rx[9]) >> 3);
	}
	else data[0] = data[1] = data[2] = data[3] = 0;	// Compiler warns these values may be used unset on early exit.

	static const uint8_t upd_tx3[] = { 0, 0xD0, 0, 0};
	tx_buf.buf = (void*)upd_tx3;
	rx_buf.len = tx_buf.len = sizeof(upd_tx3);
	spi_transceive_dt(_pspi, &tx_buf_set, &rx_buf_set);
	data[4] = (int16_t)(((rx[0] << 8)	| rx[1]) >> 3);
	data[5] = (int16_t)(((rx[2] << 8)	| rx[3]) >> 3);
...

But not sure if I will do much more if there is no interest in it.

Back to playing

[Karijn]

Here is my solution for the CYD.
It is probably not the best way but it works.

cyb_lvgl.zip

[KurtE]

Thanks @Karijn - looks similar to what I was trying with the library. Although looks like you increased the number of reads to 4 and the like.
Will try your settings.

Was also playing with maybe playing with a Pull Request for some changes, not sure yet if I will try it or not...
Maybe extend the properties, like:

sample-delay (default 100) of how long to delay between samples

Rotation and/or raw mode; as I mentioned earlier sometimes the touch grid may not be in the same orientation as the screen. And in
some cases, we may not want the rotation to be fixed. That is suppose you are sort of setup like a tablet or the like, that you can
rotate and have sensors to detect the orientation, which causes the display to change from portrait to landscape...

Also wondering about filtering or how it averaged. Currently with your 4 samples the code simply adds them up and divides by 4...
Whereas the Arduino library I mentioned earlier. When he is updating the data, he tosses the first X saying that it is always noisy.

He then takes three samples, and computes an average using the two out of three X samples and Y samples with the smallest differences between them. And I always found his library worked well... So wondering if there should be some form of filtering and averaging like this?

Thanks again!

[dolence]

I'm dealing with this panel at this moment too. If you will be using it with LVGL, the zephyr,lvgl-pointer-input node allows swapping and inverting x and y. If this isn't the case, you should be able to achieve something similar by swapping x and y coordinates or invert max min values.

The problem I'm facing is it doesn't allow dragging, only presses. Once a interrupt is triggered it does one (or more for averaging when more reads are set) and stop reading until a release event is dispatched. This is not any modern UI works and should be fixed.

Other than that, I had to lower to under 600kbps because I had too much noise on my custom board. This is a hardware issue though.

[KurtE]

Thanks, that is more or less how we handle it using Arduino. In most of my cases I have used it with Teensy 4.x boards using
PaulStoffregen's library, and then we manually do the conversion to the 4 orientations.

As I mentioned earlier, the Arduino library, discards the first coordinate returned, then it reads the coordinates three times
and averages the closest 2 samples and it has worked well.

Currently I am side tracked from doing the stuff on the Teensy boards, and trying to get some other things working using the
Arduino wrapper on Zephyr. But I hopefully will get back to playing with this