2.8 ILI9341 restive touch miso not connected ?

Status
Not open for further replies.
Has anyone tried the edits to use the SD_card slot as was done on the non touch ILI9341?

PJRC touch display package came today - great delivery time! - not powered up yet. I sent a note to Robin for future QC testing - If you were lucky enough to get one from the first batch - make sure glass front is secured to PCB or you could get a rude surprise. Metal frame loops may not catch the display side ears allowing it to fall out as you rotate it. Worse yet - the metal frame on one of mine was not secured to the PCB board meaning upside down the screen would drop and swing/tug on the attaching cable. Double sided tape seems to be a fix. <and lifting the glass enough to push the metal loop in 'some'>
 
Internally, those little displays are held together by just a couple layers of double-sticky tape. Sometimes the tape separates during handling. Just firmly pressing the pieces will re-seat the tape.

More expensive displays use metal frames or other strong ways of keeping all the layer together.
 
As noted I added double-stick tape and expect it to be fine - but it shipped adhesive free, here's pic copy of the pic I sent to Robin. The left shows no factory tape - the right shows a jumper wire I placed under the display free of the metal loops. The invoice shows a friendly smiley face that was free! And no I didn't get the display for $8 I checked my CC. 20151015_154304s.jpg

On these the adhesive holds a 'very most awesome deluxe' metal frame to the PCB, the frame loops hold the display. On the other display the two metal edge loops on one side lacked tension to capture the plastic layer bumps under the glass, in rolling it over to examine it shifted free of the restraints that hold it in the frame. Actually, when I taped the frame down that unit had loose loops on one side too, they are light gauge.

All is well - this was just a note as the mass of the glass part going free could be trouble.
 
Wired and working per the Connections and 100% success!. Much nicer than when I did the ILI9341 unit - I wired to Teensy header rather than jumper wires - which worked but once apart seemed like too much effort to restore.

One thing I noticed is you never get the same X,Y twice (on the test with delay(100) between samples). I used a pointer and did my best to hold it still. I suppose that is the variability Paul saw and wanted to average out in some fashion.

opps:: (~4 hours later sitting on desk) Seeing the screen go WHITE after running for some time sitting IDLE? USB output shows touch data updates but display is nothing but white screen? Just saw it a 3rd time - reverted back to original example/ILI9341Test - happened in under 10 minutes? And again in like 6 mins and then very quickly a time or two. Ran from USB charger battery - same thing. Swapped to backup display and re-powered - same Teensy and same loaded code . . . will update . . . so far so good @35+ mins.

In case it might be my wiring here it is - 'heavy' cat5 wires for VCC & GND, and the 100ohm resistor to LED from VIN, the rest alternated white/black wire wrap wire. I did WW and then solder each point.

Touch9341whites.jpg

8hrs on display #2 no problem. Return to display #1 - only powers up white - but still shows accurate touch data. So Teensy and wiring are fine.

ODD: Loaded 'graphicstest' and d#1 is running that? And now back running ILI9341Test ??? Seems flakey - went white again and a reset from TYQT brought it back up - 25 minutes and counting . . . came back after an hour and it was white - restored again on TYQT reset. White again at 33 mins - came back on power cycle. I've seen this display go WHITE now 6 times in the last 2 hours 20 minutes. It will come back but not long. As before the Touch SPI is still active - LED blinks - and the USB gives the readings. This is the display that came unstuck from the PCB. I didn't think much of it but when first attached I did a double upload - I thought maybe there needed to be a delay in setup - there isn't and the other doesn't need it and it doesn't when it starts up working.
 
Last edited:
I didn't get far looking into the library with the hanging display - but I did glance at RANSAC. If I read it right it seems to be designed to solve a static image alignment issue:
Applications
The RANSAC algorithm is often used in computer vision, e.g., to simultaneously solve the correspondence problem and estimate the fundamental matrix related to a pair of stereo cameras.

