Display problem of STemWin with STM32F207IG(mouse cursor)

[shinjinoji]

Posted on June 11, 2014 at 08:57

Our team is applying STM32F207IG to 800X480 Touch LCD product. To do this, we have purchased STM3220G-EVAL and succeeded in demonstration.

Now we are trying to apply STemWin to our board with SSD1963 Driver. We achieved a success of reading and writing of image data including most of functions. But we faced with a display problem of moving images such as mouse cursor, animation image, etc.

The issue is as follow:

- when mouse cursor moved, it leaves mark of black shape of mouse cursor(arrow shape) behind mouse moving.

- when animation is operating like a moving dolphins, it also leaves marks of black shapes of dolphins behind them.

I took a picture of them and attached the file.

Could anyone give any advise to solve this problem?

Thanks for the coorperation in advance.

#stm32f207ig #display #mouse

[Amel NASRI]

Posted on June 11, 2014 at 12:11

Hello,

Please note that good location to submit STemWin related issues is [DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Java/AllItems.aspx]STM32 Software Tools and Firmware. For this particular case, there is no need to re-create a new request. You will get soon relevent feedbacks from our experts. Best Regards, -Mayla-

[rigomate2]

Posted on June 16, 2014 at 13:48

Knowing you use a SSD1963 , I assume you use its frame buffer to write data.

These artifacts occur if your driver can't read back information from the SSD1963's frame buffer. See STemWin5.pdf datasheet section 30.4 about Non readable displays.

[shinjinoji]

Posted on June 23, 2014 at 02:52

We still have the same problem in spite of reviewing STemWin5 datasheet.

Can anyone give another suggestions for us?Please refer to attached image files to understand this issue better.Thank you.

[rigomate2]

Posted on June 23, 2014 at 16:33

Can you verify, that the display CGRAM can be actually read back by the STemWin driver?

Place a breakpoint in your implementation of the read_psram16() or something similar. And have a look if anything but garbage comes back.

[shinjinoji]

Posted on June 24, 2014 at 08:13 The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6fo&d=%2Fa%2F0X0000000bsw%2F4UMhUEBFgn.klMk4WAJ7SE95mY3LEoYeMcdYKd7D9Tk&asPdf=false

[rigomate2]

Posted on June 24, 2014 at 17:02

Thanks for the reply.

This might be out of my league though.Let's hope some expert pops up to this problem.Although I'll think about it some more time.

[Pm77]

Posted on August 17, 2016 at 16:32 Hi Young, Guess too late to reply for this post.. If you still interested try adding following line before GUIDRV_FlexColor_SetFunc(); in LCD_X_Config();   GUIDRV_FlexColor_SetReadFunc66720_B16(pDevice,GUIDRV_FLEXCOLOR_READ_FUNC_II); Also set dummy read to none using Config.NumDummyReads = -1; Used in GUIDRV_FlexColor_Config(); func With this change there is no need to do 3 read in

LcdReadDataMultiple

(); single read does the job.

[Tesla DeLorean]

Posted on August 17, 2016 at 17:23

Guess too late to reply for this post.. 

Yes, well there has been no activity on it in two years, but people are apt to get to it the same way you did via a web search, so having useful answers/responses is helpful.Where it gets to be a problem is when people ask ghosts questions they are unlikely to answer.