Author Topic: STM32 MCUs interfacing with LCD screens  (Read 5571 times)

0 Members and 1 Guest are viewing this topic.

Offline shakedownTopic starter

  • Contributor
  • Posts: 25
  • Country: gb
STM32 MCUs interfacing with LCD screens
« on: February 19, 2026, 10:45:13 pm »
I have used STM32F411 with small screens up to 2.8" (with ILI9341 driver). I want to make use of bigger 7" or 10" screens and I am getting overwhelmed and confused by what I have found.

Some screens I have found:

SPI or parallel 8080 or motorola 6800
https://www.buydisplay.com/serial-spi-i2c-10-1-inch-tft-lcd-module-dislay-w-ra8876-optl-touch-panel

50 pin??
https://www.aliexpress.com/item/1005008511611715.html?spm=a2g0o.productlist.main.7.4a27i3oii3oiv9&algo_pvid=38391b2d-11ef-426f-93d7-4f85cc32011a&algo_exp_id=38391b2d-11ef-426f-93d7-4f85cc32011a-6&pdp_ext_f=%7B%22order%22%3A%2249%22%2C%22eval%22%3A%221%22%2C%22fromPage%22%3A%22search%22%7D&pdp_npi=6%40dis%21GBP%2112.89%2112.89%21%21%21116.44%21116.44%21%40211b441e17715399971757750e9298%2112000045493605627%21sea%21UK%212907225413%21X%211%210%21n_tag%3A-29919%3Bd%3Af8cdf95c%3Bm03_new_user%3A-29895&curPageLogUid=HcxyuaFe5sN2&utparam-url=scene%3Asearch%7Cquery_from%3A%7Cx_object_id%3A1005008511611715%7C_p_origin_prod%3A

https://www.aliexpress.com/item/1005008011413779.html?spm=a2g0o.productlist.main.1.2bf9uE6YuE6YIJ&algo_pvid=407edbc0-4465-4f2b-8fa4-ea6a94cb89a2&algo_exp_id=407edbc0-4465-4f2b-8fa4-ea6a94cb89a2-0&pdp_ext_f=%7B%22order%22%3A%227%22%2C%22eval%22%3A%221%22%2C%22fromPage%22%3A%22search%22%7D&pdp_npi=6%40dis%21GBP%2113.29%2113.29%21%21%21120.05%21120.05%21%40211b617b17715385811323039e2abc%2112000043245026271%21sea%21UK%210%21ABX%211%210%21n_tag%3A-29910%3Bd%3Af8cdf95c%3Bm03_new_user%3A-29895&curPageLogUid=NsvoddDh7Iu9&utparam-url=scene%3Asearch%7Cquery_from%3A%7Cx_object_id%3A1005008011413779%7C_p_origin_prod%3A

I have used MCUs like F103, F401, F411, H743 and H750. Some of them have FMC, some have LCD TFT controller (according to cubeMX) and some unaffordable ones have LVDS like STM32MPXXXX.

There is also something called LVGL library, google search shows to use this with FSMC/LTDC but when I search for these two things in cubeMX nothing shows.
 
Do you use the LVGL library with parallel port? CubeMX lists LCD TFT controller and LCD parallel interface. Do I need an MCU with LCD TFT controller or LCD parallel interface to communicate with the 8080 or 6800 display?

I found a tutorial online which uses 24 pins and not 50 pins, so what do you need to drive the 50 pin displays? I have just found you can bit-bang and emulate a parallel interface too using low cost MCUs so I am going to look at that.

My question is really advice on what I could buy (MCU and LCD) to start drawing things to 7" or 10" displays. I could start with SPI but having seen the performance limitations of SPI for even small screens (<=2.8") I think I want to steer away from SPI. There are so many options and I would appreciate any suggestions. Thank you.

Edit: I just found this tutorial. He goes through different types of LCDs. Helpful.

« Last Edit: February 19, 2026, 11:02:59 pm by shakedown »
 

Offline gcrcien

  • Contributor
  • Posts: 16
  • Country: mx
Re: STM32 MCUs interfacing with LCD screens
« Reply #1 on: February 20, 2026, 04:32:42 am »
I had a question like that last week, in the comments someone ponted out the use of EVE, Embeded Video Engines, this dumbed down... Basically a GPU for your mcu.
All this will relax the load on it, all controlled by SPI, so all those 40pins reduced to 4.
As per the datasheet of one of these chips you only need a few components, the eve itself and a panel to control, im still working on implementing it on my board, so still lots to learn
 
The following users thanked this post: shakedown

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 6111
  • Country: nl
Re: STM32 MCUs interfacing with LCD screens
« Reply #2 on: February 20, 2026, 07:34:15 am »
I have no experience with the 10.1 size, but use 7 inch 50 pin ones.

A small side note, Aliexpress links don't need all the crap beyond the html specifier. So next time please only copy that part. Your 10.1 inch links:
https://www.aliexpress.com/item/1005008511611715.html
https://www.aliexpress.com/item/1005008011413779.html

Very nice find by the way, those displays are cheap.  :)

Attached is a schematic that has the needed voltage supplies and the configuration options for the displays I use.

Display 1024 x 600 https://www.aliexpress.com/item/1005005292813240.html
Display 800 x 480 https://www.aliexpress.com/item/1005003886053654.html
Touch panel (B 7 inch) https://www.aliexpress.com/item/33003864443.html

These displays should work well with the STM32H743 or any of the STM32 MCUs that have the LTCD.

I have used the setup shown in the schematic in combination with a F1C200s on a self designed board, but also in combination with the Lichee Nano, Cherry PI and the Tang Nano 20K, for which I designed another board with headers for the fore mentioned development boards.

The option mentioned by gcrcien can easily be made with a F1C100s too, but might be overkill as it is a full fledged MCU itself.  :-DD