That case is with fixed offset images adjusting for the parallax offset. The touch problem is noisy readings - compounded by user movement - intended or not.

Over sampling and averaging in an extreme case it would be similar to OIS - where the user moves a finger on the screen and the system works hard to keep you from reaching your goal, or seeing any movement - like the cute mouse app that moves the box just ahead of the pointer.

One thing I did was had 'No Touch' print the last coordinates before it appeared. Even the boundary number reported going off all four edges had a large degree of variability. I didn't get as far as looking at the raw numbers to see if that was as reported from hardware, or as averaged and returned.
 
I found a manual and didn't learn much except 'calibration' might help with pressure knowing the range of resistance across the screen. It doesn't report as linear now doing my best to raise and lower the pressure on a point it has cusps where after dropping it rises then drops. Also the formula might need adjusted as the pressure return changes across the screen when using a spring loaded stylus at light spring or full pressure. Conversely I haven't checked if screen pressure affects accuracy. I didn't find the command set in that doc, so assume it is set up for optimal analog readings by default.

I instrumented the library to eject the data array as read, and looked at the code some:

I don't know what return values are expected - but empirically I noticed that the dummy X and next X read are always zero when there is no touch. So after the dummy comes back zero, the next five SPI commands could be aborted as ( !touched ) - then after the SPI.endTransaction() all processing can be terminated after zraw is set zero. This cuts SPI data flow in half when there is no touch, if this is supported behavior, and then the math component goes to zero as now it is done on each update.

And perhaps in update() the assignment of msraw = now; should not be done up front, but only if there is a touch as it will delay getting back in to find the next touch.

So far seeing the raw X,Y data only shows it has a great deal of variability. But it is scaled over 10::1 to the screen pixels, so a value near +/- 15 on either axis will map to the same pixel. Over time the simple average (on the X axis) of the three points groups matches the current scheme +/-1, that time can be 6 total readings, or many more. usually the worst case difference is under 10, sometimes greater than 50, I haven't looked at which is right more often yet, though that would be easy - but it is late. Paul's code is right the initial X read is often not in the ball park, other times it is. There may be a simpler way to toss out errant readings, perhaps I can check if given X,Y pairs seem correlated as the current code assumes - it may be that any given X or Y is independently wild?

The cool thing is the Teensy is fast and edits and recompiles are quick! Also cool I didn't get just one display, #2 has not gone white even once, though touch worked on the white screen and I'm now needing the big screen fed by USB to scan copious data streaming - and thinking of more compares as I wrote this.
 
How accurate or inaccurate is the XPT2046 vs the Teensy 3.2 onboard ADC?
From the spec sheet its not much faster then the Teensy using the ADC Library.
 
Teensy's ADC is certainly much faster.

But the XPT2046 has the advantage of automatically canceling out the effect of the resistance (small voltage loss) of its transistors which drive the display, and of course it's actually connected to the 4 wires from the panel. Those 4 wires aren't brought to the pads on the edge of the display, so you've have to really butcher a display to use anything other than the XPT2046 chip.

This type of measurement is probably always going to be pretty noisy. It's a fairly high source impedance, and there's a matrix of switching signals to drive the TFT nearby.

The 12 bit numbers can look pretty terrible. But remember it's nearly 3000 to 3500 across the entire width of the display. Fluctuations of 30 are only 1% of the display width. Sure it'd be nice if all 12 bit were perfect, but you have to keep some perspective about how accurately a finger can even touch a 2.8 inch display. Even 2% or 3% accuracy (of the full scale) is still better than anyone can probably touch.

Still, if anyone wants to really work on this, RANSAC or some other algorithm would be awesome on a purely technical level, even if it's not of much practical value for the actual measurement on these small displays.
 
Teensy's ADC is certainly much faster.

But the XPT2046 has the advantage of automatically canceling out the effect of the resistance (small voltage loss) of its transistors which drive the display, and of course it's actually connected to the 4 wires from the panel. Those 4 wires aren't brought to the pads on the edge of the display, so you've have to really butcher a display to use anything other than the XPT2046 chip.

