 Very often we get complaints about throughput, which seems to be not high enough for some STM32 users. In this chapter we will show conditions affecting USB devices throughput. In this case our focus will be on USB CDC device example. Then our results with various scenarios in setting will be presented and at the end of this part a few tips how to optimize more project with STM32 for reaching higher speed can be done. Probably the most crucial fact for USB devices throughput is that USB communication is driven by host. So even if device is able to response on each host request immediately throughput may be low due to host low frequency of in and or out packet sendings. This is very typical problem with commonly used virtual comport application used on PCs. These applications are not expecting so high throughput from the devices as they are on emulation of the obsolete communication devices with lower speed. So the bandwidth achieved with this program is usually limited. Another problem may come with CDC endpoint standard behavior. Bandwidth is not guaranteed for this kind of endpoints and share among all devices on the root hub. So you cannot expect same results with device connected on directly to root hub or if you connect as one of multiple devices to some of hub downstairs in the USB bus topology. Topology of USB connection inside your PC where your device is already connected can be displayed using device manager or some dedicated application as you can see on the slide. On the pictures on the slide on the left side you can see a device connected to root hub to hub but on the right side the device is connected already directly. So using this way you can explore the USB ports on your PC and choose the one which is connected to most directly for the usage and also try to skip other connection on the same root hub. If you go back to problematic of USB host and frequency of sending the request on the device now is the question how do actually get the information about the throughput and where is the limitation if it's from the host or from the design. Probably the simplest method to verify this is using USB analyzer. So as you can see on the picture if you can observe in communication trace NUX from the device speed is limited by the device because it's not able to answer on all the requests from the host side on time and need to not acknowledge time to time some of the requests which need to be repeated and that is limiting bandwidth at the end. On other hand if there are no NUX in the communication device is able to all the requests from the host on time so it's very probable that even more requests from the host side could be proceed by the device in the same time so now the button like is created by the host. As already mentioned virtual comport applications are not so convenient for throughput test as performance during testing with such software was never good on our side. We mostly use for this test the command line application so the direct console which is showing better performance mostly on the linux so here you can see the commands to work with the comport using either Windows or linux and the commands are for both directions so either in or out. To get directed to the results we were able to test in our testing project generated by Cubemix without no additional changes in libraries so both driver and middleware layer were not changed. For the test we used STM32F723 which already embeds USB high speed phi so it's the easiest solution for native USB high speed and we use CDC device application for the test. All of these tests were performed on the same PC with USB 3.0 as host root hub. In first test device speed in in direction so the data are sent to from the device to the host with default Windows 10 driver and common line application four megabytes per second were measured. With application created in the C sharp and various time driver on the PC side and in the microcontroller side like in previous case more than double was achieved so 8.75 megabyte per second so here we can see that even the command line is not so efficient but it's still easier than writing a dedicated application for testing in the C sharp. Using lip USB which already was mentioned and again the command line interface 6 megabyte per second was reached so that's again 15 percent increased to the measurement with the original Windows 10 USB C sharp. That's his driver but very best results were observed when Linux was used instead of Windows 10. Here the bandwidth using the command line commands mentioned in the previous slide raised up to 12.5 megabytes per second. So as was mentioned previous measurement were done without additional change in USB libraries or drivers and for more experienced users we have here some tips where to focus to improve the driver or the middleware for tuning the throughput inside of the STM32 project. Very first place where to go is the configuration of the FIFOs. So bigger the FIFO of the use endpoints the more space for the data and more time for the application to proceed so increase the FIFO space but the user still should be aware that the setting of the FIFO in the both registers and also our libraries is in terms of words instead of the blights which maybe could be expected so it's important to be careful to do not allocate the buffer outside of the FIFO or the bucket buffer. Second thing we need to focus is the interrupt so as the USB functionality is completely handled by interrupts inside the STM32 USB libraries we should prevent other long interrupts and high parity interrupts to get the most processing time to the application and the last and probably most demanding steps would be to improve the USB library by yourself so there is the possibility to change the library in the way how it's handling and checking the flags to reach exactly your application for example you can observe that the flag and function which is used most in your application is not the first which is checked in the interrupt so the order may be changed but this here you should be very careful to do not put there any miss functionality any bug and probably the performance gain which you can get using these changes won't be so crucial