Offline elektryk

  • Frequent Contributor
  • **
  • Posts: 284
  • Country: pl
Re: STM32 MCUs interfacing with LCD screens
« Reply #3 on: February 20, 2026, 08:13:16 am »
There is also something called LVGL library, google search shows to use this with FSMC/LTDC but when I search for these two things in cubeMX nothing shows.
Here is an example code https://github.com/lvgl/lv_port_stm32f746_disco it can be easily ported to H7.
 
The following users thanked this post: shakedown

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 8349
  • Country: fi
    • My home page and email address
Re: STM32 MCUs interfacing with LCD screens
« Reply #4 on: February 20, 2026, 08:41:24 am »
Here is a short list of possible display interfaces:
  • SPI (or 3/4-wire). Typically, even with SPI there is an extra signal line from MCU to display (D/C, DCX), indicating whether the byte being transferred is a command or data.  The data transfer rate is limited, so for larger than 320×170 or so, do not expect full-screen updates at native frame rate.
     
  • Parallel 8080/68000-style bus with commands and data.  Depending on the display controller, the bus may use 1 to 3 clock cycles per pixel; it isn't necessarily all bits of each pixel at once.  For example, most controllers support an 8-bit bus with RGB565 using two cycles per pixel and RGB666/RGB888 using three cycles per pixel.

    Both of the above require the display to contain framebuffer RAM.  The display updates are asynchronous: only changes to the displayed data (in rectangular regions) are transferred.  Read-back from display to MCU is very slow, however, and rarely used.  In my experience, the largest resolutions supported are 800×480 or 640×480, regardless of the actual display size.  These are most common in the 320×240 size range, however — the ILI9341, ST7789 and similar controllers used for these are very similar, and typically only differ by maximum clock rates and display initialization sequences, as you can see in the related open-source Arduino libraries.

    For the ones below, the MCU or SoC has to have enough RAM and bandwidth for a full framebuffer, and a dedicated peripheral controller; i.e. hardware support.
     
  • Real-time digital RGB (or, confusingly, "TTL") bus, with pixel clock, horizontal and vertical sync, possibly data enable, and one signal per pixel color bit (typically 16, 18, or 24).  All these signals are digital, one-directional from MCU to display, and strictly in sync with the physical display updates.  Essentially, the image data is being continuously refreshed.  Note that the maximum resolution among affordable display modules in early 2026 tends to be 1024×600, and size about 7", with anything larger being rare or more expensive for us hobbyists.
     
  • LVDS.  This is essentially the same as above, except with fewer conductors and using higher transmission clocks and low-voltage differential signaling.  There are even affordable (4€ - 8€ in singles at Mouser and Digikey) ICs like TI SN75LVDS84A that convert the above RGB bus to LVDS signals.  The main benefit is that being differential, much longer wires and cables can be used; especially in laptops, copper twisted pair shielded wires can be used, reducing fatique and problems from passing over the display-laptop hinge.  Also, because of the higher data rates, bigger resolutions are often supported.
     
  • MIPI DSI.  This is a very common differential digital bus for larger resolutions (although 2K and larger tend to use two or more MIPI DSI PHYs in parallel), and is very common on SBCs.  Of the STM32 MCUs, I've looked at STM32H747, which has a MIPI DSI output, but currently do not have one.  (AIUI, F469 and F769 also support MIPI DSI.)  Note that MIPI CSI is a closely related bus, but specifically for video input (cameras et cetera).
     
  • Others: eDP, HDMI, etc.  While some System-on-Chips do provide HDMI/eDP outputs, there are ICs for conversion from MIPI DSI to HDMI and vice versa, see e.g. ST B-LCDAD-HDMI1 DSI to HDMI adapter.  Because of licensing issues, as a hobbyist, it is very difficult to buy these ICs, and basically impossible to get hold of the full Technical Reference Manuals needed to implement your own circuits; but again, ready-made boards are available even at Mouser and Digikey for ~ 30€ in singles, plus of course at AliExpress et cetera from reputable manufacturers like Waveshare.
     