This type of measurement is probably always going to be pretty noisy. It's a fairly high source impedance, and there's a matrix of switching signals to drive the TFT nearby.

The 12 bit numbers can look pretty terrible. But remember it's nearly 3000 to 3500 across the entire width of the display. Fluctuations of 30 are only 1% of the display width. Sure it'd be nice if all 12 bit were perfect, but you have to keep some perspective about how accurately a finger can even touch a 2.8 inch display. Even 2% or 3% accuracy (of the full scale) is still better than anyone can probably touch.

Still, if anyone wants to really work on this, RANSAC or some other algorithm would be awesome on a purely technical level, even if it's not of much practical value for the actual measurement on these small displays.

My reason for asking was I have an Adafruit 2.8 ILI9341 without Resistive Touch IC and was wondering if it would be beneficial to add a dedicated IC to it.
 
No, you need the additional resistive foil on top of the display.

If you don't need it for drawing or such things, i would think that 1/20 or 1/50 of the resultion would be more than enough.
 
Last edited:

I think the most easy way is to buy a display with touch ic....
Its so cheap that every minute fiddling with such things not worth it.. :)
I bought mine for 7 or 8 EUR from china...i dont remember the exact price.
One was defective, but i was able to fix it. The displayconnector had a bad soldering.
Now they are available from pjrc, and if you're in the us i would buy it there.
 
Last edited:
I wanted to know if there was a large difference in accuracy between the Touch IC and what the Teensy can do and from what Paul said there isn't much of a difference.
Easy and best don't always work out.
 
Just did a Pull request from (to?) GitHub. After looking over the 'constrained' random data values returned to suggest touch location I put my observations into code.

The change I made to returned X,Y is that Paul did a distance test as a paired point, which makes sense until looking at the data source and acquisition time. The three reads are under 96 SPI xfer bits apart start to end - alternated xyxyxy. We know the data is jittery and out of 6 points at least one probably wild, but calling it 'paired' with one seems artificial, and one wild coordinate would get the pair tossed, even if the other coordinate better equaled a second. So I implemented diff of the 3 values as X and Y and averaged the two closest ones. In my instrumented build I was seeing about 30% of the time my pair average was unique from the initial library.

Optional: additions:
The library enforces a THRESHOLD on rapid reads of 3ms. If it was asked ts.touched(); and it replied NO, it would keep the caller from getting back in, maybe 3ms is okay. But if a caller just hits ts.getPoint(); static data is returned without attempt to update, if no touch it will still get stale data - but at least it will try in that window. Of course that window never closes when there is no touch.

For either of the above noted calls the same internal update() is done. For touched() it still does all the math and calculations after completing the 10 word SPI data cycle in all cases. In watching the data I saw that the first X value returned after the 4th transfer is ZERO when there is no touch, the first reads are for the Pressure to detect a touch. This calc was done after the SPI cycle, but if there is no X then there is no touch [empirical not from data sheet?], that means the next 4 SPI words can be skipped as the data won't be used in any case and we can determine that there was no touch. Not reading 40% of the data and skipping all the math means the touched() call is less expensive in SPI bandwidth and cycles.

Notes:
> With the initial code and my update code the touch variability is easily +/- 1 pixel so printing it at the calculated point works, but makes a little cloud there.
> I used a stylus for most of my testing, a bit better than a finger for uniformity. If you touch near both screen edges the value is read to the middle, biased some by the harder pressing part.
> I get good fast touch and screen updates even when I changed the default delay(100) to delay(3) in my main loop.

