 Hello and welcome to this presentation on the display architectures and interfaces. After a quick review of the existing display architectures, we will focus on the various display interfaces available, and then on the display's interfaces within STM32. First display architectures. Displays are first characterized by their technology. It can be TN-based, TN is for twisted nematic, in this case for each pixel some liquid crystal will twist the light or not. For TFT LCD displays, the same principle is applied but adding a mandatory backlight source and some color filters for subpixels, red, green and blue. Another technology, AMOLED, does not need backlight, each pixel emits some light. CRT screens, based on an electro beam, is not even mentioned here since it's not relevant for embedded devices. As of today, TFT LCD is currently the most common technology in microcontrollers. Other characteristics of displays is the total number of pixels that can be displayed, which is called a definition. For example, VGA displays with a definition of 640 by 480. The number of colors that can be displayed called the color depths. For example, a 24-bit per pixel color depths can render 16 million colors. And the number of times per second an image must be sent for a proper display, which is called a refresh rate. A classical display shall be refreshed 60 times per second. The last characteristic is the interface that the display supports. The interface will determine both the actual connection, in terms of number of pins, and the protocol, the data format. Before focusing on the interfaces, let's see the basic TFT LCD components required to drive the display regardless of the interface to the MCU. First, a memory, or G-RAM, for graphical RAM, is needed to store the image to be displayed, which is also called the frame buffer. A display controller is then needed to fetch the data from the G-RAM. This controller then sends the data and the timing information to the timing controller that will convert them into synchronization pulses to refresh each pixel of the panel. The gate driver then addresses each line of the panel while the source driver addresses each pixel of each line. Each pixel is thus given a specific amount of red, green, and blue to create the final pixel color, depending on the display color depth. Between the display controller and the timing controller, some specific signals are required. First, the pixel clock, or P-clock, is the next channel signal indicating the display at which rate the pixel are sent to the screen. On each pixel colloquial tick, one pixel data is sent. Note that all these values are expressed in a number of pixel clock cycles, so there are timing information. The V-sync, or vertical sync, is the signal that indicates the start of a new frame. The H-sync, or horizontal sync, indicates the start of a new line. The horizontal front porch is the interval period between the end of a picture information and the start of a horizontal pulse, or H-sync. The horizontal back porch is the duration between the end of horizontal pulse and the start of a new next line of the visible area. The vertical back porch is the delay between the V-sync end and the start of a new frame and the vertical front porch is the delay between the end of a visible area frame and the next V-sync start. All these signals are inherited from the analog display domain. For example, the back porch is the duration of positioning the electron beam to the beginning of the panel and turn it on again. During the gray area, no pixel data is actually updated on the panel. It is called the blanking period. It is during this period that the geram can be updated since it is not sent to the panel. This slide is an illustration of the timing signals in a temporal way. At the top of the slides, at the frame level, based on vertical synchronization, there is one V-sync signal per image of frame. The bottom part shows the line level. There are as many H-sync signals as lines in the frame. This timing information is specific to each display model. They are always provided in the display data sheet as we will see in the next slide. This is typically the kind of table that can be found in every display data sheet. However, the unit may differ. For example, here, all the units are pixel clocks, but it could be nanoseconds. But each signal is present. Green values correspond to visible area, while pink ones include also the delays, vertical and horizontal front and back porches. Thus, if the pixel clock required to fill the visible area is 7.8 MHz, the actual required pixel clock to correctly display the frame at 60Hz is 9.1 MHz, as you can see in the computation. For a 24-bit per pixel color depth, the display bandwidth is then 27.3 Mbps. Usually, the G-RAM contains only the content of a single frame. As we mentioned, it is sent directly to the display 60 times per second, but must also be updated regularly depending on the content that has to be displayed. When the G-RAM contains only one frame, some tearing may appear on the display when reading and writing from and to this G-RAM. Screen tearing is a virtual artifact and video display where a display device shows information from two or more frames in a single screen draw. The artifact occurs when the video feed to the device isn't in sync with the display's refresh. In other words, if reading and writing from and to this G-RAM is not carefully handled, some tearing effect may appear. Let's see an illustration of this tearing effect. Let's consider this green L0 logo. The blue line corresponds to the reading pointer of the display controller that sends the pixel it reads to the display panel. It sends it consciously at 60Hz. The pink line corresponds to the writing pointer of the graphical application that fills the graphical buffer for future display. So the blue logo is the next frame to be displayed while the green one is currently displayed. The display controller is constantly reading the G-RAM at 16Hz. The graphical application on its side is not updating the G-RAM at this frequency but a much slower one depending on the available memory bandwidth but also depending on the application lifecycle. At this point, you can see that the writing pointer is beyond the reading pointer, which means that the display controller will read the next frame or at least or at least part of it. This will result in a wrong panel update in which we will have part of the green logo and part of the blue one. To avoid this kind of effect, using still a single buffer, the graphical application update of the G-RAM must be contained in the blanking period. Otherwise, if it's longer than the blanking period, a second buffer must be used to update the next frame. Let's now see the available display interfaces. There is basically two families of display. The display is with no display controller, only a low-level timing controller or T-con, source and gate drivers. And display with display controller, including a RAM, so a G-RAM, storing the frame buffer to be displayed. This implies several kinds of interfacing and different bandwidth requirements for the same definition and color depths. First, we can have the MCU power line interface for display with controller and frame buffer. This interface works in common mode. It means that the MCU sends data or control signal to the display controller. We have also a SPI or serial interface for display with display controller and frame buffer. Also working in common mode, the only difference between the two is the power line or serial interface, which means more or less pins to connect the display. And finally, we have the RGB interface for display without display controller and frame buffer. And in this case, the MCU sends the RGB data and the timing, such as visiting clock, to the display. So this RGB interface requires a specific IP to handle the display controller. Because if the MCU was in charge of it, it will be too much CPU consuming to render the display. Remember that the images must be sent 60 times per second. This is a diagram illustrating a display with a controller and G-RAM. As you can see, we have several interfaces that we already mentioned. The Moto 6800 and the Intel 8080 are the power line interface mentioned before. The Motorola and Intel protocol are power line interfaces, while the SPI is a serial one. So in this case, only data or control signals are sent and the display controller on the display module side is in charge of refreshing the screen with the current frame buffer it has. The MCU only updates the frame buffer when needed depending on the application lifecycle. So Motorola and Intel protocol are generally handled using the FSMC, while the SPI is of course handled by the dedicated protocol. A partial update of the G-RAM is also supported, which allows some optimization of the bandwidth on the display interface. The drawback is that commands should be synchronized properly to avoid the T-ring effect. For that, the TE pin for T-ring effect pin is configured to generate a signal on a specific line number. The number of the line is chosen to take into account the latency introduced by the sending of the command. For a display without controller nor graphical RAM, the mode is called Continuous RGB with H-Sync, V-Sync, D-E-M-P clock. The display controller generating all the signals H-Sync, V-Sync and the frame buffer is on the MCU side. In this case, the number of pins required for raw data are 12 pins for RGB 444 color depths and 24 pins in RGB 888. But also requires some specific pins like the D-E, it's the data enable and the P-Clock, which contains the pixel clock. So it means that we have between 15 and 28 pins used. In terms of comparison, displays with controller have a higher cost and frequency generally limited to 20 MHz. They are used for small definition displays, interfaced with P or FSMC and they need applicative layer for common generation. The display without controller have a lower cost and can reach very high definition. But the pin count is very high, 20, 22 or 28 pins or more and it doesn't need extra applicative layer. The MIP DSI interface overcomes these limitations as we will see. The MIP Alliance is for mobile industry processor interface. It's an organization specifying the interconnections between ICs within phones. It was founded in 2003 by Arm, Intel, Nokia, Samsung and ST Microelectronics and TI. The display working group of this organization is specifying the interconnection between an IC and a display. It has standardized already all existing display interfaces we see before and also added a new display interface which is called the display serial interface or DSI. The display bus interface or DBI works in command mode. It's using display command set. So it concerns Motorola, Intel and Spy interfaces that we mentioned before and name them type A, B and C. The display pixel interface, DPI the parallel RGB interface and works in video mode. And finally the display serial interface can encapsulate both modes either command mode over DSI or video mode over DSI. But the main advantage of the DSI interface is on the number of pins it requires since it's a serialized interface it only requires from 4 to 6 pins but is still able to handle both parallel and serial mode. In this configuration the display commands are sent by the MCU and received by the display controller using the DSI. It conciliates bandwidth optimization with low pins number. For display without controller it's the same configuration as the display without controller we saw before except that all the signals are multiplexed by the DSI host and sent on a serial link. They are then demultiplexed on the display side by the DSI device. The number of pins is between 4 and 6 depending on the number of lanes used. It's a big advantage compared to parallel interface. The DSI decreases the number of wires between the MCU and the display. It supports high bandwidths multi-lane differential link. It is scalable from 125 Mbps to 1 GBps per lane and it's scalable up to 4 data lanes. It also supports low power modes. The MCU can be in stop mode while the display is on. The DSI uses the Mipi DeFi for the physical link. As we saw the DSI encapsulates either DBI commands or DPI signals and transmits them to the display. This allows to get interfaced with a standard display below its VGA with 4 pins only with the same performance as in DPI mode. Another advantage of the DSI interface is that it allows over 15 cm long cable between the MCU and the display. Most of the STM32 MCUs already includes some FSMC device as well as SPI. So the DBI interface is already handled by most of the STM32 MCUs. Let's see now how the RGB interface is handled in the STM32 families. For display without internal controller a specific IP called the LTDC is provided in some of the STM32 MCUs. The HB master interface to communicate with the memory peripherals as well as an APB interface to generate the timing informations. LTDC stands for LCD TFT display controller and is generating all the signals for the LCD panel. The display clock, the h-sync, the v-sync, the data-enable signal and RGB raw data. It has programmable timings for all the TFT LCD displays up to XGR. The HB master interface with burst of 16 words acts like a DMA. Thanks to LTDC the CPU is not interrupted periodically to generate the DPI signals. The LTDC main features include the 24-bits RGB parallel pixel inputs which is a 8-bit per pixel color depth, two display layers with dedicated FIFO, a color lookup table up to 256 color per layer. It supports up to XGA definition which is 1024 by 768. It has programmable timings for different display panels, programmable background color, programmable polarity for h-sync, v-sync and data-enable and it supports up to 8 input color formats selectable per layer which are RGB8888, RGB888, RGB565, etc. Please refer to the user manual for the detailed information. So the LTDC IP is armed to deal with the DPI interface without loading the MCU which is still available for the application. So regarding STM32 display interfaces, all the STM32 with SPI peripherals are supporting the DPI type C interface. The STM32 with FSMC are also supporting the DPI type A and B interfaces. The STM32 with LTDC are supporting the DPI and latest generation of STM32 are supporting the DSI. And finally, all the STM32 are supporting the DCS interface in pure software, then loading a lot the MCU. Here is a quick view on the existing MCUs and the display interface is their support. As you can see, the most recent H7 is supporting all the mode because it contains an LTDC but also supports the DLC mode. And of course it contains FSMC and SPI peripherals. Note that in the marketing presentation, TFT control means DPI and display parallel interface means DPI type A or B. In the lab associated to this presentation, we will use F469 which supports all the display interface modes. Here is an overview of the STM32 flexibility. The first use case is the display module with an integrated display controller and graphical memory. Here the MCU communicates with the display through DPI or DSI interface. So with one chip, STM32 plus a display module. In this second case, another frame buffer is also accessible through the FSMC to avoid, for example, the Turing effect that we mentioned before. In this third example, the STM32 is directly communicating to the display through the LTDC interface. So the display contains no internal controller and no memory. And in this use case, we have only one frame buffer. And finally, this is the most frequent use case since the display without display controller are cheaper. In this case, we use an external frame buffer for one and or two frame buffers through the FSMC and communicate through the display, through the DPI or DSI interface using the LTDC. So as a conclusion, there are two kind of displays. We always are an integrated controller. A lot of interfaces are existing, DPI, DPI, DSI, and all the display interfaces are standardized by the MEP organization. DSI is the most advanced standard and can encapsulate all the old standards. The STM32 family supports all the display interfaces. Thank you for your attention and then you invite you to follow the next course.