Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Touch Panels and Screens

Status
Not open for further replies.
Hello Again

I am currently implementing the code for the Touch Panel part based on the XPT2046 controller.It uses a SPI interface. It is almost done (I havent tried it yet)
However I just noticed something.
Take a look at the datasheet
https://www.waveshare.com/w/upload/9/98/XPT2046-EN.pdf

You can see there is a PENIRQ output. "Theoretically" this seems to be a "interrupt" pin.

Following the ideas of this thread
https://www.electro-tech-online.com/threads/pic-spi-with-interruptions.145357/

and since SPI is always started by the master, I was thinking of using interruptions so that the LCD can notify the PIC (master) to start transmition whenever it has been touched, through an interruption.
And for this I thought of using the PENIRQ pin, since.. you know... it is supposed to trigger an interrupt.

BUT, then I notice what it says on page 25 of the datasheet


So, I am understanding that the "interruption" is only enabled whenever the master sends a control byte with a PD0= 0 to the slave!!

So, ok the interruption will tell me when the transmission has finished, but what use is this!. How use is this "interruption" if to use the interruption I have to be constantly looping and sending control bytes from the master??
Isnt supposed that interruptions save me from doing these pooling wasteful thing???

Am I understanding this wrong???

Any comment greatly appreciated
The IRQ cannot tell if the panel is touched, it is the same for the rest of XPT2046. The uC needs to do series of measurements and make the decision if and where the panel is touched by the results from the XPT2046.
The uC has to repeat these measurements say 10 times a second and when the results indicate that the panel is touched it interrupts the other routines.
 
The IRQ cannot tell if the panel is touched, it is the same for the rest of XPT2046. The uC needs to do series of measurements and make the decision if and where the panel is touched by the results from the XPT2046.
The uC has to repeat these measurements say 10 times a second and when the results indicate that the panel is touched it interrupts the other routines.

Yes , but I was hoping the micro do the measurements and decision only when the panel is touched (leaving it free most of the untouched time). The micro will know that the LCD has been touched and start the measurements whenever it receives an interruption.

I guess what you are saying is that the micro needs to do these measurements constantly. In such situation , what is the use of the so called interruption? I dont see the point
 
Yes , but I was hoping the micro do the measurements and decision only when the panel is touched (leaving it free most of the untouched time). The micro will know that the LCD has been touched and start the measurements whenever it receives an interruption.

I guess what you are saying is that the micro needs to do these measurements constantly. In such situation , what is the use of the so called interruption? I dont see the point

I'm saying that the XPT2046 does not have the capability of making decisions or knowing if the panel is touched, only the micro can do that. When the micro expect the user to touch the screen the micro must do the measurements repeatedly until it gets measurements that constitute a touch.
 
I'm saying that the XPT2046 does not have the capability of making decisions or knowing if the panel is touched, only the micro can do that. When the micro expect the user to touch the screen the micro must do the measurements repeatedly until it gets measurements that constitute a touch.

Got it. Thank you very much.
I am wondering, is this a common feature of other touch panel controllers (other than the XPT2046)??
 
Well I programmed it and tried it.

However it does not work well.
Debugging the code, I ve come to the conclusion that the problem is the SPI communication. (since the GetAdXY function which return the X Y coordinate of the touch point return strange numbers)

I have an oscilloscope here. I know how to use only the basics of this.

I would like to see the curve of the MOSI and MISO lines... how can I do this?

Thanks in advance
 
I'm saying that the XPT2046 does not have the capability of making decisions or knowing if the panel is touched, only the micro can do that. When the micro expect the user to touch the screen the micro must do the measurements repeatedly until it gets measurements that constitute a touch.
Let me reword that!!!

The XPT2046 DOES report that a touch has been made, However! It doesn't know where or whether it was valid.. It reports Z measurement... As zahwi said you still need to read the XY elements... It seems to be better to poll this driver..

When I write for a touch screen, I just poll Z ( pressure ) then if it was hard enough... Then do a position read..
 