Tested to no good effect:
1> I wondered if reading 'xxxyyy' instead of 'xyxyxy' would give a better reading not swapping the multiplexor and analog converter around, and the results got more jitter as I saw them. Perhaps the Read x then y cycle allows the alternate resistive plane to recharge?
2> I saw the code noted the first x read was always noisy, and it is, I suppose that is from 'powering down' the touch panel with the final read and getting it repowered with the first read.
3> Writing '2' made me wonder if the dummy x read should be first to make sure the pressure read is accurate
4> Writing '1' makes me wonder if the dummy x should actually be followed by the first y read? (if not move ahead of the z plane reads)
<edit> '4' is a big no - the x doesn't return zero and the touch sense fails, didn't try '2' as the shuffle would delay no touch exit an SPI transfer

Question: What is the math for mapping Touch_xy to pixels_xy? My attempt at what I thought for a linear system gets parallax error: Find the min_xy and max_xy. The pixel value for x would be: xx = (( 320 * (p.x - MinSx)) / (MaxSx - MinSx) ); But this lags at the start and accelerates and the end. Result is similar on X and Y axis. I calculate it on the fly with low/high values seen during the run to adjust some safe static start numbers.
 
Last edited:
Does their TouchScreen library work with Teensy 3.x?

A quick look suggests it probably should, but there might issues with how the pins are defined, or maybe switching from digital to analog and back to digital mode on the pins.


Considering the number of errors I may end up giving the ADC Library a try, not sure how it will handle pins being reassigned from analog to digital thou.
Code:
Build options changed, rebuilding all
In file included from D:\Arduino\hardware\teensy\avr\cores\teensy3/wiring.h:33:0,
from D:\Arduino\hardware\teensy\avr\cores\teensy3/wiring_private.h:7,
from D:\Arduino\hardware\teensy\avr\libraries\Touch-Screen-Library\TouchScreen.cpp:7:
D:\Arduino\hardware\teensy\avr\cores\teensy3/core_pins.h: In function 'void digitalWriteFast(uint8_t, uint8_t)':
D:\Arduino\hardware\teensy\avr\cores\teensy3/core_pins.h:887:24: error: 'portSetRegister' was not declared in this scope
*portSetRegister(pin) = digitalPinToBitMask(pin);
^
D:\Arduino\hardware\teensy\avr\cores\teensy3/core_pins.h:887:51: error: 'digitalPinToBitMask' was not declared in this scope
*portSetRegister(pin) = digitalPinToBitMask(pin);
^
D:\Arduino\hardware\teensy\avr\cores\teensy3/core_pins.h:889:26: error: 'portClearRegister' was not declared in this scope
*portClearRegister(pin) = digitalPinToBitMask(pin);
^
D:\Arduino\hardware\teensy\avr\cores\teensy3/core_pins.h:889:53: error: 'digitalPinToBitMask' was not declared in this scope
*portClearRegister(pin) = digitalPinToBitMask(pin);
^
D:\Arduino\hardware\teensy\avr\cores\teensy3/core_pins.h: In function 'uint8_t digitalReadFast(uint8_t)':
D:\Arduino\hardware\teensy\avr\cores\teensy3/core_pins.h:976:32: error: 'portInputRegister' was not declared in this scope
return *portInputRegister(pin);
^
D:\Arduino\hardware\teensy\avr\libraries\Touch-Screen-Library\TouchScreen.cpp: In member function 'TSPoint TouchScreen::getPoint()':
D:\Arduino\hardware\teensy\avr\libraries\Touch-Screen-Library\TouchScreen.cpp:61:41: error: 'digitalPinToPort' was not declared in this scope
uint8_t xp_port = digitalPinToPort(_xp);
^
D:\Arduino\hardware\teensy\avr\libraries\Touch-Screen-Library\TouchScreen.cpp:66:43: error: 'digitalPinToBitMask' was not declared in this scope
uint8_t xp_pin = digitalPinToBitMask(_xp);
^
D:\Arduino\hardware\teensy\avr\libraries\Touch-Screen-Library\TouchScreen.cpp:77:30: error: 'portOutputRegister' was not declared in this scope
*portOutputRegister(yp_port) &= ~yp_pin;
^
Error compiling.
 
