TFT LCD Display - where is the circuitry?

[1rel]

Today, I've been looking into TFT LCD display tech for a bit, trying to figure out how pixels are actually colored on the screen. - A) Out of necessity, because I'm trying to build a small ARM microcontroller powered board with a display on it. B) And out of curiosity, because I don't really understand how the process works.

@A) The microcontroller I'm trying to use is a http://www.st.com/web/en/resource/technical/document/reference_manual/DM00124865.pdf or F4 with a built in display controller called LTDC (LCD TFT Display Controller). So, the display should be hooked up directly to the microcontroller, instead of using one of those popular on ebay, that already come with a display controller (like S6D0129, SSD1963, ILI9341, HX8312 etc.). I guess this makes sense, since it's more direct and cheaper this way... The interface I plan to use is parallel 16-bit RGB565. I've found that display to match those criteria.

@B) I try to figure out how this actually works, how the color values actually get to the screen's pixels. - As far as I know, the 16 bits of color information are sampled by the display at a steady rate, according to the pulses on the clock pin. The bits describing the R, G, B components of every pixel are then converted to an analog voltage by an DAC (gray scale voltage?), which is then stored in the pixel's capacitors -- three of them per pixel -- controlling the brightness of the color components. The three thin-film transistors (TFT) MOSFETs per pixel are used to "sample" the DACs voltage, when they are opened by the gate driver lines. It is called an active matrix display, because it can store the information until the refresh cycle...

I also don't understand the physics/material science behind the LCD tech. But that's for later... - What I'd like to understand at the moment, is how a "controller-less" display like the one above actually does all the needed tasks, like ADC conversion, sampling, shifting etc. - Where are those ICs, are they embedded into the display itself, also "printed" with TFTs onto the glass? - I have no clue about all that... And can't find much info by searching around. As far as I can tell, there are just a couple of passive components on the flat flex cable, but that's it. No standard ICs...

What kind of control circuitry is doing that job? Where can read more about all this? - I've found some things by searching around, but nothing too clear. - This patent seems to be quite comprehensive: http://www.google.com/patents/EP2075790A2?cl=en , but it's too much for me.. :P

 

[meBigGuy]

Your display link brings up a digikey index page, not a spec sheet. Can you post a link to the display.

Display controllers have an on board display memory that they access in the proper sequence and at the proper rates to send the RGB information to the matrix. You will be doing all that in your firmware.

 

[1rel]

Your display link brings up a digikey index page, not a spec sheet. Can you post a link to the display.

Sorry for that, digikey links don't seem to work. The display has that digikey number: NHD-2.4-240320CF-CSXN#-FT-ND
Newhaven Display Intl NHD-2.4-240320CF-CSXN#-FT

I've found it just by filtering the DigiKey index by looking for RGB565, I don't know if really should use that one...

Display controllers have an on board display memory that they access in the proper sequence and at the proper rates to send the RGB information to the matrix. You will be doing all that in your firmware.

Thanks, that's what I was thinking too... one can configure the display controller in the STM32 micro with various parameters to drive a wide range of different displays. That will be tricky to get right I guess.

The DACs, gate drivers etc. are physically embedded into the enclosure of the display? There is not much information on any of those controllers for most displays I've looked into... I've disassembled a couple of displays a while ago, and can't remember how the physical construction really looks like, I'm just a bit curious about how this last stage of controlling the pixels really works...

Do you know any resources to find out more about how this is actually constructed? There's not much in the datasheet on that part... I'm trying to find a simple block diagram with the wiring etc...

 

[1rel]

Hmm, in the datasheet there's a link to the actual controller used, it's a ST7789S on that display, I must have overseen it!:
http://www.newhavendisplay.com/app_notes/ST7789S.pdf

So there are no "controller less" displays so to say? It's just a matter of interfacing them (parallel vs serial)... - Some come with a daughter board and more advanced "additional" controller ICs, and others with just a basic controller? Are there controller ICs that have no frame buffer, just very basic digital to analog drive functionality in there? - I guess I must learn more about all this before asking...

 

[rbelli1]

In this case the details of the value->pixel conversion is handled by the controller attached to the display. The TFT controller on the CPU you have selected is a DMA transfer engine that is compatible with the protocol that is often used with those controllers. It also has some bling to help with composing the image.

If you examine the display you will find a bit of shiny metal attached somewhere. It is often epoxied to the cable. This may alternatively be on the display itself or possibly a separate circuit board connected in some way. There is likely to be a bit of patent/copyright/trade secret sauce in that controller so inquiring about the details may hit a brick wall.

BoB

 

[1rel]

Thanks for the help!

In this case the details of the value->pixel conversion is handled by the controller attached to the display. The TFT controller on the CPU you have selected is a DMA transfer engine that is compatible with the protocol that is often used with those controllers.

The MCU's TFT controller pushes out the color data from the memory (using DMA), along with the clock signal, hsync, vsync... yes.

It also has some bling to help with composing the image.

There's also a 2D accelerator in there to copy/blit regions around etc., but that's for later... I'm starting out with ARM development, so it will take some time to get this all working. - And compared to 8-bit world it's really confusing. There's so much to learn...

If you examine the display you will find a bit of shiny metal attached somewhere. It is often epoxied to the cable. This may alternatively be on the display itself or possibly a separate circuit board connected in some way. There is likely to be a bit of patent/copyright/trade secret sauce in that controller so inquiring about the details may hit a brick wall.

Heh, that's what I've also expected, but I'm surprised how much -- actually overwhelmingly much -- info on those display controllers is in the data sheets, and how complex they are...

