 Welcome back! After watching previous video series, we are going to take a look at another BLD example. It's called P2P Peer-to-Peer Example. Here's a quick recap. Smartphone devices are called central devices, whereas the STM32 WB board is a peripheral which advertises BLD packets and sends sensor data. The roles can change the other way around as well. With other examples, you can configure the STM32 WB as a central device or a device that acts as a central device as well as a peripheral device. For now, we are going to focus on the P2P server example. GAT defines the way that two Bluetooth low-energy devices transfer data back and forth using services and characteristics. In this case, the STM32 WB acts as a GAT server. When running the P2P server example, the smartphone will discover the P2P server service after the connection. On the other hand, the smartphone app will check available services and characteristics. For the P2P server example, the user can write or read the LED control, meaning the user can turn on or off the blue LED by writing it, and the user can read the status of the LED as well. The P2P server can notify the smartphone app when pressing switch 1. You can observe the bell icon flashing when the GAT client receives the notification. The Bluetooth SIG defines quite a few standard services and characteristics just like the heart rate service. However, many times you will find that none of these satisfies the use case you are designing. That's where this type of custom services and characteristics come into play to toggle LEDs or receive custom notifications. In summary, the P2P server example adequately fits these specific requirements by providing both a custom P2P service and two custom characteristics. We are going to explore the STM32 software ecosystem by using both the STM32 QMX project generator and the STM32 Cube IDE. Please check your prerequisites before starting, otherwise refer to video number 3 for more information. Let's explore the P2P server example which uses the P2P service. Instead of importing or opening the example IDE project files, we are going to generate the project file using the STM32 Cube MX and build it. Since we have created a duplicate copy from previous video sessions, please navigate to the P2P server example. Let's create a copy to maintain the original example. Next, open the STM32 Cube MX project which has the .IOC file name extension. Let's open this .IOC file inside the P2P server example. The key takeaway is to use this enriched ecosystem to use the development process. We are going to use the default project settings so that we can use this example right away. Click the project manager tab. From the toolchain drop-down box, select STM32 Cube IDE and uncheck the generate under root option. Lastly, move to the code generator menu and select copy only the necessary library files option. Now let's generate the code. After generating the project, you'll know the three new files were created. Note that the Cube MX configured the STM32 Cube IDE project to use the existing source files like main.c so that you can use the example right off the bat. Now let's check the newly generated STM32 Cube IDE to build and debug the project. Don't forget to enable the debugger. Open the trace options if you want to see the trace messages. Open the STM32 Cube IDE project and build this by pressing the hammer icon. Since this is a freshly created project, set the debug configuration to start debugging. Now you are ready to debug this project using the onboard ST link. We're going to take a look at a demo of the P2P server. Let's connect the STM32 WB board using the ST BLD sensor app. With this app, the user can toggle the LED on the nuclear board. Also, the user can notify the sensor app when pressing switch 1. Moving on, let's change the STM32 Cube MX file and rebuild the project. When trying the BLD examples, you might want to change certain pins for your requirements. The STM32 Cube MX makes it handy, for instance. I can change one pin as a GPIO output pin without affecting the original example. The original example code only has 4 lines in the MX GPIO init function. Let's modify the PA0 pin and check the difference. Close the project and reopen the STM32 Cube MX project file. For demonstration purposes, I'll choose the PA0 pin as a GPIO output and name the pin using labels. Though there are three onboard LEDs populated, these are managed within the BLD application and the board support package files. So instead of editing those parts, I'll choose a separate pin. Click the system view perspective for additional configurations. Let me set the PA0 pin as high. Let's regenerate a STM32 Cube IDE project. The example code's core parts remain the same when regenerating this. You might guess that the MX GPIO init function has changed due to this custom configuration. Let's see. You are correct. The STM32 Cube MX has added codes exactly how I want it. I'm going to wire a green LED after building and downloading this new project. Let's take a look. This green LED is off right now. If I connect the board to my laptop, the firmware code starts running and the green LED turns on as we have expected. That's all for this video app session. I'm looking forward to seeing you again with other video app series. Thank you!