Managed to slap together a mostly working chunk of code using the ADC library. The xpos seems to work fine, the ypos is all over the place when not being touched. Sometimes its 0 sometimes its 3000-3400, sometimes its around the midpoint. Its way to erratic for averaging to fix. Will put a scope on it tomorrow.

Below is a snipped version of what I used.
Code:
#include <ADC.h>

//Screen I/O
const int dXp = 17; //   Digital Pin 17 for X+
const int aXn = A5; //   Analog Pin 5 for X-
const int dXn = 19; //   Digital Pin 19 for X-
const int dYp = 16; //   Digital Pin 16 for Y+
const int dYn = 18; //   Digital Pin 18 for Y-
const int aYn = A4; //   Analog Pin 4 for Y-

//touchscreen
uint16_t posx = 0; //x position for touchscreen
uint16_t posy = 0; //y position for touchscreen

elapsedMicros touchtime;

void setup() {

  ///// ADC0 ////
  //adc->setReference(ADC_REF_INTERNAL, ADC_0); change all 3.3 to 1.2 if you change the reference

  adc->setAveraging(1); // set number of averages
  adc->setResolution(12); // set bits of resolution

  // it can be ADC_VERY_LOW_SPEED, ADC_LOW_SPEED, ADC_MED_SPEED, ADC_HIGH_SPEED_16BITS, ADC_HIGH_SPEED or ADC_VERY_HIGH_SPEED
  // see the documentation for more information
  adc->setConversionSpeed(ADC_MED_SPEED); // change the conversion speed
  // it can be ADC_VERY_LOW_SPEED, ADC_LOW_SPEED, ADC_MED_SPEED, ADC_HIGH_SPEED or ADC_VERY_HIGH_SPEED
  adc->setSamplingSpeed(ADC_MED_SPEED); // change the sampling speed
  
  Serial.begin( 9600 );
}

void loop() {

if(touchtime > 1000000){  //wait x microseconds
  //Read X pos first
      pinMode(aYn, INPUT);   //reading this pin
      pinMode(dYp, INPUT);   //tristate this pin or atleast hope it goes high impedence
      pinMode(dXp, OUTPUT);
      pinMode(dXn, OUTPUT);
      digitalWriteFast(dXn, LOW);      
      digitalWriteFast(dXp, HIGH);  
      delayMicroseconds(10);   //let things settle
      posx = adc->analogRead(aYn, ADC_0);  
      
      digitalWriteFast(dXp, LOW);
  //Read y pos next
//      delayMicroseconds(20);
      pinMode(aXn, INPUT);   //reading this pin
      pinMode(dXp, INPUT);   //tristate this pin or atleast hope it goes high impedence
      pinMode(dYp, OUTPUT);
      pinMode(dYn, OUTPUT);
      digitalWriteFast(dYn, LOW);      
      digitalWriteFast(dYp, HIGH);  
      delayMicroseconds(10);   //let things settle
      posy = adc->analogRead(aXn, ADC_0);   
      
      digitalWriteFast(dYp, LOW);
      
      touchtime = 0;
      
 Serial.print(posx,DEC);
 Serial.print("  posx  ");
 Serial.print(posy,DEC);
 Serial.println(" posy ");
      
      
}

}
 
What is the xpos with no touch? The PJRC type direct ADC controller showed a uniform zero value on xpos - but only on the dummy and first reads. 2nd and 3rd reads on xpos are all over and all three reads have a wandering value.

Just for sanity: wondering what happens if you read Y then X - and/or just skip setup&reading the X for a test?

Does this unit have a way to gather pressure info? IIRC the PJRC type unit does it by doing a read across both channels in some fashion. Of course that onboard chip interface also has a temp sensor.

Would be cool to add a calibrate function where you give screen coords, and a read func that returns in pixels as that is something the user will do in some fashion.
 