Currently, I myself am playing with FK743-M2 (STM32F743IIT6, schematic), which directly supports AT056TN53 (5.6" 640×480) displays and others with similar real-time RGB bus.  I also have a few LuckFox Lyras (RockChip RK3506, Wiki, includes schematic) with MIPI DSI support for up to 1280×800/800×1280, directly compatible with several Waveshare displays (including 8-DSI-TOUCH-A), but is targeted towards Linux use, not bare metal.  The full RK3506 reference manual is not freely available, either.

When selecting a display, note that some displays require multiple voltages (VCOM, VGL, VGH) to drive the pixel element MOSFET gates; more recent displays use controller chips with built-in (capacitive) voltage generators.  As an example, AT056TN53 uses 3.3V logic, and 5V for its LED backlight circuit.  Because of this, my own approach is to find a display or compatible set of displays I like first — and especially find the datasheet and pinout, because those are often not available! —, then see if and how I can drive them.

As an example, BuyDisplay ER-TFT080-3, Panox AU080L1280M, and P0801-B4EI31H-37R501 are all 8" displays with 800×1280 resolution, and compatible 31-pin MIPI DSI connection, with direct connection to backlight LEDs with forward voltage 9V-10V at 100mA-140mA (and thus very suitable for cheap, no-flicker, current-controlled LED backlight boost chips).  But do require MIPI DSI.

A small side note, Aliexpress links don't need all the crap beyond the html specifier. So next time please only copy that part. Your 10.1 inch links:
https://www.aliexpress.com/item/1005008511611715.html
https://www.aliexpress.com/item/1005008011413779.html
These are similar to SH090JGI50, a 9" 1024×600 display with RGB interface that you can find at AliExpress for about 24€ shipped with an IPS panel (visible from any viewing angle).  Although all these use 3.3V logic levels (suitable for driving from STM32), they also require VCOM (to be adjusted per unit in range 4.0-4.6V, most datasheets show the required voltage divider circuitry with a potentiometer to be adjusted at manufacturing time), VGL (-8V), and VGH (+18V), plus current-controlled LED boost driver, since the LED chain cathode and anode is exposed.  The needed circuitry (a small interface board, for example, to interface to FK743M2-IIT6) is not difficult or expensive, but I personally am weak on multi-voltage supplies, so for larger than 7", I've used MIPI DSI instead.  For example, the way pcprogrammer's schematic uses a single TP61041 to generate 15.8V, 10.3V, and -6.3V, is completely new to me; I do understand it, but would not have thought of doing it that way myself.  (VGH and VGL are just gate driving voltages, so don't need to be any particular voltages as long as they're within the datasheet specified range, and stable.)
 
The following users thanked this post: Kjelt, tooki, pcprogrammer, __george__, shakedown

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 6111
  • Country: nl
Re: STM32 MCUs interfacing with LCD screens
« Reply #5 on: February 20, 2026, 10:15:06 am »
A small side note, Aliexpress links don't need all the crap beyond the html specifier. So next time please only copy that part. Your 10.1 inch links:
https://www.aliexpress.com/item/1005008511611715.html
https://www.aliexpress.com/item/1005008011413779.html
These are similar to SH090JGI50, a 9" 1024×600 display with RGB interface that you can find at AliExpress for about 24€ shipped with an IPS panel (visible from any viewing angle).  Although all these use 3.3V logic levels (suitable for driving from STM32), they also require VCOM (to be adjusted per unit in range 4.0-4.6V, most datasheets show the required voltage divider circuitry with a potentiometer to be adjusted at manufacturing time), VGL (-8V), and VGH (+18V), plus current-controlled LED boost driver, since the LED chain cathode and anode is exposed.  The needed circuitry (a small interface board, for example, to interface to FK743M2-IIT6) is not difficult or expensive, but I personally am weak on multi-voltage supplies, so for larger than 7", I've used MIPI DSI instead.  For example, the way pcprogrammer's schematic uses a single TP61041 to generate 15.8V, 10.3V, and -6.3V, is completely new to me; I do understand it, but would not have thought of doing it that way myself.  (VGH and VGL are just gate driving voltages, so don't need to be any particular voltages as long as they're within the datasheet specified range, and stable.)

Hi Nominal Animal, I see that you are back from your vacation.  :)  (Although this time no one started a thread about it)

To be honest, I did not design that LCD voltage supply setup myself. I copied it from the FNIRSI 1013D design, but did refine the backlight brightness control to not make use of the enable input of the TP4103. This way there is no annoying noise from the coil when dimming the display.

Good to know about the 10.1 inch displays needing other voltages and to have a part number to go hunt for a datasheet.  :-+

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 3012
  • Country: br
    • CADT Homepage
Re: STM32 MCUs interfacing with LCD screens
« Reply #6 on: February 20, 2026, 10:27:45 am »
When looking for a solution to replace worn out Advantest 6581T displays by TFT displays, i arrived at a fairly nice and simple solution. The project archive is here:
https://www.eevblog.com/forum/repair/advantest-r6581-vfd-replacement/msg5693023/#msg5693023
Also there is a circuit diagram in a follow-up post.
The solution is based on STM32H730 and its built-in digital video output peripheral. That peripheral supports a 256 color palette mode with one byte per pixel, so the whole video memory fits inside H730 RAM. That display peripheral is fairly flexible and as far as i remember it will drive a 10" display. With the display memory on its internal bus graphics operations by the MCU are very efficient.

Regards, Dieter
« Last Edit: February 20, 2026, 12:35:32 pm by dietert1 »
 
The following users thanked this post: shakedown

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 8349
  • Country: fi
    • My home page and email address
