 So we are working now on a custom board, an unknown one, a custom board, based on the same chips, which is the STM32 H7-B3 IL. So let's go, let's close this one, and let's go to the Cubemix. So here we will go and select our MCU, which will be H7-B, so this one. So the first screen shows a completely un-configured MCU, of course. So we need first to enable the 3rd JFix plugin because as you can see here, there is no more graphic IP here. Previously there was a graphics section when we can enable 3rd JFix or STMWin. This one has been removed, and now we have 3rd JFix coming as an additional software. So an external plugin. So the first thing you have to do is to go into the software package manager and download the 3rd JFix generator package. So once this is downloaded, so this is green, you will be able to go to additional software and here enable the generator. And once this generator is enabled, you have a new section appearing here, which corresponds to the 3rd JFix generator. So I enabled the graphic application, and now I have a list of the parameters that are directly linked to the 3rd JFix library. These are mandatory that are required by the library to be initialized properly. So I need to enable first all the peripherals that are needed. So I will go first to the CRC, so I will mute and do it quickly. So now the mandatory peripherals are enabled. I can start configuring my 3rd JFix framework. As you can see, there are a list of dependencies. These dependencies must disappear in order to generate the code properly. These are kinds of constraints that need to be fixed. So the pixel format is not the right one. The number of layers is wrong, because I didn't set anything, and the alpha constant should be 255. So regarding the display, first I will select the LTDC interface, because I will use the LTDC to control the screen. In this use case, I will select also RGB888. The widths will be the same as on the Discovery bot, to be simple. Here I can select the single or double buffering, or even partial buffer, so I will set single buffer. Anyway, just to be clear, we will not flash the generated code on the board, because it will require to add some board-specific initialization. I will show you that's what the Qubemix does not do, in fact. The 3rd JFix designer with the application template does this for you, but when you are using the Qubemix, there is a part which is specific to your board that needs to be implemented by yourself. So the LTDC tick source will be used, the chromat also, and the freartos. Now I have to fix the LTDC. So now, hopefully, all the dependencies are removed, so I can now generate the code. So I go into project manager, I will generate in the webinar also. My project is called S7B, we use case B. We will use advanced structure and SM32Q by D, and I can generate the code in fast-format mode again. Now the generation is done. So we open the folder. So here is the folder that has been created. So the most simple way is to directly open the Qubed and import the project. So it's an existing project, use case B, and finish. So we can see our IOC Qubemix file. We can see also some term JFix initialization, but what we cannot see compared to the other use case A, is that we have no graphical user interface files. This contains the graphical user interface definition. And also there is a generated part that is read only, and there is this part that the user can modify. So this contains all the buttons, the image, the background image we defined. This is for the moment not present, but we have here a dot part file that can be opened in a .jfx designer, and this will allow us to create the user interface. So what we basically defined using the Qubemix and the .jfx plugin is an application template, at least part of it. So when I double click on this dot part file, the .jfx designer opens and you will see that I cannot select, I do not select the application template because it's already set in some way. I only have to select a user interface. So I will select again blank UI. And here I can create, so I will go very quickly, add a box, add a button, and generate the code. So when I generate the code, I will create the generated and a GUI folder that we saw on the use case A. Just note that in this case, since we selected the Qubed ID, there is no run target button available. The reason is that for the run target to be enabled, you need the GCC tool chain behind. And this is available only when you start from an application template. But the run simulator button is still available and working, of course. So the code is now generated. I can go back to Qubed ID and refresh my project. And now I can see that I have, as in the use case A, the setup of the basic screens and the user part that can be modified with the screen one and the common file to my user interface. And the last point is that in the drivers folder, you can see that there is no BSP folder. So that means that this is an empty, it's a skeleton as far as the board-specific peripherals are concerned. So if I launch a build process, it will build, it will generate a file, but it will not be functional on your board yet. You still need to provide all the low-level drivers and the specific initialization of your screen. For example, a specific pins, the backlight needs to be enabled at a specific time. This cannot be guessed, in fact, by the Qubemix and it's not supporting the BSP for all the available displays and all the available external memories. So this is up to your user to implement it. So that's it for the second use case and that's it for this entire lab. I hope it was clear. And so I invite you to test it directly using the designer and the simulator and enjoy developing using the TouchFX solution. Bye-bye.