What is the xpos with no touch? The PJRC type direct ADC controller showed a uniform zero value on xpos - but only on the dummy and first reads. 2nd and 3rd reads on xpos are all over and all three reads have a wandering value.

Just for sanity: wondering what happens if you read Y then X - and/or just skip setup&reading the X for a test?

Does this unit have a way to gather pressure info? IIRC the PJRC type unit does it by doing a read across both channels in some fashion. Of course that onboard chip interface also has a temp sensor.

Would be cool to add a calibrate function where you give screen coords, and a read func that returns in pixels as that is something the user will do in some fashion.

xpos stays around 900 without touching it, ypos seems to bounce I got my scope attached and it seems like there is alot of noise on the X+ and X- lines.

CH1 = X+ , CH2 = X-, CH3 = Y+ , CH4 = Y-
HVFnko5.png


If I touch the screen it cleans up pretty good.

CH1 = X+ , CH2 = X-, CH3 = Y+ , CH4 = Y-
YFP0wzy.png


From what i've seen the Touch library Adafruit made has a touch detection but im having a hard time understanding what they are doing.

To clarify how im reading.

Y+(CH3) and Y-(CH4) are set to inputs, while X+ and X- are set to outputs.
The first pulse on CH1 is X+ being driver High along with X- Being driven Low. Then Y- is read.
As soon as the read is completed, X+ is driven low.
Y+ and Y- are set to outputs and X+ and X- are set to inputs.
Y+ is driven High and Y- is driven Low. Then X- is read.
Then Y+ is driven low.
 
Last edited:
Does this unit have a way to gather pressure info? IIRC the PJRC type unit does it by doing a read across both channels in some fashion. Of course that onboard chip interface also has a temp sensor.

Pages 20 and 21 of the XPT2046 explain how they do it after reading that and then looking at the Adafruit code I figured out how its being done. One thing that is confusing is a lot of the Arduino examples for reading the screens only shows 4 resistor in a cross, but there is a 5th resistance, and its the contact resistance between the X and Y planes(pressure). The XPT2046 reads 3 of the 4 Touch pins analog values in sequence and determines the resistance(Z) between the X, Y planes and thus the amount of pressure on the screen if any. Adafruit drives 2 opposite pins High and reads the other opposite pins to determine the voltage drop across the Touch plane.
 
Donziboy2 - to match your findings - I read this last night but didn't post - but it relates: http://www.unclelarry.com/?p=101 in that he discovered the 5th plane hoping he could read light touches - but until the touch is hard enough there is no circuit completed. Also describes the pressure sense. Again he shows a formula different than in the code for pressure, as in the PDF doc I saw. The code there works for touch detect - but is not linear with the math used.
XPT2046-touch-pressure-equation-300x71.png.

I updated my PULL request to Paul with a question about the time between SPI.transfer - doing actual z detect after the data from the first two reads comes back is better than assuming the x=0 on the third read is defined behavior on all units, it also allows exit one SPI word sooner when not touched. Based on the above I think in the end the z=pressure calc should be changed when touch is detected.

My SPI question would be - the transfers are blocking as we assign a return value. If we execute 'a few' instructions in code as the master before we execute the next SPI transfer is that controlled or gated by master 'clocking' the transfer and not by a steady UART like clock?

The final comment to his post says - in spite of my min/max position attempt to turn touch_pos into pixels:
I’ve found the touch screens to be very linear.
So thinking on that: my p#65 math should be right (it crosses the center but lags to start and leads to end)- but the lowest value returned and perhaps the highest are aberrations so I am skewing my conversion math assuming the lowest I see relates to what I should use. I'll put up targets and average on them - and update the pressure calc later today.
 
Touch Detect works pretty good. Its pretty easy to detect as long as you have a rough idea of where xpos is at that time, it seems to move around some so atleast one read is needed.
I tried doing the math with both float and uint32_t. It was more accurate with float but as long as you set a decent threshold to trigger on you should do fine with either. I also had some issues with float overflowing when using 12bit adc values. Makes sense since the Adafruit code uses only 10bit values they would not see issues.