Well I programmed it and tried it.

However it does not work well.
Debugging the code, I ve come to the conclusion that the problem is the SPI communication. (since the GetAdXY function which return the X Y coordinate of the touch point return strange numbers)

I have an oscilloscope here. I know how to use only the basics of this.

I would like to see the curve of the MOSI and MISO lines... how can I do this?

Thanks in advance
I was wrong about the PENIRQ, I connected a low pass to the output and and it goes low when the screen is touched.
Capture1.gif
 
I am still having problems with this...
I found that 12 clock mode did not work at all. So I changed to 8 bit and now I got a response like this
issues.jpg

As you can see I got 16 bits! The maker told me that some of them are 0s so I must do <<5 >>3
But also I suspect that I am getting the SAME value for X and Y which is not correct.
I am lost of what to try next...

Any advice?
 
Thanks. I ll try this too. Just a question. If CKE=1, that means that transition is from active to idle, and if idle is low then transition is from high to low so on the falling edge of SCK, no???
In any case I will try those settings too :)
May I ask how do you initialize and sample X and Y?? some code I have read on the internet send dummy orders before calling X and Y...

EDIT: I tried that. As a result 12bit started responding. The data though seems not to be correct. When I dont touch the panel I get X=0 Y=7FF8
 
Last edited:
I think I have solved it (well kinda:oops:)

First, I might be wrong but the datasheet is full of errors (at least for this LCD).

1. The SPI mode to use is either Mode 0 or Mode 3 (I use Mode 3) . Ergo CPOL=0 CPHA=0 or CPOL=1 CPHA=1. Reading the datasheet it seems they suggest the other modes (1 or 2).

2. The commands for X and Y are inverted. (or this model I have is cabled wrong:facepalm:, because the datasheet clearly states that you find X with 101 (0xD0) and Y with 001(0x90) but the commands are actually the opposite.

I ll try my findings more extensively tomorrow(I am beat:sorry:)
 
Thanks. I ll try this too. Just a question. If CKE=1, that means that transition is from active to idle, and if idle is low then transition is from high to low so on the falling edge of SCK, no???
In any case I will try those settings too :)
May I ask how do you initialize and sample X and Y?? some code I have read on the internet send dummy orders before calling X and Y...

EDIT: I tried that. As a result 12bit started responding. The data though seems not to be correct. When I dont touch the panel I get X=0 Y=7FF8
x and y on the TFT and touch panel don't have to be the same, the chips designers decide which is x as they find fit.
The readings are valid only when pressing the panel. Press the panel with the pen near the 4 corners and see if you get sensible readings. From those readings you should define x,y and zero point. It could be that in your PCB the x y are swapped. Those PCB's that we buy on ebay are designed by people who know very little about electronics.
In my code CKE=1 and CKP=0, that transmits data on rising edge of SCK. This is what the touch chip datasheet asked for. In practice the uC first establish the data bit and then changes clock from low to high.
Code:
void touch(void){
            cs=0;
        SPI(0b10011000);    //find Y pos, diff
        y=(SPI(0)<<1) | ((unsigned int)(SPI(0)>>7));
     
        SPI(0b11011000);    //X pos
        x=(SPI(0)<<1) | ((unsigned int)(SPI(0)>>7));
 
        SPI(0b10111000);    //Z1
        z1 = (SPI(0)<<1) | ((unsigned int)(SPI(0)>>7));    //8 bits z1
     
        cs=1;
}

unsigned char SPI(unsigned char val)        // send character over SPI
{
    SSPBUF = val;            // load character
    while (!BF);        // sent
    return SSPBUF;        // received character
}
 
You could just get an LCD from EarthLCD or ReachTech that you can just send vector graphic serial commands to and the controller takes care of everything else for you. You can then run the LCD off a dirt-slow microcontroller.
 
Well it turns out I still have problems.
Yes the touch panel is responding but the values are somehow slanted. Meaning that if I maintain X fixed while moving Y, X also changes....