Re: STM32 MCUs interfacing with LCD screens
« Reply #7 on: February 20, 2026, 11:38:01 am »
The reason I got a FK743M2 development board is that it is simple enough to do my own hobbyist boards based on, but still has 8 MiB of SDRAM available for a much larger framebuffer.  SDRAM is obviously not as fast as SRAM would be, but STM32H743II (Cortex-M7) only runs at 480 MHz anyway, and it does have internal caches so cache-sensitive approaches (which I'm very familiar with, having worked on HPC on Intel/AMD) ought to yield "sufficient" performance.  (FK743M2 boards are labeled as such on the bottom side; the ones with STM32H7 Core stenciled on the front side are a different board.  I paid only 16.60€ for mine, including shipping to Finland, but the seller increased the price to 30€.)

In comparison, LuckFox Lyra and RK3506 system-on-modules exposing all pins with 128M to 512M DDR3L memory (and optionally 8 GB of eMMC storage) are available in various configurations at AliExpress for 15€ - 30€ including shipping.  RK3506 is a triple-core ARM Cortex-A7 (ARMv7-A, VFPv4-D32) running at up to 1.5 GHz, with an additional Cortex-M0 (ARMv6-M Thumb2) core, a full separate 2D graphics engine/blitter with support up to 1280×1280 (so no FullHD!), hardware RGB and two-lane MIPI DSI video output (although only MIPI DSI is currently well supported in Linux and in open documentation, and is limited to 1280×1280 or less), and FlexBus for parallel I/O (although pinout is very restricted and overlaps with video stuff).  The FPC on the board is the same 22-pin as the DSI connector on various Raspberry Pi's, but only the 15 pins (two DSI lanes) are connected, similar to when using Raspberry Pi 5 with a 15-to-22 pin FFC.  Again, the main downside with RK3506 is that only the first half of the Technical Reference Manual is easily available.  Also, for Linux use, support is being upstreamed, but one may have to use the LuckFox images or RockChip kernel forks for full functionality.  I intend to do bare metal myself.

My own main use case is to add displays to Linux-based appliances via USB 2.0 High Speed.

On STM32H743IIT6, one does need an additional ULPI transceiver like Microchip USB3320, but it costs less than 2€ in singles.  Similarly, one can add LVDS support by connecting the RGB outputs to a SN75LVDS84ADDGR, which I can get from Mouser/LCSC etc. for under 5€ in singles, and is very straightforward to use.  For MIPI DSI, STM32H743IIT6 is not suitable.  The pinout I'll use in my own design for STM32H743IIT6 differs from the FK743M2 a bit (alternate pins used in several cases), and is
where the DCMI (parallel 8-bit video camera interface) and 24-bit RGB interfaces are 5V tolerant, external Flash and 16-bit SDRAM are exposed, both the full-speed USB 2.0 OTG and the ULPI pins for the second USB 2.0 high-speed pins are exposed, leaving 21 5V tolerant GPIO pins, one 3.3V tolerant GPIO pins, and the two ADC pins.  The SDRAM signal routing is not optimal, but I do believe a working PCB is doable even by a hobbyist like me.  Both the schematic and PCB symbols can be found at EasyEDA.  Obviously, I'm heavily relying on the FK743M2 schematic and STM32H datasheets and references, though.

The solution is based on STM32H730 and its built-in digital video output peripheral. That peripheral supports a 256 color palette mode with one byte per pixel, so the whole video memory fits inside H730 RAM.
The LTDC (RGB display output) on STM32H743 supports that also (see reference manual chapter 32), plus 32-, 24-, and 16-bit color in a few different configurations — and two separate layers, if you have the memory, with per-pixel opacity.  That is, first framebuffer is drawn "below" the second one, both having their own in-memory formats, with the second layer supporting alpha (opacity) attribute, 8-bit in 32-bit ARGB / 1-bit in 16-bit RGB / 4-bit in 12-bit RGB modes.  The 256 color palette mode does not support opacity, though.
« Last Edit: February 21, 2026, 07:59:59 am by Nominal Animal »
 
The following users thanked this post: shakedown

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 6054
  • Country: gb
  • Doing electronics since the 1960s...
Re: STM32 MCUs interfacing with LCD screens
« Reply #8 on: February 20, 2026, 04:13:13 pm »
I suggest a search of previous threads here because I went around this stuff myself and posted about it extensively.

https://www.eevblog.com/forum/microcontrollers/fonts-and-driving-lcd-controllers-for-drawing-text/msg5956073/#msg5956073
https://www.eevblog.com/forum/microcontrollers/looking-for-some-simple-tips-on-resistive-touch-panel-on-an-lcd/msg6017435/#msg6017435
https://www.eevblog.com/forum/microcontrollers/anyone-here-using-the-ramtex-graphics-library/msg5838067/#msg5838067
https://www.eevblog.com/forum/microcontrollers/screen-tearing-on-lcd-displays/msg5640281/#msg5640281
Also Search for ILI9488.

For these larger screens you will probably want parallel, probably 24 bit, not any kind of serial interface. I am using 21MHz SPI with DMA which is too slow for a lot of stuff even at 320x480, regardless of the speed of the CPU.

But it depends on what you want. One can do slick graphics with a slow interface, depending on how much needs to be modified.
« Last Edit: February 20, 2026, 05:15:36 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 
The following users thanked this post: shakedown

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 3012
  • Country: br
    • CADT Homepage
Re: STM32 MCUs interfacing with LCD screens
« Reply #9 on: February 20, 2026, 05:54:20 pm »
Yes, i also used those Chinese 4" 320x480 touch displays with SPI. The ILI9488 controller is quite dumb and a pixel-by-pixel refresh of the complete screen over SPI takes about 200 msec or so. But it provides the video memory. So it takes 99% of the load from the MCU.
Running the touch controller and the display controller both on the same SPI bus required an extra gate as the SPI output of the ILI9488 does not 3-state.

Regards, Dieter
 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 6054
  • Country: gb
  • Doing electronics since the 1960s...
Re: STM32 MCUs interfacing with LCD screens
« Reply #10 on: February 20, 2026, 06:32:24 pm »
Yes; most MCUs don't have enough RAM to hold the video buffer for a 320x480 24 bit RGB display, and still do something useful :)

In the LVGL context, AFAICT (didn't go for LVGL in the end) this means if you are doing overlaying-object graphics (like the "classic" analog clock) LVGL will be using the heap.

Even 8 bit parallel would speed up graphics massively, and 24 bit parallel much more again.

Interesting you were doing display readback. I totally avoided that.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline shakedownTopic starter

  • Contributor
  • Posts: 25
  • Country: gb
Re: STM32 MCUs interfacing with LCD screens
« Reply #11 on: February 21, 2026, 11:31:16 pm »
I have no experience with the 10.1 size, but use 7 inch 50 pin ones.

A small side note, Aliexpress links don't need all the crap beyond the html specifier. So next time please only copy that part. Your 10.1 inch links:
https://www.aliexpress.com/item/1005008511611715.html
https://www.aliexpress.com/item/1005008011413779.html

Very nice find by the way, those displays are cheap.  :)

Attached is a schematic that has the needed voltage supplies and the configuration options for the displays I use.

Display 1024 x 600 https://www.aliexpress.com/item/1005005292813240.html
Display 800 x 480 https://www.aliexpress.com/item/1005003886053654.html
Touch panel (B 7 inch) https://www.aliexpress.com/item/33003864443.html

These displays should work well with the STM32H743 or any of the STM32 MCUs that have the LTCD.

I have used the setup shown in the schematic in combination with a F1C200s on a self designed board, but also in combination with the Lichee Nano, Cherry PI and the Tang Nano 20K, for which I designed another board with headers for the fore mentioned development boards.

The option mentioned by gcrcien can easily be made with a F1C100s too, but might be overkill as it is a full fledged MCU itself.  :-DD

I was wondering how to shorten those URLs. Thanks for the tip.

So then am I right in thinking when LCDs are being sold as "50-pin" they mean that it has an LTDC (LCD TFT Display Controller) interface? Like when they sell them as "3/4-wire" it usually means SPI interface.

Is F1C100 one of the all-winner chips? I want to be able to make my own SBC one day too.  :-+
 

Offline shakedownTopic starter

  • Contributor
  • Posts: 25
  • Country: gb
Re: STM32 MCUs interfacing with LCD screens
« Reply #12 on: February 21, 2026, 11:44:38 pm »
Here is a short list of possible display interfaces:
  • SPI (or 3/4-wire). Typically, even with SPI there is an extra signal line from MCU to display (D/C, DCX), indicating whether the byte being transferred is a command or data.  The data transfer rate is limited, so for larger than 320×170 or so, do not expect full-screen updates at native frame rate.
     
  • Parallel 8080/68000-style bus with commands and data.  Depending on the display controller, the bus may use 1 to 3 clock cycles per pixel; it isn't necessarily all bits of each pixel at once.  For example, most controllers support an 8-bit bus with RGB565 using two cycles per pixel and RGB666/RGB888 using three cycles per pixel.

    Both of the above require the display to contain framebuffer RAM.  The display updates are asynchronous: only changes to the displayed data (in rectangular regions) are transferred.  Read-back from display to MCU is very slow, however, and rarely used.  In my experience, the largest resolutions supported are 800×480 or 640×480, regardless of the actual display size.  These are most common in the 320×240 size range, however — the ILI9341, ST7789 and similar controllers used for these are very similar, and typically only differ by maximum clock rates and display initialization sequences, as you can see in the related open-source Arduino libraries.

    For the ones below, the MCU or SoC has to have enough RAM and bandwidth for a full framebuffer, and a dedicated peripheral controller; i.e. hardware support.
     
  • Real-time digital RGB (or, confusingly, "TTL") bus, with pixel clock, horizontal and vertical sync, possibly data enable, and one signal per pixel color bit (typically 16, 18, or 24).  All these signals are digital, one-directional from MCU to display, and strictly in sync with the physical display updates.  Essentially, the image data is being continuously refreshed.  Note that the maximum resolution among affordable display modules in early 2026 tends to be 1024×600, and size about 7", with anything larger being rare or more expensive for us hobbyists.
     
  • LVDS.  This is essentially the same as above, except with fewer conductors and using higher transmission clocks and low-voltage differential signaling.  There are even affordable (4€ - 8€ in singles at Mouser and Digikey) ICs like TI SN75LVDS84A that convert the above RGB bus to LVDS signals.  The main benefit is that being differential, much longer wires and cables can be used; especially in laptops, copper twisted pair shielded wires can be used, reducing fatique and problems from passing over the display-laptop hinge.  Also, because of the higher data rates, bigger resolutions are often supported.
     
  • MIPI DSI.  This is a very common differential digital bus for larger resolutions (although 2K and larger tend to use two or more MIPI DSI PHYs in parallel), and is very common on SBCs.  Of the STM32 MCUs, I've looked at STM32H747, which has a MIPI DSI output, but currently do not have one.  (AIUI, F469 and F769 also support MIPI DSI.)  Note that MIPI CSI is a closely related bus, but specifically for video input (cameras et cetera).
     
  • Others: eDP, HDMI, etc.  While some System-on-Chips do provide HDMI/eDP outputs, there are ICs for conversion from MIPI DSI to HDMI and vice versa, see e.g. ST B-LCDAD-HDMI1 DSI to HDMI adapter.  Because of licensing issues, as a hobbyist, it is very difficult to buy these ICs, and basically impossible to get hold of the full Technical Reference Manuals needed to implement your own circuits; but again, ready-made boards are available even at Mouser and Digikey for ~ 30€ in singles, plus of course at AliExpress et cetera from reputable manufacturers like Waveshare.
     
Currently, I myself am playing with FK743-M2 (STM32F743IIT6, schematic), which directly supports AT056TN53 (5.6" 640×480) displays and others with similar real-time RGB bus.  I also have a few LuckFox Lyras (RockChip RK3506, Wiki, includes schematic) with MIPI DSI support for up to 1280×800/800×1280, directly compatible with several Waveshare displays (including 8-DSI-TOUCH-A), but is targeted towards Linux use, not bare metal.  The full RK3506 reference manual is not freely available, either.

When selecting a display, note that some displays require multiple voltages (VCOM, VGL, VGH) to drive the pixel element MOSFET gates; more recent displays use controller chips with built-in (capacitive) voltage generators.  As an example, AT056TN53 uses 3.3V logic, and 5V for its LED backlight circuit.  Because of this, my own approach is to find a display or compatible set of displays I like first — and especially find the datasheet and pinout, because those are often not available! —, then see if and how I can drive them.

As an example, BuyDisplay ER-TFT080-3, Panox AU080L1280M, and P0801-B4EI31H-37R501 are all 8" displays with 800×1280 resolution, and compatible 31-pin MIPI DSI connection, with direct connection to backlight LEDs with forward voltage 9V-10V at 100mA-140mA (and thus very suitable for cheap, no-flicker, current-controlled LED backlight boost chips).  But do require MIPI DSI.

A small side note, Aliexpress links don't need all the crap beyond the html specifier. So next time please only copy that part. Your 10.1 inch links:
https://www.aliexpress.com/item/1005008511611715.html
https://www.aliexpress.com/item/1005008011413779.html
These are similar to SH090JGI50, a 9" 1024×600 display with RGB interface that you can find at AliExpress for about 24€ shipped with an IPS panel (visible from any viewing angle).  Although all these use 3.3V logic levels (suitable for driving from STM32), they also require VCOM (to be adjusted per unit in range 4.0-4.6V, most datasheets show the required voltage divider circuitry with a potentiometer to be adjusted at manufacturing time), VGL (-8V), and VGH (+18V), plus current-controlled LED boost driver, since the LED chain cathode and anode is exposed.  The needed circuitry (a small interface board, for example, to interface to FK743M2-IIT6) is not difficult or expensive, but I personally am weak on multi-voltage supplies, so for larger than 7", I've used MIPI DSI instead.  For example, the way pcprogrammer's schematic uses a single TP61041 to generate 15.8V, 10.3V, and -6.3V, is completely new to me; I do understand it, but would not have thought of doing it that way myself.  (VGH and VGL are just gate driving voltages, so don't need to be any particular voltages as long as they're within the datasheet specified range, and stable.)

Thank you for such a comprehensive answer. Lots to learn for me. I looked at MIPI DSI previously and when I found some of the STM32 dev boards with MIPI DSI they were cost-wise too much as just a hobbyist but it seems like there are some cheap STM32H747 boards on ali express. Like you mentioned there are some ready-made boards/converters for MIPI to HDMI, does this mean an STM32H747 can support even larger screens at 1080p resolution? (https://www.olimex.com/Products/IoT/ESP32-P4/MIPI-HDMI/open-source-hardware).
 

Offline langwadt

  • Super Contributor
  • ***
  • Posts: 5807
  • Country: dk
Re: STM32 MCUs interfacing with LCD screens
« Reply #13 on: February 21, 2026, 11:48:14 pm »

So then am I right in thinking when LCDs are being sold as "50-pin" they mean that it has an LTDC (LCD TFT Display Controller) interface? Like when they sell them as "3/4-wire" it usually means SPI interface.

generally, 50 pin means RGB (like from the LTDC) and you have to supply the extra analog +/- voltages for the display, 40 pins similar but generation of  extra voltages are build into the display
 
The following users thanked this post: shakedown

Offline shakedownTopic starter

  • Contributor
  • Posts: 25
  • Country: gb
Re: STM32 MCUs interfacing with LCD screens
« Reply #14 on: February 21, 2026, 11:50:46 pm »
I suggest a search of previous threads here because I went around this stuff myself and posted about it extensively.

https://www.eevblog.com/forum/microcontrollers/fonts-and-driving-lcd-controllers-for-drawing-text/msg5956073/#msg5956073
https://www.eevblog.com/forum/microcontrollers/looking-for-some-simple-tips-on-resistive-touch-panel-on-an-lcd/msg6017435/#msg6017435
https://www.eevblog.com/forum/microcontrollers/anyone-here-using-the-ramtex-graphics-library/msg5838067/#msg5838067
https://www.eevblog.com/forum/microcontrollers/screen-tearing-on-lcd-displays/msg5640281/#msg5640281
Also Search for ILI9488.

For these larger screens you will probably want parallel, probably 24 bit, not any kind of serial interface. I am using 21MHz SPI with DMA which is too slow for a lot of stuff even at 320x480, regardless of the speed of the CPU.

But it depends on what you want. One can do slick graphics with a slow interface, depending on how much needs to be modified.

Thank you. I will read through your posts.

This is why I want to stop using SPI. I was at first using STM32 HAL to use SPI DMA and then I thought HAL is too slow so I made my own drivers and even then it did not improve performance that much. e.g. I was drawing text to the screen which needed to be updated fast, even when only updating the pixels required, you can see what seem like artifacts because you can tell it is clearing old text/shapes with new.
« Last Edit: February 21, 2026, 11:54:27 pm by shakedown »
 

Offline shakedownTopic starter

  • Contributor
  • Posts: 25
  • Country: gb
Re: STM32 MCUs interfacing with LCD screens
« Reply #15 on: February 21, 2026, 11:53:06 pm »

So then am I right in thinking when LCDs are being sold as "50-pin" they mean that it has an LTDC (LCD TFT Display Controller) interface? Like when they sell them as "3/4-wire" it usually means SPI interface.

generally, 50 pin means RGB (like from the LTDC) and you have to supply the extra analog +/- voltages for the display, 40 pins similar but generation of  extra voltages are build into the display

Ok that makes sense especially what Nominal Animal was saying before about some displays needing multiple voltages (VCOM, VGL, VGH).
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 8349
  • Country: fi
    • My home page and email address
Re: STM32 MCUs interfacing with LCD screens
« Reply #16 on: February 22, 2026, 06:06:04 am »
Wrt. pin count, in my experience: Yes, you can typically say that for RGB interface, the display has to have a connector with at least 40 pins.  However, that is not sufficient; the pinouts vary a lot!

That is why it is so important to get the datasheet for that particular display.  (Technically, we need the pinout on the connector, the LED backlight properties — nominal voltage at nominal current —, the power-on sequence, signal timing, and the display timing blanking/total/porch characteristics.)

As an example, N070ICN-GB1 and ER-TFT080-3 are MIPI DSI displays with 31-pin FFC connector, with electrically compatible signaling and even backlight voltage/current, but the pinout — order of signals in the 31-pin connector — is completely different: plugging one into a connector compatible with the other, almost certainly burns out something.  Yet, if you have a funky two-sided FFC or a small PCB with two 31-pin FPC connectors made at say JLCPCB that just routes/reorders the signals, you can support either display with the same host board.

(And yes, the datasheet hunt is the most annoying part about this, especially when looking at AliExpress/eBay offerings.)
« Last Edit: February 22, 2026, 06:10:09 am by Nominal Animal »
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 6111
  • Country: nl
Re: STM32 MCUs interfacing with LCD screens
« Reply #17 on: February 22, 2026, 07:07:51 am »
(And yes, the datasheet hunt is the most annoying part about this, especially when looking at AliExpress/eBay offerings.)

That is an understatement.  :-DD

It is almost impossible to find the datasheet for any of those displays offered on Aliexpress, and the sellers are no help either, as they don't have them either.

I ordered this one, just for the fun of it: https://www.aliexpress.com/item/1005008811499591.html No datasheet found so far. The similar 9 inch mentioned by Nominal Animal does give some information, but not a real datasheet found either.

So then am I right in thinking when LCDs are being sold as "50-pin" they mean that it has an LTDC (LCD TFT Display Controller) interface? Like when they sell them as "3/4-wire" it usually means SPI interface.

langwadt already gave answer to this, but for what I found on displays is that most of those 50 pin LCD's have the same connections but there are differences in voltages and more importantly timing settings. Nominal Animal shared his information on this.

A small story of my experiance, I bought a, what I though to be a 800*480, 7 inch LCD on Aliexpress that turned out to be a 1024*600 display. When connected to my FNIRSI 1013D scope it obviously did not work. Never found the actual datasheet, but after playing with the timing settings I managed to get it to work.

Is F1C100 one of the all-winner chips? I want to be able to make my own SBC one day too.  :-+

Yes that is an oldie of Allwinner. It is a simple enough MCU, but documentation is poor. It is also used in the FNIRSI 1013D and that is how I got in contact with it. My design for a board using it will be published soon. I had to make a small revision of the board, so the wait is for it to be manufactured.

See my thread here for more information about what I'm doing: https://www.eevblog.com/forum/projects/mcu-midi-and-audio-(carrier)-boards/

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 6054
  • Country: gb
  • Doing electronics since the 1960s...
Re: STM32 MCUs interfacing with LCD screens
« Reply #18 on: February 22, 2026, 09:58:56 am »
Quote
This is why I want to stop using SPI. I was at first using STM32 HAL to use SPI DMA and then I thought HAL is too slow so I made my own drivers and even then it did not improve performance that much. e.g. I was drawing text to the screen which needed to be updated fast, even when only updating the pixels required, you can see what seem like artifacts because you can tell it is clearing old text/shapes with new.

HAL is OK. Bits of it are slow because they like to read back registers to get current config and then they modify it, which is sub optimal a lot of the time, but mostly it is fine.

It sounds like you are running some graphics library and slow SPI (or large fonts). Unfortunately there is no free lunch with text; if you want to draw 48pt text you simply need a fast interface. Other graphics can be optimised to various degrees - see the other threads.

Also most LCD controllers have a mode where you define a rectangle and then all writes go into that (with automatic wrapping) and this is handy for doing fills, with DMA. But it can also be used for drawing text, if you set up the character(s) in the CPU RAM, and again use DMA to move the stuff. I suspect very few graphics libraries do use this mode for text however, due to how many bytes need to be sent to the controller to set it all up, and how much RAM is needed in the CPU to hold the text.
« Last Edit: February 22, 2026, 10:41:48 am by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 
The following users thanked this post: shakedown

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 8349
  • Country: fi
    • My home page and email address
Re: STM32 MCUs interfacing with LCD screens
« Reply #19 on: February 22, 2026, 11:11:53 am »
I ordered this one, just for the fun of it: https://www.aliexpress.com/item/1005008811499591.html No datasheet found so far.
Look at the backside image: SH101JGI40, and manufacturing date 20250214.  I can find some documentation, but not a full datasheet for it.  Elsewhere, the documentation I can find says it is compatible with SH101JGI50 (apparently, the latter being the updated/currently sold unit; perhaps with an IPS panel whereas '40 is with a TN panel?), for which I can find a datasheet.  After a cursory examination, the information seems to be correct, at least close enough for me to risk one ~ 25€ display unit.

The similar 9 inch mentioned by Nominal Animal does give some information, but not a real datasheet found either.
I do have the datasheet for SH090JGI50 as well.

Both SH101JGI50 and SH090JGI50 datasheets are in mixed Chinese/English, so one has to be very careful and double-check each detail from as many different sources as possible.  I will not directly link to the datasheets, just in case they'll vanish; and although I can forward a copy to anyone who asks, I don't want to piss off 新活力科技有限公司 just in case I want to ask them for a datasheet myself later on.  Some display-specialized AliExpress sellers may provide the datasheet, too, but as a hobbyist buying one-offs, I want to keep a low'ish profile.
 
The following users thanked this post: pcprogrammer

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 6111
  • Country: nl
Re: STM32 MCUs interfacing with LCD screens
« Reply #20 on: February 22, 2026, 11:56:24 am »
Look at the backside image: SH101JGI40, and manufacturing date 20250214.  I can find some documentation, but not a full datasheet for it.  Elsewhere, the documentation I can find says it is compatible with SH101JGI50 (apparently, the latter being the updated/currently sold unit; perhaps with an IPS panel whereas '40 is with a TN panel?), for which I can find a datasheet.  After a cursory examination, the information seems to be correct, at least close enough for me to risk one ~ 25€ display unit.

Don't know if Aliexpress also has the spring sale at your patch in the world, but I added some other bits and bobs I needed to make use of the 4 euro of on 29 euro in your basket. This way the display only costed me 19,87 euro.  :)

I did notice in the datasheet you found that it is for a 60 pin version that uses LVDS instead of RGB. The image with the cable on Aliexpress shows 50 pins though with the correct nc 3 used pins nc nc near the end of it so I have high hopes it will be a usable one with my boards.

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 8349
  • Country: fi
    • My home page and email address
Re: STM32 MCUs interfacing with LCD screens
« Reply #21 on: February 22, 2026, 12:27:55 pm »
I did notice in the datasheet you found that it is for a 60 pin version that uses LVDS instead of RGB. The image with the cable on Aliexpress shows 50 pins though with the correct nc 3 used pins nc nc near the end of it so I have high hopes it will be a usable one with my boards.
Indeed, good catch!  It looks like the model name isn't sufficient for this manufacturer, as SH101JGI50-01060L is 60-pin LVDS (with very strange gamma correction pins, yuk), and the one you bought is something like SH101JGI40-???50?.  An excellent example of why one has to be very, very careful and vigilant with these!

(I suspect, but of course don't have any proof, that you can use the SH090JGI50 pinout, but SH101JGI50-01060L timings, based on the belief that the manufacturer uses the same display controller for both display types.  That controller supports both RGB and LVDS interfaces, but the pin is not exposed, and is instead fixed by the manufacturer, for example depending on which FFC is soldered to the display board.)

Examining the actual flat flex cable on the display (if it has one; some have a connector only) can give important hints; in particular, LVDS (and MIPI DSI) are distinctly pairwise signals, but parallel (8080/68k -style bus) has 8/16 similar signals, and RGB 15/16/18/24 ones.

I do have one N070ICN-GB1 MIPI DSI 800×1280 display, which has a very nicely glass-bonded front, and you can right now (2026-02-22) find one at AliExpress for ~16€ shipped to EU.  I just need to do a 22-pin to 31-pin adapter with TPS92360 boost driver for the backlight for it for LuckFox Lyra (which, by the way, would also work for RPi's with 22-pin DSI output, or RPi 5 using a 15-pin-to-22-pin FFC).  I haven't checked the image quality yet, but physically, the front side is nice, like a slab of glass.
 
The following users thanked this post: pcprogrammer

Offline shakedownTopic starter

  • Contributor
  • Posts: 25
  • Country: gb
Re: STM32 MCUs interfacing with LCD screens
« Reply #22 on: February 22, 2026, 11:37:09 pm »
A question: why are some of these screens called 16-bit, 24-bit? Is it because each of the D-pins (D0, D1, D2, D3, D4 etc) are setting an individual bit in a register within the screen?
 

Offline shakedownTopic starter

  • Contributor
  • Posts: 25
  • Country: gb
Re: STM32 MCUs interfacing with LCD screens
« Reply #23 on: February 23, 2026, 12:20:47 am »
(And yes, the datasheet hunt is the most annoying part about this, especially when looking at AliExpress/eBay offerings.)

That is an understatement.  :-DD

It is almost impossible to find the datasheet for any of those displays offered on Aliexpress, and the sellers are no help either, as they don't have them either.

I ordered this one, just for the fun of it: https://www.aliexpress.com/item/1005008811499591.html No datasheet found so far. The similar 9 inch mentioned by Nominal Animal does give some information, but not a real datasheet found either.

So then am I right in thinking when LCDs are being sold as "50-pin" they mean that it has an LTDC (LCD TFT Display Controller) interface? Like when they sell them as "3/4-wire" it usually means SPI interface.

langwadt already gave answer to this, but for what I found on displays is that most of those 50 pin LCD's have the same connections but there are differences in voltages and more importantly timing settings. Nominal Animal shared his information on this.

A small story of my experiance, I bought a, what I though to be a 800*480, 7 inch LCD on Aliexpress that turned out to be a 1024*600 display. When connected to my FNIRSI 1013D scope it obviously did not work. Never found the actual datasheet, but after playing with the timing settings I managed to get it to work.

Is F1C100 one of the all-winner chips? I want to be able to make my own SBC one day too.  :-+

Yes that is an oldie of Allwinner. It is a simple enough MCU, but documentation is poor. It is also used in the FNIRSI 1013D and that is how I got in contact with it. My design for a board using it will be published soon. I had to make a small revision of the board, so the wait is for it to be manufactured.

See my thread here for more information about what I'm doing: https://www.eevblog.com/forum/projects/mcu-midi-and-audio-(carrier)-boards/

So how will you go about figuring out what the pins/connections are on that screen? As a noob all I can see is a ribbon with no idea where to start. Nominal Animal also mentioned the connections can differ a lot.
 

Offline pcprogrammer

  • Super Contributor
  • ***
  • Posts: 6111
  • Country: nl
Re: STM32 MCUs interfacing with LCD screens
« Reply #24 on: February 23, 2026, 07:32:47 am »
A question: why are some of these screens called 16-bit, 24-bit? Is it because each of the D-pins (D0, D1, D2, D3, D4 etc) are setting an individual bit in a register within the screen?

Not sure, but I think that the 16 bit ones refer to just a databus that is used to write the data to registers or display memory. I have not used any of those.

The 24 bit ones, referred to as RGB use R0-R7, G0-G7 and B0-B7 as the data pin designators. These displays rely on a steady stream of pixel information send by the display driver. These are the ones I commonly use. These require the host to have the display memory to store the pixels, which adds up with more pixels and 24 bits. That is why I choose to use a reduced number of colors based on RGB565. This reduces the number of bits per pixel to 16. Saves on MCU pins and memory.

So how will you go about figuring out what the pins/connections are on that screen? As a noob all I can see is a ribbon with no idea where to start. Nominal Animal also mentioned the connections can differ a lot.

That is a tricky one and takes a bit of luck. Nominal Animal seems to have better contacts than I do and finds more datasheets, which he shares to help others. So the answer is to ask on forums if someone has more information on a particular display.

For the 50 pin ones, I have not seen that much differences in the pin out, but they do exist.


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf

 

-->