 Here we have the block schematic of the USB host as it's done with the OTG peripheral in STM32. So some blocks are similar to the blocks inside of the USB device. So again we have the core with the bus and the bus driver and the FIFO. The FIFO are divided different in this kind of application. Again we have one FIFO for the RX for receiving but then there are two additional FIFOs. One for non-periodic endpoints and second for the periodic endpoints. The periodic endpoints are isochronous and the interrupt endpoints. So it can be a bit get out of the nature of these types. And the endpoints are entered using the queues. So there is a non-periodic queue and a periodic queue. So if we have inside our host application something to be sent, it's put into the queue and one is get at the end of the queue. It's put to the FIFO and to the driver. Here it's also important to mention that the periodic queue have the priority before the non-periodic queue. So you are able to put on the bus something from the non-periodic queue only if there is nothing in the periodic queue. So that also make you sure that if you have the interrupt it will be on time the same with the isochronous transfer. Both need to wait. And host channels are then connected to the periodic queue according to the use transfer type. So now why we need to have multiple channel numbers and why the number is increasing, decreasing across the device and why we need to have these numbers. So for each endpoint you are connecting, you need to connect to some channel. So for example as we had the VCP device that are free endpoints, one interrupt, two bulk endpoints. So we need to have three channels to connect this interrupt and also then the control one. So we need three channels but we have for example 16. Because some devices like the GSM model I mentioned may be composite and composite with five UART. So they are demanding to have 15 channels to be used. Otherwise if you don't have enough channels you can connect also some of these devices or some of these UARTs. So in the past what I did so on some older devices I was able to connect maximally free virtual comport. So I have to pick among the pipes or among the interfaces from the device which are needed for the communication in my application for the purpose and which are not mandatory there. Also the channels are not statically allocated. You can relocate on fly but usually this is not done and there are no such examples in our library. So here is the similar picture like before with the device. So again we have the upper layer file so the USB host.c where I am able to see the user structures if the application is ready or it's disconnected. Inside of this file is intended to have the transmit and receive function callbacks and all the handling connected to the upper layers. Then there are the device drivers and middleware. So we already get up to this layer but inside of the core is the USB H process. So the process which is driving the enumeration, driving the connection which we need to call periodically. Then there are two functions. So for the control request and I request and for the host pipes which are the channels. This is common for all the host application no matter what is the class. And also from these functions we are calling then the class function. So from the core we are calling the class function. So we were able to see that from the process we call the CDC process. And if we want then send any kind of data or start the reception we need to go to the I request and to the pipes. These middleware layers are connected through the USB H configuration file where we have the settings of the number of endpoint, settings of the peripheral, settings of the GPIO interrupt and so on. Down to the whole drivers. So now during the reduction of the load on the bus we also touched the ACD.C. So the callback from the interrupt and there is one additional with the lower function of the peripheral. So this is already tightly connected to the device. And after that we go through the register access to the IP. So the hardware peripheral on the microcontroller which is notifying back using the register access and using the interrupts. And here we have the overall structure inside of the host machine. From this point of view it's look more or less heavy but we already were able to see almost all the structures and some of them we already modified. So for the first one this is the structure inside of the USB process. So we have here the state of the host machine, state of the enumeration and of some additional stuff. Also through this structure is connected the active class. So as you can see here it's prepared to support more classes. And here we are showing the active one and also the pipes so the channels work. So in the host state this tells us where we get during the USB host process. So either we are in the idle state and we are waiting for the connection. Once we get connection we go through the bouncing and detection through enumeration and detection of the class up to the host class. Inside here the functionality is passed to the class driver so in our case to the CDC. After that we can get also to the suspend so we decide to put the device into the raw power mode or to the abort. During the enumeration there are also values state. So as you see during the theory on the first day you need to get the device descriptor, set the address. Then you need to ask for the configuration descriptor. Optionally there are the string descriptor, product descriptor and serial number. So you obtain all this information and these are set in some other structure it will be shown later on. And once you are asking for the descriptor sending the data you are also in the value state. So first you are in the idle nothing is done. Then you need to send the request so put into the queue. But still you are still waiting for the confirmation that the request was received and you get the response. So you are in the wait before you can get back to idle and move to different state for example into enumeration or different state. Control type def. So this tells you which pipe you are using, where is your buffer, what is the length and the timer for timing the application. So for example to be able to put there some time out and don't get stuck completely if something is not responding. Control type def. Okay this is for example if you run already sent some type of request you were able to see also during the first day territory how the packet is put together what are the types of the field inside. So you see again value index request type. And the control line state. I think this is quite self explanation. So for what you are waiting on the state. So this branch here you are holding the data about the device you received from the descriptor. So the configuration. Otherwise you assign to the device speed on which it's communicating. Then if the device is exactly connected. For example this is change using the interrupt and then you are reading inside of the process. And then to another structure. So the device descriptor and configuration descriptor. And inside of these two descriptors you are holding the information about connected device. So that is also the reason why we need such a huge heap for the device to be sure that we will be able to put everything inside. So device descriptor configuration descriptor. So after then when the host process is checking if the connected device is compatible with the active class. It's checking with the configuration descriptor. So it's comparing the class number and the subclass number of the set and the one which are set using the defines. So this is different for the virtual comport. This is different for the HID for various type of application. Interface descriptor. So this is now directly about the connected interface and about the endpoint in the interface. Okay what is here. And this is the structure which contains all the class dependent structure. So we already show how to go through this process to the class process from the core process. So the connection between the core and the class itself. So here how it's go through the animation. So once we submit the URB. So this is already the low layer function. So it's just about the hardware. So this at the end send the data to the to the bus. And once we get the acknowledge via we get a interrupt. And in the type def we go through the state. And we need to check the state again in the process. So through the process and we can do the next operation defined by the process. So for the host reception it's a bit similar. Only that first we get we put only the in we get the data data acknowledge and after acknowledge. We trigger the interrupt is triggered and we can move on inside of the host machine. So here it's one more time described what I believe already showed during the CDC demonstration. So first we are in the host idle state and inside of the state we are only checking if there is any device connected. So nothing is connected check again nothing connected check again. But once we detect any any device we will reset and move to the next state. Then after we receive the interrupt that the peripheral detect the connection of the peripheral after reset. We again move to the next state. So we know now that there is the device attached. So we check the speed if it's full speed high speed low speed. Open the endpoint zero which is then taking care about the animation. What maybe I should also mention here that for the OTG full speed we have the full speed host. But the full speed host is also capable to connect the low speed devices low speed functions. But on the other hand it's not possible with the OTG full speed act as a low speed device. No in this case it's only full speed device but the full speed host is compatible with both of them. The same is true with the high speed. So the high speed with the external file is able to act only as a high speed device. But for the host functionality the host according to the specification have to be compatible with the lower standards. So the high speed need to be able to handle the high speed communication full speed communication and low speed communication. But if you go higher to the super speed super speed is not for super speed is not mandatory to handle the low speed. It's not mandatory but it's common. So back to the topic here. We check the speed. Open the endpoint zero and do animation start. So we are going through the all the step of the animation. So get the device descriptor configuration descriptor. And at the end the string descriptors and that lead us to the host configuration. In this step we check if the connected device or the class of the connected device is supported by our current active class. So we check if on our CDCVCP host is connected to CDCVCP device or the master edge. If it's master edge we are not able to go on. If not, if not, we go to the class request. So for the CDCVCP that's our request during the start. So the line coding and any other commands connected to the CDC class. And then we go to the host class. We already were able to see that inside of the host class we are calling the command so the machine of the middle layer of the CDC. So in the structure there we have the reception and transmit for example for the CDC may be different but here it's already class dependent. And from this we can only get to the, sorry, to the disconnection state or to the abort state if the device will store us. And if we go to the disconnection again we are moved to the idle. So this was again a bit more theoretical but at the end we were able to show that it's working like that in the library. I can believe that on first look it can be really strange but like for the CDC you have it here if you have any doubt what is connected how and not able to found inside of the code. You may use or to remember otherwise it's for the first touch not exactly needed but we like to mention it.