 and welcome on our STM32Q IDE by Ziggs training session. In this part, we'll try to convert our existing example from HAL to low-layer. We will reuse our existing external interrupt hands-on session, which has been fully done using HAL libraries, hardware abstraction layer libraries, and we will change it to low-layer. So in this project, we have configured already two GPIOs. One is output to control LED. The second one is an external interrupt, which is connected to our blue button on the board. We configured as well the nested-vector interrupt controller and VIG to accept interrupts from the maternal pin, but now we will reuse this configuration and transfer everything to low-layer to check what is the difference between those two approaches. OK, I have just opened STM32Q IDE. I'm opening the project for external interrupts and I'm opening GZERO External Interrupt IOC file. I'm just double-clicking to open the device configuration tool. The project is done. It's ready. We do not need to change anything within the pinout, within the clock configuration. So again, we've got PC13 is configured as GPIO underscore external interrupt, line 13, and its label is blue underscore button. And then PA5 is configured as GPIO underscore output, and its label is LED underscore green. Additionally, we have selected SWD interface as a debug one, and we have not changed anything in a clock configuration. So we are working on an internal oscillator HSI, 16 megahertz, which is clocking the compete system. The only difference, which we'll do right now, is the difference within the project manager. We go from project to the advanced settings. And for each of those two modules, RCC and GPIO, we will switch from HAL to low-layer. I just click on this HAL and select low-layer instead. The same for GPIO. Once done it, I will generate the code. So I just press Control-S, Control-Save. And now I need to regenerate the project. So I click this gear icon to generate the new project using low-layer libraries. I can see some action on the left side. Now if I would go into the HAL driver, within Includes, I can see instead of HAL files, I can see low-layer ones. So the structure of the name for the file is the following. Name of the family underscore. Type of the library, in our case low-layer, underscore name of the peripheral. Most of the functions, in fact macros, to control the peripherals, are stored in the header files as a macros, as a macros which are operating on particular registers. The idea behind the low-layer macros and functions is that each function, each macro, is operating on single register. Let's have a look on our source file, main.c. We can see still this user code, begin user code, and sections. So we can see still our flag, which was between the user code section, so it was not deleted. Additionally, we can see some new functions, like enabling the clock to system config and power. And we still can see our HAL function to toggle the LED, because it was within the user code area. If I would try now to compile the code using the hammer, I can see two errors. If I would inspect it, I can see that HAL function is not recognizable, because we switched the library from HAL to low-layer. I would comment it out. And then I will try to find a similar function within low-layer library. So I'm starting low-layer underscore GPIO underscore control space, and sorry, underscore control space. And there is exactly the same function, same name, toggle pin. And again, we need to specify the port and the pin mask. For this, I would reuse the arguments from above. Now it should be OK. Let me spend a while on definitions of those macros. We can find them within main.h file. As you can see, LED green pin has been transferred to LL underscore GPIO pin 5. And port is the same. If you would change to HAL again, those definitions would be changed as well. Instead, this LL underscore GPIO pin 13, we will have only GPIO pin 13 and GPIO pin 5. So the application during the code generation is handling all of the definitions which has been developed by us during the device configuration. OK, so we have the main while one loop ready. Next point would be implementation of the interrupt procedure. In the HAL version, we were using this callback, which would be not used anymore. So I would comment it out, because the structure of the interrupts handling is pretty different here. So let's go to interrupt factor file. And we've got all the procedures of active interrupts. And again, we've got some system ones, like NMI, Hartford, SVC, PentSV, and C-Stick. And we've got our IRQ handler for external interrupts. So as you can see, again, everything is done for us. I mean, detection of source of the interrupt and clearing the flag. But instead of calling additional function, everything is done within this file. So we've got one call less in the hierarchy of the interrupt handling process. So the only thing we need to do is to set our flag. Flag set to 1, but we need to import it from our main file. This is why I will go here above this file. And I would just import it external. Now let's try to build it again. No errors, no warnings. And let's turn the debug session. I press the play or resume button. And I'm pressing now the blue button. And each blue button is changing the state of our green LED. So the application is working properly. I'll terminate the code execution. And now application is still in flash, so I can still play with the part. Thank you for watching this video.