 Hello and welcome to this lab on the STM-WIN tool using the Qubemix. In this lab we will use the Qubemix version 4.25, the cube firmware for the F4 platform version 1.18, the board will be the STM-32F469 discovery, and the IDE will be a system warbench for STM-32. The lab is split into three steps. The step 0 is the opening of a prepared Qubemix project. We will then review all the peripherals that are already enabled for the graphics. Then we will finalize the graphics configuration and generate the system warbench project. The step 0 will be the basic appearance of the demonstrator. In the step 1 we will enhance the default graphical user interface appearance, setting some bitmaps to the buttons and also a background image. And in the step 2 we will add some interactions using the touchscreen. So enabling the touchscreen and handle the interaction in the graphical user interface. The STM-WIN is the object oriented C code framework. The library supports all the STM-32 boards. It has a hardware abstraction layer based on touch and display ST driver, and the new board supports are handled directly by ST. There is a special agreement between a CIGAR that provides AMWIN and ST so that ST gets the full source code and can rebuild the library based on STM-32 boards optimizations. Regarding the graphical user interface development phase, there are several tools involved in the development phase. First you have some graphical user interface content importation, using some tools like BMP converter or font converter and also GPEG to movie converter. These tools are mainly used to convert media files such as bitmaps or fonts or movie GPEGs to C code. The graphical user interface appearance is handled by the GUI builder. The GUI builder is provided by CIGAR also. It's not a very advanced tools but at least it can provide a skeleton for the graphical user interface. Don't expect to build your entire user interface in this tool. It has some limitations but at least it's a good starting point. Regarding the graphical user interface logic, it has to be done in the external editor, the chosen one. Here it's KIL, so you will see that we will modify directly the AMWIN source code to handle the logic, the interaction with the graphical user interface. The build is done also using the chosen IDE. It can be KIL, IR or S6 and it's the same for the platform integration. And finally there is a prototyping tool that can be run on a PC using the Visual Studio Express PC simulator. Regarding the support, ST provides an application note, which is AM4323. You of course have the full API documentation in the UM03001. And for a more advanced question, just ask the online support on myst.com. The demonstrator are located in a STM32 cube firmware. For this lab we will use this one. So the F4 cube firmware with the version is 118 and the platform will be the STM32469 Discovery. So we will now open the prepared project. With this MOOC you will have access to NACRIVE called STMWIN Labs version 2.0 Materials.zip. These files contain the lab folder and in the lab folder you have all the content needed for this lab. So first we will launch the Cubemix 4.25 and then load the project from the archive. So here is the Cubemix tool, so it's the beta version for the 4.25 version. We will open the project located in this hierarchy. So here you can see I unzip the archive in the C drive directly. So the lab folder contains an asset folder which contains the images of the demonstrator. The project folder contains the IOC file which is the prepared project for Cubemix. And each step folder contains the source code for the various steps of the lab. We will see that later. So first let's open the IOC project. Okay now the project is open. So let me first show you that in the project folder for the moment there is only this IOC file. This is the prepared Cubemix project which is actually displayed here. Once we will have generated the source code corresponding to this project, this folder will be populated with the all the necessary source code file. So in terms of peripherals you can see here there is a new item called graphics in which STMWin is enabled and also graphics acceleration with the MAT2T. To enable this graphics option you have to enable several peripherals first. The peripherals are the CRC that must be enabled because there is a CRC check when AMWin library starts to check that it's running on the STM32 platform. So this is a security peripheral. Then you have to enable the DMA2D because AMWin library as ST provides it makes intensive use of the DMA2D acceleration. On this specific platform we use the DSI host because the screen is connected in DSI. So it's a special interface but we could also use the FMC directly or the RTDC. The FMC is however enabled also because we need some SD RAM to store the frame buffer of the demonstrator. And the RTDC is also enabled in RGB 888 so it's 24 bits in DSI mode. So these are the main peripherals required to enable the graphics. On the clock configuration we are running at 180 MHz and the pixel clock of the RTDC is 25 MHz. Let's go now to the configuration panel. There are two new buttons on this tab which are the graphics and the graphics simulator. Let's have a quick view on the graphics simulator. This graphics simulator gives a lot of information on the current configuration of course but on a simulated one also. So this is the configuration that is set for this demonstration. Don't pay attention too much on the screen size because it's very specific to this display that we have to split the screen in two in order to avoid some artifacts. Usually you should have here 800 and not 400. But for this specific board we have to use a trick to split the screen in two to have a perfect display. So the RTDC is enabled, the QALSPI is not and the SD RAM is enabled of course. And here on the lower part you have the information on the pixel clock that are feasible with these settings. And if you want to test others you have to adapt these settings on the simulator configuration part and it will be displayed on this part. So the results here are different scenarios if you unfold all of them. So you have different scenarios. First build the image using the internal flash and external SD RAM on a 16 bit per pixel frame buffer. Build an image and display it using internal flash and external SD RAM. These scenarios give some numbers, some pixel clocks and some timings depending on which memory you use to store your input images and to store your frame buffer. Of course if you store your frame buffer for example in flash you will have terrible performances so you better store them in SD RAM but the SD RAM may not be able to contain all your input images so they will be put in the external or internal flash. In the end the frame buffer will be in the SD RAM or in the SRAM. Usually the SRAM is not sufficient to contain a full frame buffer. So this can give some interesting information on the pixel clock required depending on the scenarios. Before going to the graphics options we need to check that the QO firmware has been found by the tool. So we go just to project and settings and check that this pass is good. So this one is good. This is the QO firmware F4 1.18 and my REMC reference is the 469. So this part is okay. I will now launch the graphic options. So the first tab shows the general graphics options which are already configured based on the LTDC configuration and on the DLC host also. So these are almost filled automatically except for this one that must be enabled. So this one will allow us to launch the GUI builder tool directly from the QBemix clicking on this button. And the graphical user interface builder tool is located in the QO firmware. That's why we have to be sure that it's been correctly found by the tool. Then we have to update the dimension of the display. So it's 800 by 480. The driver is fine. The number of virtual screens is okay. Also we have to set the number of buffers to 2. 3 could be also accepted but 2 frame buffer for this kind of demo is sufficient. The color conversion will set it to GUI CCM 8888 inverted. This is very specific also to the current version of AMWIN. This color conversion is because this current version of AMWIN was not supported natively the RIGB format. Instead it supports the BGRA format. So we have to specify that it's an inverted format of the 8888 RGB format. And then this is okay except for the LCD screen. We have to update it because this screen has an internal controller. So we have which is called the OTM 8009A. So we have to set it so it's a landscape orientation and RGB 8888 format. Then we go to the STMWIN tab. For this demo we will use a window category. This is only related to the name of the file that will be generated. You can see here that all the grade information are automatically filled based on the parameter that we set. Either on this or on the LTDC or DSI PABIFERAL. For example this format is automatically taken from the LTDC configuration. But some parameters still have to be configured in this dialog box. So this is okay for the STMWIN. And regarding the other tab we have here for this specific screen to select this GPIO. Because it's the reset pin that is configured on this PH7 GPIO. So now we can launch the GUI builder from the Cubemix. So let's click on the execute button. So here is the graphical user interface builder tool, GUI builder tool. So let's design our first version of the demonstrator. It will contain first a background image. Let's put it at the right size. So it's 800 by 480. So for now there is no actual image associated to this image element. We will set it later. And we can add some buttons also. That we will use later. And that's it in fact. Maybe one more button. So now we have a first ugly graphical user interface. We will save it. And it will automatically generate a window dlg.c file. So here it's already existing. So it's replacing it. And we can close. So let's apply all these settings. And close this window. Now we can generate the code. But before that let's go to the project settings to check that first system row bench for STM32 is selected as the ID. You have also KIL or IR. And True Studio is the solution from Atolik that has been bought by ST. Will be available in the next release as well as the Mac file and other two chains. So here we choose the system row bench for STM32. In the code generator tab just be sure that you have this option checked. This allows to keep the code that you edited outside the QBemix when you regenerate the code from the QBemix. If you edit the code between specific tags then your code will be kept when regenerating the code from the QBemix. For example if you add a peripheral from the QBemix you regenerate then you will keep the code that you put in specific tags. And that's it. So regenerate the code. You will see that for the build processes not for this one which is quite fast but for other processing are we going fast forward. So don't be afraid your PC is not slow but the video is fast forward. So we can now open the project. It will launch system row bench and import automatically the project that we generated. In the meantime I can show you that in the folder that only contained previously this IOC file it now contains all the source code. You can see that all the source code has been imported or generated from the profile of the QBemix tool. So here we come with the system row bench tool and here is our project. And you can see for example that in the STM win we have here the file that has been generated using the gray designer. For now we can already build the code and flash it on the board. That's what we will do and then we will enhance the current demonstrator. At this moment you will see that we have quite an ugly demonstrator with default button appearance and default bitmap for the background image that we set. So let's launch the build in the fast forward way. So now the code is built. We have an X file and we will flash it directly on the board. So just right click on the project and use the command debug as AC6. So now the code is flashed and we will go and you can see on the board the ugly demonstrator. So now let's go back to the input files of the labs. We have three steps, the step 0, step 1 and step 2. In fact the step 0 is the one we already done so we will not use these input files. It's just make an empty demonstrator screen. We will use directly the step 1. So to use them we use a file comparator tool which is called beyond compare but you can use any other tool. So as you can see the only difference is an extra file which is called resources.h. This file contains the C table for all the images of the demonstrator. The images are these ones. You can see the butterfly blue, green, pink and yellow as well as this little butterfly in only black and white version. And some home button, mail button and the logo. Of course the background image is also contained in this file. This is why it's six megabytes large. So we will copy that directly this file. And then there is some update in the window.dlg.c and we will see why. So first of course to include the resources.h. The button here we defined only four buttons and a background image. In the actual demonstrator there are also two more images and some text also. So we'll add this. This one is no more useful. This table is the default background image. So it's the gray square that we can see on the screen. It is no more useful because we will replace it with a nicer image. But the table corresponding to this nicer image will be in the resources.h file. The idea is to keep this window.dlg.c file readable. If you put all the images as suitable in it, you will get a very large file. But also very hard to read because the source code will be at the end just before the images. So we will remove these images. Here is the default location of each button and images. And you have here callback functions for each button. These callback functions are needed because we want to change the default appearance of buttons. The buttons have a paint message that will be called each time the button needs to be refreshed. And in this case we will draw the bitmap corresponding. For example here it's the home button, the mail button and the butterfly button. So we have to override the default refresh functions. And also this one. Then these two variables are normally needed. And here it's the callback, the main callback of the graphical user interface, which is called as soon as something happened, an event happened. So an event can be a button pressed, can be a touch information, or also some refresh of a widget. And here in the dialogue is the message that is received when first creating the window. And in this case we will draw the background image and each button with this corresponding image. And also setting as you can see, we set the callback for each button and the callbacks are the one we just added before. And finally we have also to call to force a repaint of the window. So regarding the system or bench, normally it has been updated accordingly. If we go to the window dlg.c, we can see that all that we did is there. And we need to refresh the project so that the resources.h appears also. The system or bench automatically scans the folder hierarchy on the PC. But it doesn't mean that the include file will be automatically found. And you can see in this file that you have here the background image. So it's mostly made of white color. So this one is for the transparency, which is fully opaque. And this three value, you have two F per value. It means a maximum value for RG and B, which makes white. But it's not all white, of course. There is at some points other values here, for example. And you have also the buttons. So here's the mail button with the corresponding image. So let's build again this demo and flash it again. That's done. And you can see that the window dlg.c that we modified has been rebuilt only this one. So let's flash on the board. So after flashing, like many IDEs, the function, the execution is stopped automatically just at the beginning of the main function. So we need to make a go. We show is the resume here to actually run the application. And as you can see on the screen, the move is much nicer like this. But there is still no interaction possible for the moment. And the blue butterfly is an image that will be able to move using the touch display in the next step. So back to the input files of the lab. We are now in the step two. So we will compare the step two files with the current project. For this step two, we have to first add the low level drivers for the touch functionality of the display. This can be found in the BSP folder. It's this one. So let's copy this driver. Let's go now to the file we already know, which is window dlg.c. There is not much update in this one. There is a status of the power of the butterfly for the image, the butterfly image. You will see it's used later. We have to set movable the butterfly image, the blue one that I show you on the screen. In order to move it with the touch screen, we have to set it as movable. That's the AM win API. And here, this is the default action of the home button. So the home button will set back the butterfly image to its original place and set it to blue. So that's why you have a move item to this position and set image to a butterfly blue. Then another button, the butterfly one. There is a small white butterfly button. This one will change the color of the larger image button. So you will see that each time we touch the butterfly button, the small one, the bigger butterfly will change its color. So it will change from yellow to blue. It will be yellow, pink, green and blue. And finally, we have to enable the motion in general for this dialog box. So that's it for the window dlg.c file. On top of the low-level touch driver, we need to have some high-level drivers for the touch screen, which are dedicated to this board and which are contained here. So these two files. And these two files are also dependent on more generic definitions that are contained in these ones. So that's it for the application part. And that's it, in fact, for the step two in general, except for the main, of course, the main.c. In the main.c, we need to initialize the touch screen, especially a timer. Because in this demonstrator, the implementation of the touch screen is in polling mode. But it can also work in the internet mode, which means that we are polling the touch driver constantly until we see some modification on the coordinates. But there could also be an interrupt falling each time we touch the screen. It depends on your requirements. In this demonstrator, it's in polling. So we have to initialize a timer dedicated to the touch screen. On each expiration of this timer, we will check the touch coordinates. So we initialize it. And here's the code for the timer initialization, but also the touch initialization. Here we call the BSPTS init on the full size screen. And this is what we do when an update of the touch coordinate is detected. And finally, the include file must be also dated to get the driver, the higher level driver for the touch screen. So let's go now back to the system or bench. So we will launch the build. First refresh. So we can see now in driver you have BSP. We have our low level driver. So as you can see, there is no error, which is in fact normal. Because when we added the driver here, the system or bench project detected some new files and it detected some C file. So it added it automatically to the file that must be compiled. And since the include file is in the same folder, it's not an issue. But just keep in mind that if we could have here, I've had some SRC folder and include folder. And then the system will have found the C file, but not the pass to the include file. So in this case, we do not have to modify the project, but it could happen. So let's keep this in mind and we now can flush the final version of the demonstrator. So now the system is stopped at the beginning of the main function. We will let it go. And now I can move the butterfly, change its color, put it back to its original. So that's it for this demonstrator. I hope you enjoyed this session and see you in the next MOOC.