(I still don't understand how the controller really generates the voltages applied to the "source lines" of the grid... how the DAC generates that voltage exactly. But there's a lot in those datasheets actually. Also a block diagram...

)Currently trying to figure out whether I should stick with the display above, or try to find one with a more popular ILI9341 controller (which is older than the ST7789 I think):
http://www.newhavendisplay.com/app_notes/ILI9341.pdf

Does anybody have a suggestion on ST7789 vs ILI9341?

Also realizing that I'm stuck to one type of display, when I connect the LTDC pins to a flat flex connector with the pin out fixed.

Maybe I should just route out the LTDC pins to breakout connector... since this is experiment after all. So that I can try out different types of display. Hm...

BTW there's a quite long list of (S6D0129 family) of TFT display controllers on that site: https://www.ramtex.dk/gclcd/glcd0129.htm

Display controller hardware

...8-bit, 16-bit and 32-bit parallel bus modes and serial bus modes (e.g. SPI).

Display controller types with built-in display screen driver (primarily COG types):
S6D0129, HX8312, HX8325, HX8345, HX8346, HX8347, HX8352, HX8353, HX8367, ILI9340, ILI9341, ILI9163, ILI9320, ILI9325, ILI9328, ILI9331, ILI9335, ILI9221, ILI9222, ILI9225, LGDP4524, NT39122, OTM2201, OTM3225, R61505, R61506, R61509, R61580, S6B33BF, S6D0144, S6E63D6, SEPS525, SPFD54126, SPFD5408, SPFD5420, SSD1283, SSD1284, SSD1285, SSD1286, SSD1288, SSD2119, SSD1355, SSD1298, SSD1289, ST7628, ST7735, ST7773, ST7781, ST7787, ST7789, TL1771, UC1682, UC1697, UC1698

Stand-alone display controller types for use with external display modules:
FSA506, S1D13517, S1D13742, S1D13743, SSD1960, SSD1961, SSD1962, SSD1963​

No idea yet, how those are related. S6D0129 family? - All quite confusing to me...

 

[1rel]

Some notes after looking around more:

@display controller VS display driver:
It seems, that there are displays that only come only a driver built-in. For example that one; with that driver: HX8257,
which has a much more basic feature set than the ones above (e.g. no frame buffer/ram or complex set of "commands")... I think that fits better, since the STM32 already has a controller in there (?).

@ST7789 vs ILI9341:
Some ILI9341 based products by newhaven were replaced by ST7789 based ones. So there might have some advantages..

 

[meBigGuy]

What driver is the ST32 TFT-LCD controller you are looking at designed to interface to? Have you found an application note or reference design? The software drivers would be important also.

 

[1rel]

What driver is the ST32 TFT-LCD controller you are looking at designed to interface to? Have you found an application note or reference design?

Well, it can handle quite some different interface types (it's all in the STM32 http://www.st.com/web/en/resource/technical/document/reference_manual/DM00124865.pdf ):

LTDC main features
• 24-bit RGB Parallel Pixel Output; 8 bits-per-pixel (RGB888)
• 2 display layers with dedicated FIFO (64x32-bit)
• Color Look-Up Table (CLUT) up to 256 color (256x24-bit) per layer
• Supports up to XGA (1024x768) resolution
• Programmable timings for different display panels
• Programmable Background color
• Programmable polarity for HSync, VSync and Data Enable
• Up to 8 Input color formats selectable per layer
– ARGB8888
– RGB888
– RGB565
– ARGB1555
– ARGB4444
– L8 (8-bit Luminance or CLUT)
– AL44 (4-bit alpha + 4-bit luminance)
– AL88 (8-bit alpha + 8-bit luminance)
• Pseudo-random dithering output for low bits per channel
– Dither width 2-bits for Red, Green, Blue
• Flexible blending between two layers using alpha value (per pixel or constant)
• Color Keying (transparency color)
• Programmable Window position and size
• Supports thin film transistor (TFT) color displays
• AHB master interface with burst of 16 words
• Up to 4 programmable interrupt events

The LCD-TFT controller pins must be configured by the user application. The unused pins
can be used for other purposes.
For LTDC outputs up to 24-bit (RGB888), if less than 8bpp are used to output for example
RGB565 or RGB666 to interface on 16b-bit or 18-bit displays, the RGB display data lines
must be connected to the MSB of the LCD-TFT controller RGB data lines. As an example, in
the case of an LCD-TFT controller interfacing with a RGB565 16-bit display, the LCD display
R[4:0], G[5:0] and B[4:0] data lines pins must be connected to LCD-TFT controller
LCD_R[7:3], LCD_G[7:2] and LCD_B[7:3].

(edit: there's an error in that block diagram, they place Layer 1 two times!)

Yesterday, I had to find out that with the 144 pin package I use in my project, I cannot use the true color RGB888 mode, because the pins are already consumed by the memory controller (FMC)... I don't know If RGB565 or even parallel 8-bit are really faster than just using serial (SPI).

The software drivers would be important also.

I know... it's really a difficult to decide on one part. So many factors to consider.

What also puzzels me about this topic: there's not much good info on the net about display technology (at least i couldn't find any yet), and all the cheap china displays on ebay or aliexpress have absolutely no info on pinout, dimensions, mostly no datasheet at all... - Do you know any place to find good ~320x240 displays for the use in microcontroller projects?

 

[1rel]

Some good answers for the initial question can be found in that white paper on Chip On Glass (COG) technology:
http://www.nxp.com/documents/white_paper/NXP_COG_WhitePaper.pdf

*reading it right now*

 

[1rel]

One of the best illustrations I've found so far on how a basic driver circuit/IC works is from that datasheet:

 

[meBigGuy]

You seem to be on the right track looking at all the right stuff. Good finds/references. I don't really have anything to add.