STM32F103 and VCP_V1.3.1

[mfederici]

Posted on October 04, 2013 at 13:14

Hi all ! I did a device using the STM32f103, managed by a GUI from windows PC. I did my protocol and so on.   STM32, after any command, answers with an ACK. Then the PC sends the following command and so on. Now, doing a test about the communication speed, I noted that when the PC receives an ACK, waits about 15 ms, and then sends the following message. I did the GUI using VB. Than I tried to use the C++. the results is the same. Anytime Windows introduces this wait. Is this a  problem due by Windows or the VCP_V1.3.1 ?? There is possibility to send commands faster, with no waits ?  I am looking for the faster USB communications for STM32F103 ! Thanks for all !!

#usb-stm32 #vcp-stm32-usb

[Tesla DeLorean]

Posted on October 04, 2013 at 13:49

So are you sure the latency is in the send path?

[mfederici]

Posted on October 07, 2013 at 16:24 Hi Clive, thanks for your interest in my discussion 🙂  🙂 what do you mean with ''the send path?'' I tested it using free serial port monitor. Yes. it gives to me this latency time that I do not succes to understand... the protocol is so made: 1) I send a macro. 2) it stm32f103) soon answers giving an ACK (command received OK) [monitor says: time=0) 3) the stm32 executes the macro (it has a variable time: very short or very long. It depends by parameter attached to the macro) 4) as stm32 ends, it sends another ACK meaning it has finished the command 5) now, the pc should send soon another macro, but introduces this very annoying delay of about 15 ms. after this delay the PC finally send the following macro and so on. In short, STM32 seems to be very fast to receive and execute the commands, but since the PC involves a delay, the procedure is continuosly stopped and restarted... I tried using different PC, even if very fast (dual core, etc.). trying both a GUI done by visual basic and Csharp...the result is the the same...stop,go,stop,go,.... the funny matter is tat I tried also to drive two and three peripherals (STM32), each with its unique address, and the time is allways the same! thanks for your help.! M.

[Tesla DeLorean]

Posted on October 07, 2013 at 17:42

Sounds like you're asking the OS (WIN32) for too much data from the serial port, or have too large a receive timeout.

My point before was that the lag was not related to the ''Send Path'', the ability to send data too the device (outbound) both quickly and rapidly, and probably not the repressiveness to data once received by the application, but rather how you attempt to get data from the OS and it's buffering. ie in the ''Receive Path'' side of the communications from the PC perspective.