Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

TFT LCD Display - where is the circuitry?

  1. Feb 15, 2016 #1
    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 [Broken] 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
    Last edited by a moderator: May 7, 2017
  2. jcsd
  3. Feb 15, 2016 #2


    User Avatar
    Gold Member

    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.
  4. Feb 15, 2016 #3
    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...

    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...
  5. Feb 15, 2016 #4
    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!:

    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...
  6. Feb 15, 2016 #5


    User Avatar
    Gold Member

    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.

  7. Feb 15, 2016 #6
    Thanks for the help!

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

    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...

    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):

    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...
    Last edited: Feb 15, 2016
  8. Feb 15, 2016 #7
    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..
  9. Feb 16, 2016 #8


    User Avatar
    Gold Member

    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.
  10. Feb 16, 2016 #9
    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 [Broken]):

    (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).

    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?
    Last edited by a moderator: May 7, 2017
  11. Feb 16, 2016 #10
  12. Feb 17, 2016 #11
    One of the best illustrations I've found so far on how a basic driver circuit/IC works is from that datasheet:

  13. Feb 17, 2016 #12


    User Avatar
    Gold Member

    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.
Share this great discussion with others via Reddit, Google+, Twitter, or Facebook