{"id":2149,"date":"2016-11-09T10:28:54","date_gmt":"2016-11-09T18:28:54","guid":{"rendered":"http:\/\/visualgdb.com\/w\/?p=2149"},"modified":"2024-02-28T16:21:25","modified_gmt":"2024-02-29T00:21:25","slug":"optimizing-stm32-usb-performance-with-real-time-watch","status":"publish","type":"post","link":"https:\/\/visualgdb.com\/tutorials\/profiler\/realtime\/usb\/","title":{"rendered":"Optimizing STM32 USB performance with Real-time watch"},"content":{"rendered":"

This tutorial shows how to analyze and optimize the performance of a USB device based on the STM32 microcontroller using the VisualGDB real-time watch feature.<\/p>\n

We will create a basic firmware that receives the data over USB and sends it back in chunks, will measure the throughput and use the real-time watch to analyze what exactly happens on the device and how to improve the USB performance.<\/p>\n

Before you begin, install VisualGDB 5.2 or later.<\/p>\n

    \n
  1. Start Visual Studio and open the VisualGDB Embedded Project Wizard:\"01-prjname\"<\/a><\/li>\n
  2. Proceed with the default “Embedded binary” setting:\"02-binary\"<\/a><\/li>\n
  3. Select the ARM toolchain and choose your device. In this tutorial we will use the STM32F4Discovery board that has the STM32F407VG chip:\"03-device\"<\/a><\/li>\n
  4. On the Sample Selection page choose the “USB Communications Device” sample and press “Next”:\"04-usbcomm\"<\/a><\/li>\n
  5. Finally select your debugging method. The easiest way to get it to work is to select OpenOCD, plug in your board and click “Detect” to automatically detect the necessary settings:\"05-debug\"<\/a><\/li>\n
  6. Press “Finish” to generate your project. Then replace the loop inside main() with the following loop:\n
    \u00a0\u00a0\u00a0 char buffer[4096];\r\n\u00a0\u00a0 \u00a0for (;;)\r\n\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0int total = 0;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0while (total < sizeof(buffer))\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0int done = VCP_read(buffer + total, sizeof(buffer) - total);\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0total += done;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0}\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0if (VCP_write(buffer, total) != total)\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0asm(\"bkpt 255\");\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0}\r\n\u00a0\u00a0 \u00a0}<\/pre>\n
    This code will read data in 4KB chunks and immediately send it back. For simplicity we don’t apply any transformation to the received data and just send it back as is.<\/li>\n
  7. Before you can try out the code, go to the definition of VCP_write() and check that the loop at the beginning of it looks as shown below. If not, correct it:\n
    \u00a0\u00a0\u00a0 if (size > CDC_DATA_HS_OUT_PACKET_SIZE)\r\n\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0for (int offset = 0; offset < size; )\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0int todo = MIN(CDC_DATA_HS_OUT_PACKET_SIZE,\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0size - offset);\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0int done = VCP_write(((char *)pBuffer) + offset, todo);\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0if (done != todo)\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0return offset + done;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0offset += done;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0}\r\n\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0return size;\r\n\u00a0\u00a0 \u00a0}<\/pre>\n<\/li>\n
  8. Switch the configuration to ‘release’, build it and run with F5:\"07-main\"<\/a><\/li>\n
  9. Locate the USB device in the Device Manager and note its COM port number:\"devicemgr\"<\/a><\/li>\n
  10. We will use the following benchmark program to measure the USB performance. Build it in another Visual Studio instance and run it:\n
    using System;\r\nusing System.IO.Ports;\r\nusing System.Threading;\r\n\r\nnamespace USBBenchmark\r\n{\r\n\u00a0\u00a0\u00a0 class Program\r\n\u00a0\u00a0\u00a0 {\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 static void Main(string[] args)\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 {\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 SerialPort port = new SerialPort(\"COM6\");\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 port.Open();\r\n\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 var buf = new byte[65536];\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 for (int i = 0; i < buf.Length; i++)\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 buf[i] = (byte)i;\r\n\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 new Thread(() => ReadThread(port)).Start();\r\n\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 DateTime start = DateTime.Now;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 long bytesWritten = 0;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 for (;;)\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 {\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 port.Write(buf, 0, buf.Length);\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 bytesWritten += buf.Length;\r\n\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 double msec = (DateTime.Now - start).TotalMilliseconds;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 double bytesPerSecond = (bytesWritten * 1000) \/ msec;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 double kbPerSecond = bytesPerSecond \/ 1024;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Console.Write($\"\\rWritten: {bytesWritten \/ 1024}KB; time: {msec \/ 1000:f1} sec; Average speed: {kbPerSecond:f0} KB\/sec\");\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 }\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 }\r\n\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 static void ReadThread(SerialPort port)\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 {\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 var buf = new byte[65536];\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 for (;;)\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 {\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 int done = port.Read(buf, 0, buf.Length);\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 }\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 }\r\n\u00a0\u00a0\u00a0 }\r\n}<\/pre>\n<\/li>\n
  11. Note down the speed it shows. In this example we have measured 309 KB\/sec:\"08-benchmark\"<\/a><\/li>\n
  12. Now we will use the real-time watch to obtain some measurements and check for optimization possibilities. Before we do that, do a quick check that the oscillator speed specified in the HAL configuration file matches the one on your board. The easiest way to verify it is to insert the following loop in main()<\/strong> and check that the value of g_Counter<\/strong> increases exactly each second:\n
    \u00a0\u00a0\u00a0 for (;;)\r\n\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0HAL_Delay(1000);\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0g_Counter++;\r\n\u00a0\u00a0 \u00a0}<\/pre>\n<\/li>\n
  13. For STM32F4Discovery the default value in stm32f4x_hal_config.h<\/strong> is incorrect and the 1-second delay will actually take 3 seconds:\"09-speed\"<\/a><\/li>\n
  14. Adjust the value if needed (on STM32F4Discovery the HSE_VALUE should be set to 8 MHz):\"10-hse\"<\/a><\/li>\n
  15. Now we can finally take some measurements. Go to the Dynamic Analysis page of VisualGDB Project Properties and check the “Allow tracing function calls” checkbox:\"11-profiler\"<\/a>If you have not referenced the profiler framework before, click the “Add Reference Manually” link and build your project.<\/li>\n
  16. Run the project again and measure the speed. Instrumenting the functions slows them down, so the overall performance will reduce by around 10%. When you compare different measurements when instrumentation turned on, ensure you use the reduced value as your baseline:\"12-bench2\"<\/a><\/li>\n
  17. The first thing we will measure is the timing of VCP_read() and VCP_write(). Stop your program once the benchmark is running and, those functions to the real-time watch window and resume your program to collect some data. VisualGDB will show many calls to VCP_read()<\/strong> and a few calls to VCP_write()<\/strong> interrupted by profiling buffer overflows:\"14-overflows\"<\/a><\/li>\n
  18. The buffer overflows happen when too much real-time data is captured and the program needs to wait for VisualGDB to read it. Most of the time VCP_read()<\/strong> immediately returns 0, so it is generating huge amounts of real-time data and quickly fills the buffer. In order to get a precise picture of what is happening inside the loop we need to capture at least one one entire loop (i.e. the time between 2 calls to VCP_write()<\/strong>) without any buffer overflows. We can do this by either reducing the amount of measured data (e.g. by measuring some block inside VCP_read() that does not get invoked too often) or by simply increasing the buffer size. In this example we will use the second approach and increase the buffer size to 32KB:\"15-buffer\"<\/a><\/li>\n
  19. Build and run your program, start the benchmarking and put a breakpoint at the beginning of the loop. Then add VCP_read()<\/strong> and VCP_write()<\/strong> to real-time watch and enable the ‘stop on overflow’ option:\"16-autostop\"<\/a><\/li>\n
  20. Then resume your program and wait until it stops on an overflow event. Now we have enough data to see what is going on. It quickly becomes obvious from the graph that the VCP_write()<\/strong> function does not do any buffering and the next loop iteration does not start until the write() returns:\"17-reads\"<\/a><\/li>\n
  21. You could zoom in to see that most of the time VCP_read()<\/strong> returns immediately and sometimes it takes more time (when it has data to return):\"18-zoomread\"<\/a><\/li>\n
  22. The time between 2 calls to VCP_write()<\/strong> should be a good measure of how much time it takes to transfer 4 KB of data. In our example it was 14 msec that corresponds to 4K * 1000 \/ 14 = 285 KB\/sec that is 2% more than the average throughput measured before (slight variance in measurements is normal due to USB bus events):\"19-cycle\"<\/a><\/li>\n
  23. The easiest way to see what is happening on the USB bus is to modify the USB interrupt handler to generate custom events each time a ‘read complete’ or ‘write complete’ interrupt arrives:\n
    #include <CustomRealTimeWatches.h>\r\nEventStreamWatch g_IN, g_OUT;\r\n\r\nvoid OTG_FS_IRQHandler(void)\r\n{\r\n\u00a0\u00a0 \u00a0if (__HAL_PCD_GET_FLAG(&hpcd, USB_OTG_GINTSTS_IEPINT))\r\n\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0g_IN.ReportEvent(\"in\");\r\n\u00a0\u00a0 \u00a0}\r\n\u00a0\u00a0 \u00a0if (__HAL_PCD_GET_FLAG(&hpcd, USB_OTG_GINTSTS_OEPINT))\r\n\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0g_OUT.ReportEvent(\"out\");\r\n\u00a0\u00a0 \u00a0}\r\n\u00a0\u00a0 \u00a0\r\n\u00a0\u00a0 \u00a0HAL_PCD_IRQHandler(&hpcd);\r\n}<\/pre>\n<\/li>\n
  24. Build the new code and add g_IN<\/strong> and g_OUT<\/strong> to the real-time watches. This confirms that reading and writing does not happen in opening and suggests a way to optimize it:\"21-events\"<\/a><\/li>\n
  25. If you look into the VCP_write()<\/strong> function, you will see that it waits for the TxState<\/strong> field of the CDC state structure to be 0 before it returns. Quickly checking for references to TxState (write references are shown in read) shows that it’s assigned from the USB_CDC_DataIn()<\/strong> function that is called when a USB packet is successfully sent:\"22-datain\"<\/a><\/li>\n
  26. We will now modify the VCP_write()<\/strong> function to be asynchronous, i.e. to start a multi-packet transfer and return immediately.\u00a0 First of all, add a TxTotalRemainingLength field to USBD_CDC_HandleTypeDef:\n
    \u00a0\u00a0\u00a0 typedef struct\r\n\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0uint32_t data[CDC_DATA_HS_MAX_PACKET_SIZE \/ 4];\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0uint8_t\u00a0 CmdOpCode;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0uint8_t\u00a0 CmdLength;\u00a0\u00a0 \u00a0\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0uint8_t\u00a0 *RxBuffer; \u00a0\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0uint8_t\u00a0 *TxBuffer;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0uint32_t RxLength;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0uint32_t TxLength;\u00a0\u00a0 \u00a0\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0uint32_t TxTotalRemainingLength;\r\n\u00a0 \r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0__IO uint32_t TxState;\u00a0\u00a0\u00a0 \u00a0\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0__IO uint32_t RxState;\u00a0\u00a0 \u00a0\r\n\u00a0\u00a0 \u00a0}\r\n\u00a0\u00a0 \u00a0USBD_CDC_HandleTypeDef;<\/pre>\n
    Then change USBD_CDC_SetTxBuffer() as follows:<\/p>\n
    uint8_t\u00a0 USBD_CDC_SetTxBuffer(USBD_HandleTypeDef\u00a0\u00a0 *pdev,\r\n\u00a0\u00a0 \u00a0uint8_t\u00a0 *pbuff,\r\n\u00a0\u00a0 \u00a0int packet_length,\r\n\u00a0\u00a0 \u00a0int total_length)\r\n{\r\n\u00a0\u00a0 \u00a0USBD_CDC_HandleTypeDef\u00a0\u00a0 *hcdc = (USBD_CDC_HandleTypeDef*) pdev->pClassData;\r\n\u00a0 \r\n\u00a0\u00a0 \u00a0hcdc->TxBuffer = pbuff;\r\n\u00a0\u00a0 \u00a0hcdc->TxLength = MIN(packet_length, total_length);\r\n\u00a0\u00a0 \u00a0hcdc->TxTotalRemainingLength = total_length;\r\n\u00a0 \r\n\u00a0\u00a0 \u00a0return USBD_OK; \u00a0\r\n}<\/pre>\n
    Then update USBD_CDC_DataIn() to immediately start another packet it TxTotalRemainingLength is not 0:<\/p>\n
    static uint8_t\u00a0 USBD_CDC_DataIn(USBD_HandleTypeDef *pdev, uint8_t epnum)\r\n{\r\n\u00a0\u00a0 \u00a0USBD_CDC_HandleTypeDef\u00a0\u00a0 *hcdc = (USBD_CDC_HandleTypeDef*) pdev->pClassData;\r\n\u00a0 \r\n\u00a0\u00a0 \u00a0if (pdev->pClassData != NULL)\r\n\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0hcdc->TxTotalRemainingLength -= hcdc->TxLength;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0hcdc->TxBuffer += hcdc->TxLength;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0if (hcdc->TxTotalRemainingLength)\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0if (hcdc->TxLength > hcdc->TxTotalRemainingLength)\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0hcdc->TxLength = hcdc->TxTotalRemainingLength;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0hcdc->TxState = 2;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0if (USBD_CDC_TransmitPacket(pdev) != USBD_OK)\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0asm(\"bkpt 255\");\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0}\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0else\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0hcdc->TxState = 0;\r\n\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0return USBD_OK;\r\n\u00a0\u00a0 \u00a0}\r\n\u00a0\u00a0 \u00a0else\r\n\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0return USBD_FAIL;\r\n\u00a0\u00a0 \u00a0}\r\n}<\/pre>\n
    Finally rename VCP_write() to VCP_write_async() and change its contents as follows:<\/p>\n
    int VCP_write_async(const void *pBuffer, int size)\r\n{\r\n\u00a0\u00a0 \u00a0USBD_CDC_HandleTypeDef *pCDC = (USBD_CDC_HandleTypeDef *)USBD_Device.pClassData;\r\n\u00a0\u00a0 \u00a0while (pCDC->TxState) {} \/\/Wait for previous transfer\r\n\r\n\u00a0\u00a0 \u00a0USBD_CDC_SetTxBuffer(&USBD_Device, (uint8_t *)pBuffer, CDC_DATA_FS_OUT_PACKET_SIZE, size);\r\n\u00a0\u00a0 \u00a0if (USBD_CDC_TransmitPacket(&USBD_Device) != USBD_OK)\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0return 0;\r\n\r\n\u00a0\u00a0 \u00a0return size;\r\n}<\/pre>\n<\/li>\n
  27. Now we can change the loop inside main() to use 2 buffers: one for sending the previous data chunk and another one for receiving a new one:\n
        const int bufferSize = 4096;\r\n\u00a0\u00a0 \u00a0char buffer1[bufferSize], buffer2[bufferSize];\r\n\u00a0\u00a0 \u00a0for (int iter = 0;;iter++)\r\n\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0char *pBuffer = (iter % 2) ? buffer1 : buffer2;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0int total = 0;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0while (total < bufferSize)\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0int done = VCP_read(pBuffer + total, bufferSize - total);\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0total += done;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0}\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0if (VCP_write_async(pBuffer, total) != total)\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0asm(\"bkpt 255\");\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0}\r\n\u00a0\u00a0 \u00a0}<\/pre>\n<\/li>\n
  28. Run the updated program and get a measurement of one full cycle in real-time watch: \"23-cycle2\"<\/a><\/li>\n
  29. Reading and writing interrupts now overlap and the time between calls to VCP_write_async() was reduced to 11 msec that corresponds to 4K * 1000 \/ 11 = 363KB\/sec (~1.3x faster). Confirm this by pausing real-time watches and running the benchmark:\"24-speed2\"<\/a>Note that running the benchmark with real-time watches active will result in much slower speed as each time the real-time data buffer is filled, the program is delayed until it is read by VisualGDB.<\/li>\n
  30. Another observation clearly visible from the real-time watch window is that sending data to the computer (IN endpoint) takes less time than receiving it (OUT endpoint):\"25-imbalance\"<\/a><\/li>\n
  31. If you compare the reading and writing code, you will see that we are sending data in 512-byte packets and receiving it in 64-byte ones. 512-byte packets supported in the USB 2.0 High Speed (but not in Full Speed mode), and are causing strange timing side effects. Adjust the VCP_write_async()<\/strong> function to use the 64-byte packets (CDC_DATA_FS_OUT_PACKET_SIZE):\"26-fspacket\"<\/a><\/li>\n
  32. This balances reading and writing times and reduces the cycle time to ~8 msec:\"27-newcycle\"<\/a><\/li>\n
  33. Disable the function tracing on the Dynamic Analysis page to get the maximum possible speed and run the benchmark again:\"28-notrace\"<\/a><\/li>\n
  34. In our measurements parallelizing reading and writing and balancing the IN\/OUT packets raised the speed to 445 KB\/sec (1.44x):\"29-fastest\"<\/a><\/li>\n
  35. You can also quickly check how consistent is the transfer speed over time by adding a scalar real-time watch:\n
    int g_BytesTransferred;\r\nScalarRealTimeWatch g_BytesTransferredWatch;\r\n\r\nint main(void)\r\n{\r\n\u00a0\u00a0 \u00a0\/\/...\r\n\u00a0\u00a0 \u00a0\r\n\u00a0\u00a0 \u00a0const int bufferSize = 4096;\r\n\u00a0\u00a0 \u00a0char buffer1[bufferSize], buffer2[bufferSize];\r\n\u00a0\u00a0 \u00a0for (int iter = 0;;iter++)\r\n\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0int total = 0;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\/\/...\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0g_BytesTransferred += total;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0g_BytesTransferredWatch.ReportValue(g_BytesTransferred);\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\/\/...\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0\r\n\u00a0\u00a0 \u00a0}\r\n}<\/pre>\n<\/li>\n
  36. Adding g_BytesTransferredWatch<\/strong> to the real-time watch will show how quickly the amount of transferred data grows over time:\"linear\"<\/a>Measuring this will not introduce any significant slowdown as the real-time events will only be produced once per the 4KB block of data and VisualGDB will have plenty of time to process them without stopping your program.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
    This tutorial shows how to analyze and optimize the performance of a USB device based on the STM32 microcontroller using<\/p>\n","protected":false},"author":1,"featured_media":2207,"comment_status":"closed","ping_status":"closed","sticky":true,"template":"","format":"standard","meta":{"footnotes":""},"categories":[135],"tags":[109],"_links":{"self":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/2149"}],"collection":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/comments?post=2149"}],"version-history":[{"count":2,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/2149\/revisions"}],"predecessor-version":[{"id":2208,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/2149\/revisions\/2208"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/media\/2207"}],"wp:attachment":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/media?parent=2149"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/categories?post=2149"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/tags?post=2149"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}