Stm32 Virtual COM Port Driver Windows 103/31/2024 Yes, but that ACK is *not* a high-level ACK from the usbser.sys. Sven Köhler wrote: If you study 'USB in a Nutshell' you will see that every bulk transfer data packet has to be acknowledged by the PC. My python test script verifies the integrity of those strings (is the string of the format above? does it contains the specified amount of characters?). Where x and y are random integers and x*y stands for x copies of character y, and x is in the range while y is in the range. The microcontroller is sending strings of the following format: 'x y x*y\n' To summarize: It is well known that virtual COM ports are not only faster but also they don't come with those old-school problems like data corruption and buffer overflows. So data corruption is extremely unlikely to go unnoticed. If you study 'USB in a Nutshell' you will see that every bulk transfer data packet has to be acknowledged by the PC. The buffers in the ST VCom (which is really just using Microsoft's usbserial.sys) will never overflow because flow control means that the microcontroller can only send data if the PC can accept them. Depending on how large a buffer the ST VCom driver has (or the python COM port library), you could easily overflow that if the python script stops reading from the serial port for 100ms.įor Bulk transfers, which is what virtual COM ports use for the actual data, the USB standard will give you something called flow control. If your code on the ST CPU is sending data as fast as the USBD_CDC functions will transmit it, you are effectively sending data at close to 10MBits/sec (12MBits/sec minus a wild guess for USB protocol overhead), or however fast the firmware can stuff data into the USB. If you configure the virtual serial port for, say, 9600 baud, that has no affect on how fast data is transferred across the USB. When you run a USB device as a CDC peripheral, there is NO data rate throttling across the USB bus. Unless of course you specifically seen your embedded code dropping data. If so, the most likely issue is the buffering on the PC side of things. I would guess that what you are seeing is missing data. When you randomly delay the python code, what is 'inconsistent' about the data that the python script sees? Is it seeing dropped or missing data? Corrupted data? I think you are looking in the wrong place. Is there ChaneLog for the STM32L4 packages, so I can study what was changed between 1.8.1 and 1.12.0? The same issue was reported here recently by another person. I switched a test project to 1.12.0, but then the virtual COM port won't work on Windows anymore. My project, unfortunately, is still based on STM32L4 package version 1.8.1. There should not be any data loss here.Ĭan somebody point me to the location in the CubeMX's USB code that handles the re-transmission of bulk data? I can't seem to find it. However, when the PC does not send an ACK in response to a bulk data packet, then the USB peripheral must re-transmit the data when the host asks for the next data packet.Īnyhow, USB has built-in flow control. The obvious conclusion seems to be, that the USB driver code doesn't re-transmit data. In that case, the microcontroller sends faster than the PC is reading the data. However, if the python script sleeps randomly (with 5% probability) for 100ms before reading a line, then data is inconsistent. Turns out, that if the python script reads fast enough, data is consistent. On the PC (Windows), a python script reads the data, line by line, and checks the links for consistency. The data sent is a randomly generated string, which includes a terminating newline character.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |