SSD1963 driver update

fred
Posts: 19
Joined: Wed Feb 27, 2013 4:32 pm

SSD1963 driver update

Postby fred » Thu Mar 14, 2013 2:27 pm

Hi Tectu et alii,

a week ago I received a new SSD1963 5" TFT but it didn't work out of the box 100%. I updated the src for the driver, added the beginnings of a BG dimmer and crammed in some comments (a lot of that LCD stuff is pretty esoteric).

The dimmer code is functional but not in its current implementation. When I test gdisp_lld_bg_dimmer() as a seperate function called by a brighter/darker button it behaves normally, but I implemented it by passing it to gdisp_lld_control() as intended by the src and it only dims for a fraction of a second. Somehow a refresh is happening after dimming so I'll have to look into that.

I also added an example I found to control the 4 GPIO pins on the SSD1963. I don't have real use for it (enough pins on the STM32) but I hope to turn that into a seperate getter/setter.

regards,
Fred
Attachments
SSD1963.rar
(10.42 KiB) Downloaded 370 times

User avatar
Tectu
Posts: 1226
Joined: Thu May 10, 2012 9:50 am
Location: Switzerland
Contact:

Re: SSD1963 driver update

Postby Tectu » Thu Mar 14, 2013 7:00 pm

Hey fred,

I thank you very, very much for your work and the contribution of it! Getting a rework of the SSD1963 driver is something I waited for so long. I gave your work a quick check and man - this is very good quality! I like the comments - I should definitely write more comments in my code as well :D

I'm not sure what causes the refresh problem in the control routine. The control routine is definitely NOT called periodically, so even if you messed something up in the GDISP struct, it shouldn't have any affect until you recall the function.

I replaced the old driver by your work. You've also been mentioned in the release.txt as well as in the credits table. I've also written a blog post about your work. Let me know your real name in case of you'd appreciate seeing it there :)

I hope to receive future contributions from you! :D



~ Tectu

petr
Posts: 7
Joined: Mon Jul 30, 2012 8:54 pm

Re: SSD1963 driver update

Postby petr » Fri Mar 15, 2013 10:35 am

Hi,
thanks for the updated driver. I am trying to figure out the correct values to put in gdisp_lld_panel.h and I am not sure how to read the datasheet. What are the values for HPS/LPS, VPS/FPS? I don't quite understand the STHD[7:0]-26 and STVD[6:0]-9. I attached the datasheet.
Thanks,
Petr
Attachments
5inch display .pdf.bz2
datasheet
(1.04 MiB) Downloaded 171 times

mobyfab
Posts: 446
Joined: Sat Nov 19, 2011 6:47 pm
Location: Versailles, France
Has thanked: 8 times
Been thanked: 17 times

Re: SSD1963 driver update

Postby mobyfab » Fri Mar 15, 2013 1:46 pm

I have synced the repo, I will make some tests as soon as I have time.

Thanks a lot!

fred
Posts: 19
Joined: Wed Feb 27, 2013 4:32 pm

Re: SSD1963 driver update

Postby fred » Fri Mar 15, 2013 3:45 pm

petr wrote:Hi,
thanks for the updated driver. I am trying to figure out the correct values to put in gdisp_lld_panel.h and I am not sure how to read the datasheet. What are the values for HPS/LPS, VPS/FPS? I don't quite understand the STHD[7:0]-26 and STVD[6:0]-9. I attached the datasheet.
Thanks,
Petr


Looking into it...

fred
Posts: 19
Joined: Wed Feb 27, 2013 4:32 pm

Re: SSD1963 driver update

Postby fred » Fri Mar 15, 2013 5:27 pm

Right, did some digging.

According to the datasheet you provided the internal driver that translates the digital input to analog signals for the TFT transistors is HX8258-A (two of them) and a HX8662-C. The HX8662-C drives the gate of the transistors, so this component is critical on those timings. In it's datasheet for a different 800*480 module it states that the first data starts from the 68th clock after Hsync falling - looks like the HSYNC_BACK_PORCH but without the STHD nonsense. The reason for the STHD[7:0]-26 and STVD[6:0]-9 is probably clipping of the display area, the STDH and STDV can be used to set a clipped distance when the chips are implemented for smaller resolution screen, but that's a guesstimation. The datasheet you provided is odd in that it specifies active time periods that are half of the resolution (400 and 240) hence my suspicion of these clipping values.

SCREEN_HSYNC_BACK_PORCH = 68 (according to your doc this must be > 8, note ii p5)
SCREEN_HSYNC_PERIOD = HT = 1056 (nominal 528 in your doc, but remember that's for half the horizontal pixels - we get 928 for an HS Active Time of 800)
SCREEN_HSYNC_PULSE = 128 (nominal 46 in your doc)

=> SCREEN_HSYNC_FRONT_PORCH = SCREEN_HSYNC_PERIOD - ( SCREEN_HSYNC_PULSE + SCREEN_HSYNC_BACK_PORCH + GDISP_SCREEN_WIDTH)
= 1056 - (128 + 68 + 800)
= 60

SCREEN_VSYNC_PERIOD = VT = 525 (nominal 262 in your doc, but remember that that's for half the vertical pixels - we get 502 for an VS Active Time of 480)
SCREEN_VSYNC_PULSE = 2 (also nominal 2 in your doc)

=> SCREEN_VSYNC_FRONT_PORCH = SCREEN_VSYNC_PERIOD - ( SCREEN_VSYNC_PULSE + SCREEN_VSYNC_BACK_PORCH + GDISP_SCREEN_HEIGHT)
= 525 - (2 + SCREEN_VSYNC_BACK_PORCH + 480)
= 43 - SCREEN_VSYNC_BACK_PORCH

According to your doc, SCREEN_VSYNC_BACK_PORCH must be > 0 (note iii p5) e.g.
SCREEN_VSYNC_BACK_PORCH = 2
SCREEN_VSYNC_FRONT_PORCH = 41

So that leaves us with SCREEN_HSTART_POSITION and SCREEN_VSTART_POSITION. I think those are the subtracted values in STHD[7:0]-26 and STVD[6:0]-9:
SCREEN_HSTART_POSITION = 26
SCREEN_VSTART_POSITION = 9

To the best of my knowledge these are the values to start with but take into account the cryptic nature of the datasheet and the fact that I'm pumped up on caffeine to get through the Friday ;)
Attachments
HX8662C.rar
(695.28 KiB) Downloaded 163 times

petr
Posts: 7
Joined: Mon Jul 30, 2012 8:54 pm

Re: SSD1963 driver update

Postby petr » Fri Mar 15, 2013 7:34 pm

Hello fred,
thanks for help, but unfortunately it doesn't work. I tried googling STHD/STVD in the morning and it appears in numerous datasheets, but I didn't find what it could mean. In some datasheets it is equivalent to a fixed value. Could it be time to transfer n bits of data?
I will continue scratching my head a little more.
Petr

fred
Posts: 19
Joined: Wed Feb 27, 2013 4:32 pm

Re: SSD1963 driver update

Postby fred » Sat Mar 16, 2013 11:00 am

Could you elaborate on what's happening when you run your code? If the timing is severely off you normally get part of the LCD content with garbage on the others sides. If the timings are moderately off you get shimmering effects, noisy colors. Another symptom is noisy edges which points to bad connections on the power supply. Screen freezing and "bleeding" from the edge inwards points at bad pin configurations on the IOs.

petr
Posts: 7
Joined: Mon Jul 30, 2012 8:54 pm

Re: SSD1963 driver update

Postby petr » Sun Mar 17, 2013 12:55 pm

Hi,
I don't get anything on the screen, it is simply white, backlight on and nothing on the screen. Same effect like just manually turning on the backlight. This makes me thing that I could have incorrectly setup pin modes. I have the screen connected to F3 discovery via gpio. I also noticed that the screen seems to be drawing a lot of current from the discovery board, even though it is connected to an external 3.3V source.
I have set the pins for the lcd in board.h to PIN_MODE_OUTPUT(GPIOD_PIN0) PIN_OTYPE_PUSHPULL(GPIOD_PIN0) PIN_OSPEED_100M(GPIOD_PIN0) PIN_PUPDR_PULLUP(GPIOD_PIN0) PIN_ODR_LOW(GPIOD_PIN0) PIN_AFIO_AF(GPIOD_PIN0, 0)
Is this actually necessary? I think there is a pin setup in the LCD code, right?

User avatar
Tectu
Posts: 1226
Joined: Thu May 10, 2012 9:50 am
Location: Switzerland
Contact:

Re: SSD1963 driver update

Postby Tectu » Sun Mar 17, 2013 1:09 pm

I just took the first look to the work of fred. The driver does not really match the GDISP structure. There should be board files so no #define for the interfaces are in the actual driver source code. Also, the GDISP_LLD() macro has become obsolete.
fred, could you please take the SSD1289 driver as a template and rework the structure?


~ Tectu


Return to “LCD Driver and Graphic Framework”

Who is online

Users browsing this forum: No registered users and 1 guest