 In next example, I will show you how to use custom HID class, one of the standard USB class also supported by QPMX. What is good for custom HID is intended for data communication using the interrupt transfer. So instead of the CDC, which is using bulk, here are the interrupts. So the response of the device of the communication is ensured, the bandwidth is allocated, but the throughput is limited to 64 kilobytes per second and the communication is expecting fixed packet. What is the biggest advantage and why it's worth to use it is that it has a standard class with HID. It don't need any drivers for Microsoft Windows. So you are able to deploy without additional driver development, additional signing of the driver and it can be very easy for some control transfer. So in our example, we will again use QPMX. So we are using F446NLQFP144. Like for each USB application on F4, we need to use high speed external, here bypass from ST-Link. We want to have OTG full speed as device only and the class we will use in the middleware is custom human interface device. Additionally, we will also use the PC13 for the input, which is the button here. So in the clock configuration, our input frequency is 8 MHz. We want to use the high speed external and some bigger speed, OK, 48 for the USB and we are good to generate here. Bigger heap is not needed, so only the name need to be choose. And for sure the ID we are using. So we open the project and we can take a look inside of it. In default shape, the custom hit example is generated for the messages with size of 2 bytes for the historical reason, but we will use the 4 bytes for the communication between the host and device. So for this, we need to change the configuration. So we will go to include file to the configuration one. And here, we will change the size. So instead of 2, we will use 64, so 0x40 and the same also for the report descriptor. That's all here. And in the custom hit interface, not in the interface here, is the size of the endpoints. So we see the numbers and the size. So we want to increase the size, which will be then propagated to the configuration descriptor. Also the report descriptor's size, which is already changed, so this is not about the size of the buffer, but the size of the hit report descriptor, which we will modify a bit later. So let's go back to custom hit.h and here is the structure of the custom hit. We can see that the out event is expecting 2 bytes, but as we change to have 40 bytes, we will use a buffer instead. So let's pass a pointer instead of this configuration. If this changes, we will go to the middle layer to class functionality. And here is the configuration descriptor of our device. So to this descriptor, we are propagated the changes we made in the header files. Additionally, we can change here the pulling interval, which is defining how often the host should ask for data from our device. So here we can lower to get better response, but then the bandwidth can be limited for other devices. More important here is to change the out and in functions, which are used. So HID data out, we can see that here in the out event is passed the pointer to only 2 bytes and we want to change it to buffer. So instead of 2 bytes, here is a buffer and the same we will do also for endpoint 0 rx ready. So this change provide us the possibility to send more than 2 bytes. Now we will go to the source file and custom hit interface we have, which is again prepared for 2 bytes. So first we will create a buffer, for example, never mind. Now it's defined for 64 elements, which is good for the full speed. But for example, with high speed usage, there are other speed usage that could be different sizes needed, but for now it's not crucial for us. So we have our buffer and again here, we have 2 bytes, where we are using the buffer. So we keep one of them and change to the pointer. And the same we need to do also for the function itself. So only one is here and is a pointer. So this is what's happened when we receive some data. As we are acting as a device, we are in out direction from the host point of view. So this is the callback upon receiving any kind of data. So for the demonstration purpose, we will add here the eco functionality. So we will copy, receive data to the buffer. So buffer and after that, we need somehow to send the data. This function is in the interface and it's called usbd custom hid send report. So we will pass the handler of the device and the buffer. So we don't need to retype and the link is fixed to 64. But very important step, which is probably the biggest drawback of this solution is the report descriptor, which is common for the hid. You are able to see it also with the mouse keyboard and it's a collection of numbers without any meaning from the human point of view, which is defining the functionality of the device itself and make the solution universal. But as it's not easily readable for human, it's also not so easy to create such a number and they are dedicated to for it and probably the easiest way is to find some source online, follow that source and use its values. You can see the values we will use in presentation. I'm not able to describe here all the meanings and so on. It's better to go directly to the specification just to highlight. Here is the report count. So here we are directly showing the size of the data we will use. So now we are ready for building the project that's better and low to the microcontroller. So let's run, let's see, VCSTM32 human interface device and again in attachment of this example, you can find the terminal application. It's very simple demo, but you can use for the test purposes and for the next inspiration. So we can send some data and here in the receive, we will see what it's returned from the PC. Like before, plug and play if natively support it. So for example, now if I remove the USB and plug it again, I'm still able to send and receive the data. If I remove and send, we get a failure to open the device and the program is closed. So using this simple step, you create any type of application which you may need for simple communication between host and device without additional need for the drivers. So we've defined the response time from the device.