 In this chapter we will look on to how to make an embedded graphics application on STM32F7 processor. We will show you very briefly why STM32F7 is a great platform for embedded graphics. And because we think in the graphics it's better to see a real application than just talking about the theory, we have prepared few demo applications to show you all the capabilities on the STM32F7 Discovery Kit. So why is STM32F7 a great platform for embedded graphics? The answer is in the block diagram of the smart architecture of the processor. Well, here you can see the LCD controller DMA, which is effectively capable to drive any LCD TFT display. Well, usually the bigger LCDs don't have embedded memory and you need to provide the frame buffer memory in your application. Usually the frame buffer is too big to fit into the internal memory so you need some extra memory to store the frame buffer. For this there is a good compromise between the price and performance in the SDRA memories and these SDRA memories are supported by our FMC controller. If you have the frame buffer, ok, you can show something on the LCD, but what to show? You need to have some graphical elements which needs to be moved into the frame buffer to show some of the GUI which you want to create. Again, all the graphical elements are usually very huge in terms of size so you need some non-volatile extra memory to be connected. Of course, you could use some NOR flash memory or NAND flash connected to FMC, but we can see on the next slide why it's quite useful to have another memory on another bus to relieve the bandwidth of the FMC. What you can see here is that if you do these memory movements which are only useful for the graphics, the rest of the systems stays unimpacted by the graphic application and the CPU can do any other operation and the performance is not impacted at all. If we just extract the elements which are used for driving the graphics, here we have the LTDC controller and the DMA2D. The LTDC controller is responsible for updating the LCD display at the nominal refresh rate which is usually 60 Hz and it takes the data which are stored in the frame buffer and uses this data to update the display at this refresh speed. Well, just by very simple mathematics, you can see that the bandwidth which is coming from the SD RAM to the LCD can be quite high. Simply, you need to multiply the refresh rate with the dimensions of the display and the color depth for each pixel and you get the needed data bandwidth just to update the display. And this is only for the statistical image. If you want to change something in the frame buffer, which means you need to change the GUI or even to make an animation, you need to at the same time update the data in the frame buffer. For this, you can use very effectively a dedicated DMA which is called DMA2D or also Chromart. This DMA2D can take data anywhere in the memory and put it also anywhere in the memory, but it can take the data in the format of bitmaps. And why it is beneficial to have another bus for fetching these data? Well, of course, you could have a parallel memory connected also on the FMC, but then if you update the frame buffer, you need to consider that there are three data paths coming directly on the FMC at the same time. Reading the Norflash, storing the new data or the new frame buffer into the SD RAM and still keep in mind that you need to refresh the LCD all the time, so there is fetching the frame buffer from the SD RAM continuously. If you consider that each of these streams needs to have several tens megabytes per second, you can very quickly come to the limit of the SD RAM. We can see that having the non-volatile image data in another memory, like Quad SPI which is connected through another bus, makes a bit relief on the FMC bus and it enables us to use higher display resolutions and higher color bandwidth. Well, so what the DMA2D is exactly good for? You can imagine you have a background in the frame buffer and you want to update this background or you want to show some graphical element above the background. How to do that? What you effectively need to do is to blend two pictures together and store it back to the frame buffer. In our case, there is the background with the girl running in the mountains and as the icon, let's take the ST logo. The DMA2D is completely capable to do this task just by hardware, fetching the both foreground and background streams at the same time, then optionally you can do the pixel format conversion independently on these two streams and then it can blend it together with various settings and the blended picture again converted by color and stored to any location. As you can see the background and the output locations can be the same, which makes the frame buffer updated, but of course you can program it that you can store it somewhere else in the memory map for further use. Well, you may ask why we have the pixel format conversion in each of the stage. The reason is very simple. Usually the output of the frame buffer is stored in the same format as the display is connected to use the whole capabilities of the display, but many of the graphical elements are pretty easy and they don't need to be used or they don't need to be stored in the full resolution of the colors. That would be just wasting of your valuable memory space. So some of the graphical elements like logos, texts and so on can be stored in less color depth, so saving the memory space, but still having the possibility to decompress it or to convert it on the fly each time you show it on the frame buffer, just by programming correctly the DMA2D pixel format correction block. Which formats are supported? So we support from the full true color format including or excluding the alpha channel. So taking either 24 or 32 bit per pixel down to 16 bit or even 8 bit pixel formats. The first 5 formats are called as a direct format because they directly represent the color and it just differs how many bits you reserve for each color. The last 3 formats are called non direct or indexed colors and the data stored for each pixel are not representing the color itself but are representing just the index in the color lookup table. As an example in the L8 format each pixel is represented as 8 bits and these 8 bits are just pointers in the lookup table. So for this format you need also to provide a color lookup table where you have the possibility to store 256 possible colors and then the image will be composed only of these 256 colors. This will save a lot of memory space for basic pictures where only few colors are needed but yet not compromising the quality. Because every time you show the image the conversion is done by hardware. Well this is the hardware but what about the firmware around? Composing and creating a graphical user interface is quite huge task and there is many companies which are providing graphical stacks for you. Here is the list of all available companies at the moment which are providing stack compatible with STM32 solutions. As ST we are providing for free a solution which is called STMWIN and it's completely free to be used on our STM32 microcontrollers and you can download it together with our HAL libraries. Well but in the market there is many other companies which are developing STM32 enabled solutions. The STMWIN package is provided as the object files only but you have the full documentation of the APIs of these objects and the ST is providing the support for this package. So here you can see that the list of the partners is really extensive. Okay so you have seen some basics about what the STM32 is offering in terms of hardware but better than talking about it I think it's better to see it. So we have prepared a demo with one of our partner which is called TouchEffects and these demos are available in the hex file format. So all you need to see them is to flash the hex file into your words. There are effectively free demos and they differ in size but also in the set of features which are shown. All the demos are inside one project which is in the 10 underscore graphic demos folder of the hands-on folder. We can use also IR which is quite convenient as well. So when you open this project you will see instead of all the source files just the hex file you can choose between these three demos just by clicking on the loader button. If you then if you select the demo which you want to download you just go to the menu download and select download active application. The downloading can take up to several minutes because the demo has a lot of nonvolatile information stored in the quad SPI memory, effectively a few megabytes and it may take some time to program this quad SPI memory. So please be patient. When the flashing is finished you just need to press the reset button on the discovery board to make the demo running. So now I leave you some time to explore the graphical capabilities of STM32.