Wednesday, April 25th 2018, 12:25am UTC+2

You are not logged in.

  • Login
  • Register

Renderman

Beginner

Date of registration: Aug 13th 2014

Posts: 10

1

Wednesday, August 13th 2014, 2:16pm

Touchscreen cursor footprint remains on LCD

Hi,

I'm running emWin on an STM32F103ZET6, using FSMC as interface to connect with the LCD driver(SSD1963).

For touch, I have written my own driver, and use GUI_TOUCH_StoreStateEx function to store registered x, y.

Touch screen works fine, accuracy is acceptable, but all the points that cursor has been are marked with a ghost of the cursor, as if I'm in a paint program and I'm drawing something.

I have gone both with and without OS (FreeRTOS) and the result is the same. Besides, the cursor shape (Arrow or whatever) tend to become somehow deteriorated, like if some pixels of it are misaligned, missed or like that (the placement of deteriorated pixels is random and changing).

Has anybody had this problem? What am I doing wrong?

Thank you.

Renderman

Beginner

Date of registration: Aug 13th 2014

Posts: 10

2

Wednesday, August 13th 2014, 4:10pm

Ok, one problem solved.

I connected pin RD (Read) of SSD1963 to VDD, somewhere nearest to the IC. It helped remove the deterioration of cursor shape.

Now I have a perfectly and neatly shaped cursor, but it still leaves its footprints on the LCD.

Renderman

Beginner

Date of registration: Aug 13th 2014

Posts: 10

3

Thursday, August 14th 2014, 8:29am

Come on! Only 8 views so far?! Someone help me!

Renderman

Beginner

Date of registration: Aug 13th 2014

Posts: 10

4

Sunday, August 17th 2014, 10:23am

I realize that during touchscreen moves, WM_PAINT message is not being sent to the call back function. Is that a clue?

Renderman

Beginner

Date of registration: Aug 13th 2014

Posts: 10

5

Sunday, August 17th 2014, 11:46am

If I invalidate the region cursor has been, it helps because invalidation makes Window Manager pass WM_PAINT message, hence cause cursor footprint clearing.


So, I conclude that touchscreen cursor at the moment does not invalidate the area it has been, why not?

Date of registration: May 26th 2009

Posts: 1,022

6

Monday, August 18th 2014, 2:24pm

Hello,

The cursors function is based on emWin Sprites. Sprites are emWin devices which separately manage drawing operations happening in the according area. It should never be necessary to explicitly invalidate a window in order to have a cursor properly displayed.

Unforunately I am not able to reproduce this problem, but I would suggest checking the function of your touch driver.

Best regards,
Adrian

Renderman

Beginner

Date of registration: Aug 13th 2014

Posts: 10

7

Monday, August 18th 2014, 4:32pm

Hello Adrian,

Thanks for the reply, I was getting disappointed.

Touchscreen driver IC is XPT2046, which is ADS7846 compatible. I have created a task which reads X and Y from the touch screen, maps it to LCD coordinates and uses
"GUI_TOUCH_StoreStateEx" to save PID state (layer 0).


I NEVER call GUI_TOUCH_Exec(), and as I said before, cursor movement is fine.

Can you provide a sample driver code?

Thanks again

P. S.:
I ran the sample program "Showing sprites" to see how sprites worked.

The background and Segger logo are shown perfectly, but no sprite (dolphins) appears.

Debug reveals that there is no hard fault or things like that, what does it mean?

This post has been edited 1 times, last edit by "Renderman" (Aug 18th 2014, 4:55pm)


Renderman

Beginner

Date of registration: Aug 13th 2014

Posts: 10

8

Monday, August 18th 2014, 5:10pm

Well well well...

I found an old topic here:

emWin Mouse


In which it seems exactly the same problem is being encountered.

Due to some noise problems, I have shorted the RD pin of the controller to VDD. Does emWin need to read data from the LCD driver chip (SSD1963)?

I debugged the sprite code mentioned in my previous post, and saw some calls to the routines that read from the LCD driver, but they seem to happen just at the beginning of the program (during initialization?) .

P. S.:
Reconnected RD pin from SSD1963 to NOE pin on STM32, as it should be. I suspect what I thought to be a noise problem actually might be an LCD read problem.

Anyway, sprites did not appear, cursor still is leaving footprints, although the color of footprints is changed and the cursor shape is a little bit deteriorated (some pixels missing).

Besides, LCD becomes washed out sometimes (What I thought to be a noise problem).

Is there a chance I might have damaged the pins? I should check it with an oscilloscope.

This post has been edited 1 times, last edit by "Renderman" (Aug 18th 2014, 5:43pm)


Renderman

Beginner

Date of registration: Aug 13th 2014

Posts: 10

9

Tuesday, August 19th 2014, 3:37pm

I reconnected the RD pin. No physical damage.

During my searches, I found out this function was missing in my codes:

GUIDRV_FlexColor_SetReadFunc66720_B16(pDevice, GUIDRV_FLEXCOLOR_READ_FUNC_II);


So I added it to LCDConf.c

Then I wrote a very basic code that clears LCD with Red, Green ... and enabled cursor as well.

Only the 0,0 point, were cursor has been at the beginning of application, is redrawn correctly, every other place is drawn black.

I checked what was read back from LCD using debug (I used Keil Uvision), and realized that color codes are read back correctly, 0x001F for red, 0x07E0 for green, 0xF100 for blue. Also checked yellow, result is 0x07FF, which is correct.

So, I conclude that colors are read back from SSD1963 correctly.

Then I tried this code:


GUIDRV_FlexColor_SetReadFunc66720_B16(pDevice, GUIDRV_FLEXCOLOR_READ_FUNC_I);


(FUNC_I instead of FUNC_II). Although places cursor has been are not redrawn correctly, but the color changes depending on the background of the cursor. It differs from previous results, which were always plain black.

Any ideas?

Renderman

Beginner

Date of registration: Aug 13th 2014

Posts: 10

10

Wednesday, August 20th 2014, 9:30am

Problem Solved!

It was an LCD driver problem! In LCDConf.c I did:

1. Add GUIDRV_FlexColor_SetReadFunc66720_B16(pDevice, GUIDRV_FLEXCOLOR_READ_FUNC_II); to the function: void LCD_X_Config(void)

2. Add Config.NumDummyReads = -1; to the same function (before GUIDRV_FlexColor_Config)

Number 2 is very important, by default, Config.NumDummyReads is set to 0, which is invalid. if you don't need any dummy reads, Config.NumDummyReads must be -1, not 0.


Besides, your microcontroller must be able to read data from LCD, because in most cases it does not have a copy of LCD contents internally, it cannot figure out how to restore the colors where pointer has been before.

That's it! I can't believe it took me such a long time to get fixed!

Date of registration: May 26th 2009

Posts: 1,022

11

Wednesday, August 20th 2014, 6:30pm

Hello,

Yes, just as it is explained in the emWin user manual:


Best regards,
Adrian

Renderman

Beginner

Date of registration: Aug 13th 2014

Posts: 10

12

Thursday, August 21st 2014, 7:26am

Hello Adrian,

Thank you. The confusing thing was that I checked many LCDConf.c files and none of them had this value set to -1.

They didn't bother to change this value at all, and I wonder how their drivers worked then!

Thanks again.

Similar threads