(sigh)
to keep experimenting
 
In the end, slanted values is no problem since that is the nature of raw values of the touch panel. I am solving this through calibration. which transform (rotation, traslation and sizing) the coordinates of the touch panel to the LCD.

I notice that the direction of the coordinate frames is opposite. I wonder if this is solved with a negative sizing? I didnt do that but instead multiplied Y by -1.
The next problem was that for some reason the code the maker provided mixed unsigned and signed values and of course a substraction of two unsigneds will give also an unsigned which is not correct as we need to handle negative numbers. I cast them and solve them.

Next problem is the limitations of the PIC18F. I found out it handles 32 bit integers. I was surprised! Problem is the calculations of the calibration process often makes overflow it so right now I am solving that.
 
I could finally do it!
Thanks to all who helped me in this first stage:rolleyes::wideyed:

TouchPanelResult1.jpg


I am going to keep working on Touch Panels for a while so I would be very grateful for your continuous and generous help and advice!:)
 
Hello everybody!
Thanks again for all the help you gave me when implementing my touch panel project.

On my last trip to Tokyo I found a cheap LCD with similar characteristics
LCD2.jpg LCD3.jpg
The differences with the previous one are:

It uses ILI9327 (https://aitendo3.sakura.ne.jp/aitendo_data/product_img/lcd/arduino/UL035/ili9327.pdf ) as LCD controller (instead of ILI9325).
It uses a 8 bit interface instead of the 16 bit one of the previous one.
The touch panel controller is the same.

I am right now reading the datasheet to see the differences in commands , it seems they are rather different, initialization routine etc.... :facepalm:

Also, I found out about this library
uTFT (**broken link removed**)
It says it is for arduino and PIC32s , still reading the code... seems a little bit complicated...but I am wondering if it is worth...

Has any of you used them? any other libraries you could recommend to make pretty GUIs?
Do you know what is Mipi DBI???

Any comment, advice will be greatly welcomed! :happy:

Thanks
 
Last edited:
Has any of you used them? any other libraries you could recommend to make pretty GUIs?
Thanks

Going 300 miles to Tokyo for this screen, you must have wanted it badly. In 1990 It took me 2 days to do this journey by car.
As per post #25 these projects work for your new screen. You can get the code for initialization. Most libs are for rectangles and circles, for pretty shapes you will have to write the code.
https://www.moty22.co.uk/usb_tft.php
https://www.moty22.co.uk/sd_bmp.php
 
Going 300 miles to Tokyo for this screen, you must have wanted it badly. In 1990 It took me 2 days to do this journey by car.
As per post #25 these projects work for your new screen. You can get the code for initialization. Most libs are for rectangles and circles, for pretty shapes you will have to write the code.
https://www.moty22.co.uk/usb_tft.php
https://www.moty22.co.uk/sd_bmp.php

Haha, Actually I was in Tokyo to check the Wearable Expo :cool: but on my way back I pass through the electronic town (Akihabara) and got some stuff.. (ethernet shields, power boosts, etc) and then I saw that screen and I knew I had to have it :D:facepalm:

Thank you for the links, I ll check them out and come with questions probably :joyful:
 
Ok, reading the (modified) uTFT library I got , I have a question.
This LCD has an 8-bit interface. (the previous one was 16 bit)

So far the examples send 8 bits commands.
But for writing bitmaps it needs to send 16 bits (VH, VL).
How do I send 16 bits to an LCD through a 8 bit interface???

I got this piece of code
Code:
    //PORTD = VH;
        //pulse_low(P_WR, B_WR);
        PORTD = VL;   // NOT PORTA!
        pulse_low(P_WR, B_WR);

        break;

as you can see I am sending VL through PORTD.
I tried to send VH first through the same port (commented) but this does not work...
but if PORTD is the only data transmission way, what should I do??

EDIT: I think I am getting this to work...
apparently the libraries given by the manufacturer are full of errors :eek: so I am reading the code and correcting them myself
 
Last edited:
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top