 Hello everybody. My name is Emil Petersen. I'm a part of the STM32 graphics team who are responsible for touch-the-effects. Today's presentation is going to be an introduction to board bring up, meaning the process of getting your display board ready to run touch-the-effects. Today's agenda is going to start out with a quick introduction before we move into the hardware selection part, where we're going to give you some pointers and some information about how to select the correct hardware fitting the UI solution that you have created or going to create. Afterwards, we're going to move into the board bring up, where we're going to go through a how-to guide that we have created that can help you through the board bring up process itself. The goal of this presentation is first to provide some information that can help developers selecting the right hardware for their graphics application, including that is giving some preliminary considerations that you have to take into account when doing the UI itself, because the UI that you are designing is going to have an impact on the hardware that you need for your display solution. Also, we're going to give you some information about the hardware components that is needed when doing an embedded GUI solution. Another goal of this presentation is to present a guide that developers can use in the bring up phase and thereby have a tool that can help them in ease the process of getting their display solution up and running and ready for touch-the-effects. We will not get touch-the-effects up and running in this presentation, this you can see the abstract layer development presentations for. If you want to learn more about touch-the-effects, you can go to our documentation site support.touch-the-effects.com, where you can find a lot of information about both embedded graphics and mainly about touch-the-effects itself. Slides in this presentation will also refer to the relevant documentation page on our website, because all slides would have a link in the lower right corner where you can access the documentation page directly related to what I'm talking about in the slides. This presentation will in general be related to the two sections of our documentation hardware selection and board bring up. In relation to the touch-the-effects development process, we are going to start with the main activity hardware selection, deciding what components our main component display board is going to consist of, before moving on to the activity board bring up, where we're going to create the main component board initialization code. Let's dig into the hardware selection part of this presentation. As talked about earlier, there are some preliminary considerations we have to take into account when designing our application, our UI, because the way that that is designed is going to have a direct impact on the hardware that we need. As we know from the presentation embedded graphic basic concepts of that part of the documentation, our display resolution and our color diffs is what determines the size of our frame buffer and thereby the amount of memory that we need, which is going to put some constraints on the hardware that we have to choose. As we see here, we have three examples of applications, or four examples of applications actually, two running and two pictures where the two running applications are in 16 BPP and the two pictures here of the aircon and the watch are only in 8 BPP. Therefore it can be a very good idea to consider if having something like 24 BPP is needed for your application because you can save memory on selecting smaller amount of bits per pixels and in many cases 16 BPPs can actually achieve almost as good as quality in your graphic as 24 with the delivering algorithm that we also talked about previously in the embedded graphic basic concepts presentation. Also, going down to 8 BPP is definitely an opportunity. It has to fit with the application you're trying to do and it of course puts some restraint on the people doing the graphics, but if this is done right you can still achieve some quite beautiful applications. Same as the BPP, the resolution is also something you need to take into account of how high resolution you actually need for the application you're trying to do. Another element or element that can be quite important to look into when you're doing your UI because this will also have an impact on how much performance that is required for your UI solution is the animations and the complexity of your UI. So if you have a lot of full screen animations as you see on the demo in top this will require a lot of performance for your UI. Also having multiple animations scaling and so forth will add to the amount of performance that you need where compared to the video running in the left corner of our four applications here doesn't do that much at the same time as you could say so it doesn't have as many animations as large animations and as much complexity and therefore will not require as high performance from the hardware. So these are the factors that you need to also look into before designing the UI what will actually fit the solution that you're trying to make. Another element is the touch. So there are different type of touch screens and depending on if you're selecting capacitive or resistive touch screen you maybe need to design a UI after that because there is different way that they respond to the touch. Even in some cases you maybe would like to not have touch at all on your system and use buttons. Instead for example our G0 offer we offer with no touch but then buttons to navigate around in your application. Another aspect that you need to take into account is the mechanical design requirements. One of them is size so maybe you already know which how the setup that you're going to have your touch solution in is going to be and which could put some size constraints on the solution that you're doing but also the environment can be quite important thing to factor in. If you're using it in a standard consumer product that's going to be in a home like a coffee machine or something like that which is not going to be affected or not going to be put in a context where there is a lot of rough environment, water, dust, high temperature or something like that. You may be a bit more flexible in the hardware choices that you can make compared to something that you could have at a smartwatch or in a more industrial setting which is going to have a bit of a rougher environment and therefore needs to be able to handle the setup for example adding a cover lens or something like that. So what hardware actually to select from when we are designing our graphical solution? We can divide our hardware for our graphic solution into four basic parts so the hardware that is directly related to doing the embedded graphics. One is the MCU which is doing all the heavy lifting, the computation, the transferring of data from flash to RAM and RAM to the display. The RAM is where we store the frame buffer as I just talked about and the flash where we have our images, fonts, some of the code that we're executing, our display where we show what we are creating. The flash and RAM can both be placed as internal memory so within the MCU but also as external memory so separate hardware components that we need in our solution. As mentioned in the preliminary considerations section we need to have a hardware setup that supports the performance that we have created for our UI or supports the performance that our UI demands as you could say. A very important element in achieving the proper performance is the frequency of our MCU. This means that our MCU is fast enough to handle the tasks that we give to it. When talking about frequency it is not only the core frequency itself for example we can see up here that our GCO chip has that 64 megahertz and our F7 is 216 megahertz that is of course an important factor but not the only one because there is also something that we call the graphic subsystem frequency which is the frequency of our internal buses, frequency of the graphics accelerator, internal and external memories all these components play a vital part in the performance that we can get and if any of them are not fast enough it can become a bottleneck for our performance. The embedded hardware accelerator is also a place where we can achieve a better performance. One of the frequent embedded hardware accelerator that is present on the STM32 microcontrollers for graphic solution is the Chromart. As we can see it's also one we have on our F7 line and the Chromart or DMA2D accelerator is designed to help the MCU by offloading some of its tasks meaning that the Chromart will handle some of the graphics tasks that the MCU usually do. For example the Chromart can transfer pixels of images from the flash to the frame buffer and do some of the blending that is some of the tasks that is able to perform Chromart instead of the MCU so the MCU can focus on other tasks for example handling texture mappers or so forth. This video of our birded coin game that you see in the bottom right corner down here is a good example of how much performance that you can achieve when using the Chromart instead of using just the MCU. In this demo we simulate the performance for one of our STM chips and we can see here that there's a button that can enable and disable the Chromart. When we have the Chromart enabled as now we only or we only use 4% of the MCU but as you see as when we disable it the MCU load changes to 82 and it's a very good example of of course when you're having the right application how Chromart really can be helpful. Another hardware accelerator is the JPEG accelerator which is a hardware JPEG decoder that decodes JPEGs for us so the MCU doesn't have to do it in software and this is really helpful especially with videos in your application. The third is ChromGRC. ChromGRC can help us save memory when doing round display in our applications as we've kind of tried to show here because a frame buffer is normally squared fitting with a squared display but when you have a round display the elements in the corner as we shown with the red lines are not visible and by using ChromGRC we are able to have a round frame buffer thereby not using memory on the elements in our display that is not visible enabling us to save some memory for the frame buffer and thereby not requiring the same amount of RAM. Some other stuff that we have in our internal memory that is useful for graphics is the memory. We have both RAM and flash internal memory and even though that you have big applications that require a lot of memory you maybe don't always want a lot of internal memory because in some cases you know that you're going to require so many different images that the internal flash will never be enough and you might as well maybe have a bit of a lower internal flash and then have a large external flash and the same goes for RAM where you might are not able to even have one frame buffer in your RAM and might as well only use external RAM or mainly use external RAM for your frame buffer so in some cases you can have small applications or applications that is suitable for only keeping the internal but especially in graphic you want to use external memory for your flash and also in some cases for your RAM. The LCD controller is also a very important element for our graphic solutions because the LCD controller ensures the communication between the display and the MCU and this one needs to be suitable with the display that you have chosen and further along that way packages and the IO of your MCU is of course also important to have the correct number of IOs and for those to be fitting with your display as well as memory interfacing as similar with the display you need the memory to have a proper interface to the MCU and to the external memory that you're using. I have shown two of our lines here of our SDM32 microcontrollers for the graphic solutions and the G0 and the F7 and they are kind of in the opposite side of the scale where the G0 is our low cost solution and the F7 is almost one of our higher performance solutions of course we also have the H7 now but these two show you a good picture of what different things the MCU can consist of regarding graphics. So we have the hardware accelerator which the F7 has and in a low cost solution is not present as talked about before but also the display interface as we see for the G0 it has the SPI where we have multiple interfaces that we can use in our F7 offers and also important thing to take into account is the supported resolution for these chips is important element so if you need a high resolution as talked before earlier you need a higher performance chip as well for example the F7 or an H7. When selecting a display there are different types of displays to choose from one of the more common types of display is the LCD TFT the film transistor variant of the LCD display which are also one that we use in a lot of our SDM32 discovery kits and evaluation boards for example we can see here a picture of the SDM328725 discovery kit using the LCD TFT display another type of display is the MIP display memory in pixel which has a low power consumption and can for example be very good for wearables the third type which fits in very specific use cases often is the e-paper e-ink display which also has a very low power consumption but is also quite slow and only in monochrome selecting the right display the display interface of course also have a big factor because you want as mentioned under the MCU right before you want a display interface that is compatible with your MCU and compatible with the performance that you need for your hardware solution in general and for the GUI that you have made brightness and backlight is also something that's important to take into account because the environment or the situation that you expect your solution to be used in maybe have an impact on the brightness that is needed for example if the display is often going to be placed in direct sunlight you need to ensure that the brightness and the backlight support this situation this environment and enabling the graphic on the display to be viewed even though there is a lot of glare viewing position and color inversion is also something that is important for example as you can see at the example of our display kit here is that if a viewing angle can have an impact on the color that you see on the display causing what is called color inversion so if you're going to have a not direct viewing angle so like 115 degrees or something it could have an impact and you need to ensure that the display is showing the graphics as you expected to do from the angle that is going to be the most common angle to view your solution your display from as talked about with the solutions regarding the application that you make the pixel density of the display is of course also a factor here so you can have a big physical display with a low resolution and then you will have a low pixel density and we are tied to kind of show what pixel density and having a low and a high pixel density means by these three images here where if you have a low pixel density you have a lot of big pixels and maybe going to give a bit of jacket edges around some of the elements in your graphics while having a high pixel density and thereby having a more smooth edges on your graphics as we can see this circle changes a lot depending on the pixel density that we have memory is also something that you can have in your display because some display come with built-in RAM called graphical RAM g-RAM and it's of course something also that if you need external memory for a solution a second frame buffer as an example you can have that combined with your display lastly as discussed under preliminary considerations the environment is also something we need to take into account when selecting the display as mentioned on that slide we need to ensure that the display is able to perform as expected in the environment that we place it in the third and final thing we're going to discuss here on the hardware selection is external memory as mentioned a couple of times we often need external memory especially for flash since graphics require a lot of memory the first thing that is important when looking at external memory is the interface to the MCU as has been the topic for the other two components we discussed we want to ensure that our interface of course is compatible with the MCU but also supports the speed that we need to ensure that we have a proper performance because the communication between the external memory and the MCU is also where we can have a bottleneck in our graphic solution looking into the non-volatile memories the nor flash is able to be used in something called memory map mode where we can use the external flaps to seen as internal memory for read operation meaning that something like our dma2d the chromat can interact directly with the nor flash the nan flash can be very good when you have a high volume of graphical assets because it has faster write and read operation but the nan flash is not able to be configured in memory map mode and is not recommended for code execution emmc stands for embedded multimedia card provides a standard interface that can help developers save time in the development process because they don't have to focus that much on setting up the interface but emmc is often also slower than nor a nan flash in our volatile memory our RAM it's often important to take in factors such as the density the performance of the RAM the power consumption the interface and how it fits with a framework for strategy we have highlighted the three types of RAM here SD RAM S RAM and PS RAM because these are very good to use in a graphical solution but of course these type of rams have their advantages and disadvantages when they're compared to each other for example S RAM is usually a bit slower than SD RAM but it comes with a lower power consumption a final note to be made in the hardware selection process is that it can be a good idea to base your display board on one of our display kit solutions this is because that we of course spend a lot of time doing our hardware setup our board bring up in these display solutions to make sure that they run properly and we have the best possible performance and therefore can help you a lot in the board bring up process when you have selected and created your display board you are now ready to get started with the board bring up to be able to perform your board bring up there are several tools that you need first off you need the stm32 cube max which is our graphical tool that allows you to very easy configure your stm32 mic controller and will generate initialization code for you then there is the stm32 cube firmware package where all the codes for the drivers everything that you need to set up your mcu we also need the vendor data sheets to have information about how to configure and set up our external components for example the timing for our LCD or our display and finally we need the driver code as well as we need the firmware package to be able to run these external components another very important step as mentioned earlier is the verification of functionality the reason why we need to verify the functionality in this process is that we need to ensure that it's ready to be integrated with our abstraction layer thereby be integrated with touchgfx but also we want to write test code to this to ensure that this works properly and it's not the issue that we have when doing the abstraction layer development because if we are in a case where we don't test it before combining with touchgfx we can be in a situation where we don't know if the issue is in our abstraction layer or the issue is in our initialization which can add a lot more time in bug fixing as mentioned here in the stm32 graphics team we have created a how-to guide for doing the spot pick up process to help and ease the process of getting your driver and components up and running this is done in a 11 step guide where we are highlighting each step we have to go through to get things ready for showing touchgfx the way that we have done this it's under each step we have four important points the motivation which is the why we are doing this step how does it help us getting our board up and running the goal what do we expect to have when we are done with the step the prerequisites what is needed before we can start doing this step and do basically just what we have to do in this step it's important to remember that since a display board solution can consist of lots of different components different type of flash different type of display and so forth this guide is not a universal guide but we use some examples to show you how some of the more common ways of doing these steps is performed the first step here in our board bring up how-to guide is the create project step the reason we are doing this step is we want to create a basis for our whole board bring up procedure meaning that we have a project in stm32 cuba mix and we have some chosen IDE where we can work with the code that we are generated and we need to add to get our board up and running the goal of this step is to have a working cuba mix project and be able to debug some code on the MCU so the prerequisites that we need to have to be able to perform this step is of course an stm32 based board so a display solution able to program and debug this board either by having an IDE where we can do everything in or having some tool to program and maybe set up a terminal where we can send information from our MCU to our computer to able to see what's going on and thereby verify that the things that we have set up on our MCU works the way as it is expected of course we also need the stm32 cuba mix to create the product to begin with and an IDE installed to do our programming and coding for this project through the landing page here where we are starting our project we will open the MCU selector as we see here and select the chip that we are using in our display board when we have selected the MCU we will go and create a project which will get us to this screen the project manager where we are able to name our project select a toolchain that we want to use it's important to select the advanced project structure or the advanced application structure in this drop down menu to ensure that it's compatible with our touch effects integration that we'll be doing later on after everything has been selected you can go and select the generate code up here and there the code for our project with this microcontroller will be generated when this is done we can select an open project pop-up and it will bring us to the IDE we have chosen so as we can see on the toolchain IDE here we have selected IR and then our IR project will open now what we want to do is to put in a stop in our debug session so like here in our code and we will simply just flash our board with the program run it to see that we're able to debug and see that our project here can run on our target the next step here our step two is the cpu running step we are doing this to ensure that the MCU core and the internal ram or flash is running at a clock speed that we are able to set therefore the goal is to set up a clock and ensure that the correct speed is running on our MCU the prerequisites here is to ensure that we have enough information about the clock on our hardware to set it at a desired speed so what we're going to do is that we're going to go to the menu as we see here in cuba mix so the picture shows the tab clock configuration that we have selected for a project here in clock configuration we are able to set up the clock that we are using for a project so as right now and what the picture shows is the h is i clock the internal clock and we are able to set the prescalers multipliers dividers for this clock after we have set the clock we want to ensure that the speed is correct or the speed fits what we have set it to by debugging on our hardware we will also ensure that we're able to read and write from our internal flash and internal ram at a proper speed it's important to note here that if you're using an f7 on h7 you need to ensure that the data cache is disabled so we are sure that we are reading from the memory and not from the cache so after the clock setting is set up you can go to your code to your IDE and set a hell delay which for this case is five seconds and if the clock is running correctly cuba mix will have ensured that the delay will actually be five seconds that the clock settings is combined with the hell option of a delay is five seconds we will now by debugging through the code be able to see if it actually is five seconds the delay and thereby the clock is running as expected which is done by first adding a debug breakpoint next to the delay and then next to the while loop that we will enter after the delay so what we just do here is run our code and when we hit the delay we will start a timer when we start the code again and when we get to the while we will stop the timer and five seconds should have passed after ensuring that the internal clock speed is as expected we can now move on to check the speed of our internal memory and of course also if we are able to read from the internal memory this is done by creating a small program as the one we see here where we are able to access places in the memory for example we are looking into the flash here the information about where your random flash is placed can often be found in the linker script in your project so here we started at that place in our flash and end and using held tick we can check how fast we are reading starting from code going to stop after doing it for the flash we can change the address here and do it for our RAM the third step is the frame of an internal RAM step where we want to set up an internal frame buffer on our mic controller connect the display and enable the display to show the content of our internal frame buffer the goal of this step is to have RAM allocated for a frame buffer and to show the content of the frame buffer on the display the prerequisites here is to have some information about the display usually via a data sheet that can tell us how to connect the display and set up the timing for running the display also we need some information about the connection between the display and the MCU the first thing we do in this step is to set up the frame buffer and internal RAM which is simply done by defining an array at the size of the frame buffer that we need in our code similar to what we have done up here then we want to configure the gbo connections to the display for this display that we're using here we have an lttc controller selected on the multimedia here where we are able to set the dpi os in the dpi os setting after our connection to a display is configured we will then set the settings for our lttc display this means first to set up the layer settings on the layer settings and we see here followed by setting the parameters on the tab here where we can set elements as our v-sync and so forth another thing we want to do when we are configuring our lttc controller is to set the background color here in cuba max this is done in the bottom here of our layer settings on the background color so of course we are normally going to define via the touch fx framework what we are putting into a frame buffer but for test purposes the color that we set here is going to be put into the frame buffer and is what we're going to see on the display after setting up our lttc controller we will move to the clock settings tab and configure our pixel clock where we highlighted the relevant settings here with yellow after we have configured our pixel clock for the lttc we will then set the address of the lttc as we can see in the top here or the code we have in the top here on the slide where I set the address for the lttc to the frame buffer that we have created earlier to check the framework you can create a piece of code similar to the one shown on the bottom here where we run through different colors that we then put into a frame buffer the code that we have here is for the color format rgv565 so of course if you use another color format like rgv888 to run 24 pvp you need some other code to do this another reason it can be a good idea to run through different colors in your frame buffer and on your display is to check if the color is represented as you expect and thereby ensuring that your display also is working as you want it to after being able to set up a frame buffer into the RAM and being able to show what's in the frame buffer we now know that our display is able to show some information that we have defined in the frame buffer and we're now moving on to getting external RAM running as mentioned a couple of times for this presentation the reason we want to have external RAM is that our frame buffer or multiple frame buffers does not fit in the internal RAM on our mic controller and we therefore need some extra memory the goal of this step is to be able to read and write from external RAM thereby having it up and running as expected the prerequisites here is similar to the one for this place we need to ensure we have enough information from the RAM that we're using so often the data sheet to set this up and we need to know how to connect this RAM to our MCU so to get the external RAM up and running with our board we're going to kubemix as we see here where we in this example using SD RAM that is configurable via FMC and therefore we can set up what we need to here for external RAM we also have to remember to configure the GPIOs of our RAM as well as we did with the display in some cases we need to add some code to fully configure our RAM and therefore we will do that under user code for our RAM here in our project as we can see here now we can go and test our RAM simply by debugging through our code and when we have set up the RAM we can look at the memory section that we have defined that the RAM will be in and if we're able to see some memory in there we can read from it writing it to it we can do by a small test program as we can see down here where we again use the address of our RAM preferably write some test code where we write in the entire RAM and thereby ensure that our configuration and the setup is performed so the entire RAM is accessible now that we have set up our external RAM to work with the MCU we will now move the frame buffer into the external RAM and this is of course to put the graphics that we are creating into the frame buffer an external RAM and get the display to read from there instead of the one we have created an internal RAM the goal is therefore to remove the frame buffer from our internal memory and create one and have it in external memory the prerequisites here is to have the address of the frame buffer that we are placed in external memory and what we are going to do is that we are going to place the frame buffer in external memory and set up our display controller to read from this place so what we first going to do is that instead of creating a variable as we saw in the beginning creating a ray now we are going to create a pointer to the address where we have the frame buffer and another important step is to go and remove this line because now we are going to set the address of our frame buffer in the qmx and not via code so this needs to be deleted then we are going to go back to the lcdc setting in qmx where we are down here on the frame buffer in the tab layer settings are going to set the address that our external RAM has after you have set up your frame buffer in external RAM you can run it through some test code similar to what we did for internal RAM to check the frame rate but it could be a good idea here to change the order of the colors so instead of doing red green blue do green with blue for example to ensure that we are reading something new and not just running the old frame buffer setup in internal RAM after we have set up our frame buffer to run from external RAM we are going to set up another of our external memories the external addressable flash so as it is with RAM graphic application of course requires a lot of memory and therefore external flash is especially often needed in graphical applications in this step here we're going to enable external flash in memory map mode and read from it again here the prerequisites is to know about how to set up this flash and to know which settings we need to set in qmx to connect it with the mcu and also the dpios that is used so first we're going to go in to qmx again here and this flash is working with quadsby so we can in access our quadsby under collectivities and set up the dpios then to have it running in memory map mode we will go to our code and we will configure our flash to run in memory map mode to test it we can do something similar to what we did for external RAM and read from our flash here it's of course important to remember that if you want to copy all this code and maybe follow in a bit slower pace you can go to our documentation and you can just follow the step by step guide here and hope use this video to give you some introduction to what you can do this step will create a driver for our non-memory map flash to enable it to work together with touch gfx the goal is therefore to have a driver that can read from a location in a flash and store it in an array which touch gfx can use later on the prerequisites here is to have some information about a flash again usually from a data sheet and all so some information about the connection between the flash and the mcu and the speed of the flash is also needed so what we're going to do to get our flash up and running in block mode is to go to the fmc part of our project in qmx where we usually are able to set up our nand flash and also still set up the cruise b for the flash or the other interface that we're using including the gbio as we did in the memory map mode step and then we need to add the code to address the flash so the code piece we see here under the qmx setting is where we're going to set up our driver which will be used later on by touch gfx in this step we're going to set up our hardware acceleration meaning our chromat dma2d the reason is that by using our chromat we are able to drastically improve the graphical performance when we are transferring data from memory into the frame buffer the goal is therefore to enable the chromat to read and write data prerequisites is of course to use an stm32 mic controller which has chromat so the first step we're going to do is to go into a qmx and as we see here under multimedia we are able to select the dma2d and set it in memory to memory mode next it's important to set up our interrupt so we know when we are done using the chromat to transfer memory and this is done by entering our NVIC settings on the system core where we will first set up the interrupt and then afterwards ensure that some code is going to be generated for it when this is done we're going to write some code that will fill a specific color into a rectangle target in our memory the code here is from our documentation but it's recommended that you look into your firmware for the specific mcu that you're working it to figure out how to perform this for the mcu that you are using but the goal is to use dma2d to transfer this memory and be able to measure or see the performance increase also as a side note this code is not what is going to be used when you do the extraction layer because the generator will there help you generate code that will work together with touch gfx next up is the touch controller so setting up the touch controller will enable us to interact with the application via the touch interface on the screen the goal is therefore to be able to read the touch coordinate phase and where we're interacting with the touch screen from the touch controller the prerequisites here is to have a display with a touch controller on it and to have some drivers to read from the touch controller the first step is therefore to set up the communication with the touch controller and the example that we are working with here the touch controller is using i2c to communicate with so this is what we will set up in qmx and then we will use the driver code afterwards in our program to set up the driver to interact with the touch controller finally based on the driver code that we have from the touch controller we will be able to set up some function where we can read information from our touch controller for example here we will get some state and if the state is that something is happening with a touch controller we will read the x and y coordinates another interface that we can use to interact with our application is physical buttons physical buttons is both something we can use in our application combined with the touch interface but it can also be the only interface to the graphics the goal is therefore to set up the application to receive input from the button the prerequisites here is of course to have some physical button that is connected to the MCU so the first thing we will do is to identify which GPIO our button is connected to for example from the datasheet that we have been using we can see that the button here is connected to pc13 then we will go into qmx and set up our GPIO to be in input mode and based on the hardware setup for the button with a pull down resistor and then we will set up some code to react on the input of our GPIO a little bit help can be using this user label this is not done in example here but giving it a user label with something you can remember will be easier to remember what labels you have to use when interacting in the code so the final step here in our how to guide is the flash loader the reason we are doing this step is to enable our solution to write data to the external flash burn programming this is because that the compiler will compile the text the font the images in your project into a binary or hex file that we need to flash into the external flash where the internal flash is normally reserved for code the goal is therefore to select a mechanism for a setup that we can use to load data to the flash the prerequisites here are that we need the information about the flash and the connections to the flash in the MCU we propose two different ways of doing this the first one is using a flash loader for the stm32 cube programmer the cube programmer comes with a lot of flash loaders designed for the discovery kits and evaluation kits and these flash loaders consist of two parts one which is the configuration of the GPIOs and one which is a setup of the flash interface and setup of the communication with the MCU and the flash this flash algorithm knows the commands and sequence of these commands required to write into the flash to use these flash loaders for the cube programmer you can either get inspiration from them to rework them and get it up and running with your setup and this is done by going into the folder on your computer for your stm32 cube programmer where you can find the flash loaders and also a couple of example projects for how a flash loader is created also if you're using the same flash as the one on one of our evaluation kits you just have to modify the GPIOs to fit and finally the one that we recommend is using the same setup as a display evaluation kit so having the same flash with the same connection to the MCU and thereby you can use the flash loader from cube programmer directly another way to do this is doing what is called a proprietary application based solution where you include the flash loader in your project itself the idea here is that you already have your flash configuration in your application and when you're starting your application you will load the data onto your external flash so where to go next as i mentioned in the introduction you can go to our section hardware selection and board bring up in our documentation and find a lot more information about the two topics that i have discussed today if you want to move on to the next step in the touch effects development process you can go to the part of our documentation which is about abstraction layer development starting with the AL development introduction you can also watch the presentation abstraction layer development to get an introduction as well so that was all for this presentation i want to thank you for following and i hope that you find the information that i have discussed here today useful and something that you can take with you next time that you do your hardware selection and board bring up