Details: http://bbs.21ic.com/forum.php?mod=viewthread&tid=109584
USB 1.0 up to 12Mbps.
USB 2.0 High Speed mode 480Mbps, full speed mode 12Mbps, Low speed mode 1.5Mbps
Instead, set the baud rate of the Usart on the STM32 side. The transmission speed of PC and STM32 is transmitted at the theoretical speed of USB1.1, and it cannot be set.
Receiving the data, the nak-> copies the buffer data to the user area (user process), and the ACK notifies the host that the complete receive can be sent next to the host to send the next.
The day before yesterday to test their own written USB driver found from the host to the STM32 out transfer (host to device) rate is only the highest 33kb/s, it is dizzy dead. After study, it was found that
The relationship of pipe maxtransfersize parameters set in the driver, originally set 64 can 33kb/s, after reference other USB device driver value, set to 65535, and then test the speed of USB out, reached the 500kb/s, finally solved the bottleneck of the driver. But calculate the USB 2.0 full speed communication rate is 12mb/s, eliminate the CRC, tokens, SOF and so on how to spend more than the maximum 500kb/s ah. To see the internet, basically should be able to reach more than 600kb/s~700kb/s, I now the speed should still have a lot of promotion is.
Look at the program and find
void Ep3_out_callback (void)//ep3 out callback function that is called when EP3 receives data
{
Count_out = Geteprxcount (ENDP3);//Get the received data length
Pmatouserbuffercopy (Buffer_out, endp3_rxaddr, count_out);//copy data from the buffer of USB EP3 Rx to the user-specified array
Seteprxvalid (ENDP3); After the copy is completed, the EP3 sends the ACK host to send the next packet.
}
Try to pmatouserbuffercopy this sentence out (so that STM32 do not process the received data) and then test the speed, surprised to find that the speed has reached the 997kb/s! In the evening, think carefully, the data must be used, the process of the data copy of the time consumption is always unavoidable; because the USB device bulk data is usually received in the following steps: Receive data,
nak-> The buffer data is copied to the user area (user processing), the ACK notification host completes the complete receive can send the next host to send the next, follow the steps above USB receive step by step, as long as the STM32 does not complete data processing, The state is always a nak, the host will continue to send the packet, wasting bandwidth,So it will lead to my maximum speed 500kb/s difficult to increase the situation! Unwilling to heart AH ~ ~
Last night, we carefully studied the USB section of STM32 's Technical Reference manual, which mentions that bulk can be processed using a double-buffering mechanism (ping-pong), which solves the above situation. The principle of double buffering mechanism is to allocate 2 block receive buffer, STM32 user processing and USB interface can alternately occupy 2 buffers, when the USB endpoint receives data to write one of the buffers, the user's application can process another buffer, so that the buffer in turn to exchange the occupants, As long as the user handler completes processing in the time fragment received by the USB endpoint, it will not affect the speed of the USB communication at all!
Program Partial modification
First, the Ep3_out setting changes,
ZYP: Modify the EP3 to bulk double buffering mode-------------------------
Seteptype (ENDP3, Ep_bulk);
Setepdoublebuff (ENDP3);
Setepdblbuffaddr (ENDP3, endp3_buf0addr, endp3_buf1addr);
Setepdblbuffcount (ENDP3, Ep_dbuf_out, virtual_com_port_data_size);
Cleardtog_rx (ENDP3);
Cleardtog_tx (ENDP3);
Toggledtog_tx (ENDP3);
Seteprxstatus (ENDP3, ep_rx_valid);
Seteptxstatus (ENDP3, Ep_tx_dis);
//------------------------------------------------------
Second, the modification of Ep3_out callback function
void Ep3_out_callback (void)
{
ZYP: The following is a handler function modified to EP3 double-buffered out
if (Getendpoint (ENDP3) & EP_DTOG_TX)//first determine which buffer the data received is placed in
{
Freeuserbuffer (ENDP3, ep_dbuf_out);//Release the user's possession of the buffer first, so that the next receiving process of USB can be done immediately, with another buffer, while the user in parallel processing, before another piece received, processing the user data on the line, or buffer competition.
Count_out = Getepdblbuf0count (ENDP3);//reads the number of bytes received,
Pmatouserbuffercopy (Buffer_out,
endp3_buf0addr, count_out);
}
Else
{
Freeuserbuffer (ENDP3, ep_dbuf_out);
Count_out = Getepdblbuf1count (ENDP3);
Pmatouserbuffercopy (Buffer_out,
endp3_buf1addr, count_out);
}
}
After the above modification, finally solved the STM32 in processing received data caused by the host waiting for the situation, with the bus hound software test the next PS: the aboveFreeuserbuffer(ENDP3, ep_dbuf_out); The upper and lower position of this sentence is the key, if put in the back of the function, there will still be a host waiting for STM32 processing data, the speed is still 500kb/s!
Put this sentence in front of the copy function, you really put the double buffering ping-pong mechanism used up. Roughly forget the next pmatouserbuffercopy (Buffer_out, endp3_buf1addr, count_out); When Count_out is the maximum value of 64 STM32 execution takes 302 cycles, In the case of 72MHZ, approximately 4.2 microseconds of execution time, while USB transmissions transmit 64 bytes of data at 12mb/s wire speed at least 40 microseconds, so as long as the pmatouserbuffercopy time does not exceed 40 microseconds, there is no case of buffer contention.
STM32 Bulk Double buffered transfer speed discussion, hardware pits never fill out