Next step will be adding more samples and averaging. Im now using 3 of the 4 pins as both analog and digital pins.


code snippet
Code:
//Touch Detect
      pinMode(aYp, INPUT);
      pinMode(aXn, INPUT);
      pinMode(dYn, OUTPUT);
      pinMode(dXp, OUTPUT);
      digitalWriteFast(dYn, HIGH);
      digitalWriteFast(dXp, LOW);
//      delayMicroseconds(1);   //let things settle
      z1 = adc->analogRead(aXn, ADC_0); 
      z2 = adc->analogRead(aYp, ADC_0);
      
      digitalWriteFast(dYn, LOW);
  //Read X pos first
      pinMode(aYn, INPUT);   //reading this pin
      pinMode(dYp, INPUT);   //tristate this pin or atleast hope it goes high impedence
      pinMode(dXp, OUTPUT);
      pinMode(dXn, OUTPUT);
      digitalWriteFast(dXn, LOW);      
      digitalWriteFast(dXp, HIGH);  
//      delayMicroseconds(1);   //let things settle
      posx = adc->analogRead(aYn, ADC_0);  
      
      digitalWriteFast(dXp, LOW);
       
   //Barrowed from Adafruit TouchScreen    
    uint32_t rtouch;   //use float for higher accuracy, watch out for overrun when using 12bit values
    rtouch = z2;
    rtouch /= z1;
    rtouch -= 1;
    rtouch *= posx;
    rtouch *= 298;   //x resistance
    rtouch /= 4096;
      
      
      
      
  //Read y pos next

      pinMode(aXn, INPUT);   //reading this pin
      pinMode(dXp, INPUT);   
      pinMode(dYp, OUTPUT);
      pinMode(dYn, OUTPUT);
      digitalWriteFast(dYn, LOW);      
      digitalWriteFast(dYp, HIGH);  
//      delayMicroseconds(1);   //let things settle
      posy = adc->analogRead(aXn, ADC_0);   
      
      digitalWriteFast(dYp, LOW);
      
      touchtime = 0;
     
 Serial.print(posx,DEC);
 Serial.print("  posx  ");
 Serial.print(posy,DEC);
 Serial.print(" posy ");
 Serial.print(rtouch,DEC); 
 Serial.println(" rtouch ");      
    
}
 
On the PJRC - assume the same as OP Frank's display: For pressure calc per the data sheet p#73 the main factor is the z2/z1. Supposing we had a steady accurate X position multiplying that by x/4096 is supposed to fix the drift as it crosses the screen. it does no correction for y.

Working with that I see similar or greater variability to the pressure # as in the initial PJRC lib code that is wholly different, but relies on z1 and z2. Removed the x-term as it just adds another random term to what didn't look good.

Just looking at (z2/z-1) and expecting it to reflect on the x position I don't see that. It changes on my display at the lightest touch seen or a firm touch - finger or spring stylus. Not only at the same point by a factor of 2 - but across the display both x and y.

z1 and z2 are read up front and may be weak after power on? - so I read them a second time midway through the xyxyxy reads - and the (z1/z2) value is no better.

I should be right on x.vs.y - as they are bits in the SPI commands - and printed in the debug spew. But it varies across both axis as well. Lowest x,y has highest z tendency on the lightest touch and it is lowest z at the highest x,y.

The pressure value from the original calculation is more suggestive:: int z = z1 + 4095 - z2;
> I don't see a reason to change it for the data sheet version - wherever it came from

This is with my working #2 display - up for days. As long as it has been on #1 was off - did a power off swap and it came up white on repowering. Did a reprogram and the color is back [for 10 minutes] - but the touch works in either case - and #1 maybe better than #2,
 
Status
Not open for further replies.
Back
Top