[STM32F769Discovery development board trial] USB-HS HID simple transmission and reception evaluation

donatello1996

[STM32F769Discovery development board trial] USB-HS HID simple transmission and reception evaluation [Copy link]

 

 

Most of the evaluation boards and third-party development boards of STM32 have USB interfaces. If the USB interface is configured as Device mode, it can communicate with the computer. Generally, Device mode is divided into protocols such as HID/CDC/DFU/MS/Audio. Among them, HID is a human body input device, CDC is a virtual serial port device, DFU is a firmware upgrade device, MS is a large-capacity storage device, and Audio is an audio communication device. HID is suitable for simple/low-speed transparent communication or virtual human body input devices such as mouse and keyboard. The length and characteristic value of each transparent field can be customized, and there is no need to parse each byte in the data packet; CDC is suitable for high-speed/large-flow transparent communication, and can communicate with the computer in the form of winusb. The characteristic value of the transparent field cannot be customized, and it can only be parsed byte by byte from a frame of data packet; DFU is only suitable for master code upgrade; MS is only suitable for virtualizing the master as a storage device such as a U disk; Audio is only suitable for virtualizing the master as a sound card device. In the application of data transparent transmission, the HID protocol is very similar to the CDC protocol.
The official steps for building the HID code routine are very simple. You only need to use CubeMX and configure the send field to complete it. Let's start step by step. However, USB communication requires a fixed 48MHz clock. For the official evaluation board or the third-party development board whose clock design refers to the official evaluation board, generally try to use the board-level initialization function of CubeMX (ie, Access to Board Selector):

The significance of not using the chip-level initialization function (Access to MCU Selector) is that the USB clock can be initialized correctly to avoid unnecessary trouble. Enter the CubeMX pin configuration interface, remove all unnecessary peripherals such as ETH I2S SAI QSPI FMC LTDC, and set USBHS (high-speed interface) to Device mode, external PHY, and SOF are not enabled:

Why is it an external PHY? It's very simple. You can tell by looking at the schematic diagram and the chip layout of the board:

The USBHS interface of the F769 main control board leads to the physical layer microUSB interface through a USB3320 USB-PHY chip.

Then for the configuration of the USB Device third-party peripherals, set the mode to Custom HID:

Finally, confirm that the USB clock frequency is 48MHz and then generate the project:

After the project is generated, according to the official USBHID document guidance provided by ST, you need to replace the CUSTOM_HID_ReportDesc_HS enumeration array under the usbd_custom_hid_if.c file:

#define REPORT_INPUT_LEN              64

__ALIGN_BEGIN static uint8_t CUSTOM_HID_ReportDesc_HS[USBD_CUSTOM_HID_REPORT_DESC_SIZE] __ALIGN_END =
{
0x06,0xA0,0xFF,//用法页(FFA0h, vendor defined)
0x09, 0x01,//用法(vendor defined)
0xA1, 0x01,//集合(Application)
0x09, 0x02 ,//用法(vendor defined)
0xA1, 0x00,//集合(Physical)
0x06,0xA1,0xFF,//用法页(vendor defined)
	
//输入报告
0x09, 0x03 ,//用法(vendor defined)
0x09, 0x04,//用法(vendor defined)
0x15, 0x80,//逻辑最小值(0x80 or -128)
0x25, 0x7F,//逻辑最大值(0x7F or 127)
0x35, 0x00,//物理最小值(0)
0x45, 0xFF,//物理最大值(255)
0x75, 0x08,//报告长度Report size (8位)
0x95, REPORT_INPUT_LEN,
//报告数值
0x81, 0x02,
//输入(data, variable, absolute)

//输出报告
0x09, 0x05,
//用法(vendor defined)
0x09, 0x06,
//用法(vendor defined)
0x15, 0x80,
//逻辑最小值(0x80 or -128)
0x25, 0x7F,
//逻辑最大值(0x7F or 127)
0x35, 0x00,
//物理最小值(0)
0x45, 0xFF,
//物理最大值(255)
0x75, 0x08,
//报告长度(8位)
0x95, 0x40,
//报告数值(64 fields)
0x91, 0x02,
//输出(data, variable, absolute)
0xC0,
//集合结束(Physical)
0xC0
//集合结束(Application)  

};

This array will be initialized by the function set USBD_CustomHID_fops_HS call:

USBD_CUSTOM_HID_ItfTypeDef USBD_CustomHID_fops_HS =
{
  CUSTOM_HID_ReportDesc_HS,
  CUSTOM_HID_Init_HS,
  CUSTOM_HID_DeInit_HS,
  CUSTOM_HID_OutEvent_HS
};

Then modify USBD_CUSTOM_HID_REPORT_DESC_SIZE in usbd_conf.h and fill it with 52, which is the length of the array just now:

Add a callback function, this step is essential:

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
    HAL_IncTick();
}

After the above code is modified, you can use USBD_CUSTOM_HID_SendReport(&hUsbDeviceHS,buf,sizeof(buf)); function to send USBHID. The unit sent each time the function is called is 64 bytes, which is fixed:

Of course, in order to facilitate system and HID software identification, it is necessary to modify parameters such as VID PID device name:

#define USBD_VID     			1155
#define USBD_PID_HS     			22352
#define USBD_LANGID_STRING     		1033
#define USBD_MANUFACTURER_STRING     	"STMicroelectronics"


#define USBD_PRODUCT_STRING_HS     	"donatello1996 STM32F769 USBHID Device"
#define USBD_CONFIGURATION_STRING_HS  	"Custom HID Config"
#define USBD_INTERFACE_STRING_HS     	"Custom HID Interface"

Finally, use an oscilloscope to capture the time taken by the sending function:

	while(1)
	{
		GPIOJ->BSRR |= 0x00000002;
		USBD_CUSTOM_HID_SendReport(&hUsbDeviceHS,buf,sizeof(buf));
		GPIOJ->BSRR |= 0x00020000;
		USBD_CUSTOM_HID_SendReport(&hUsbDeviceHS,buf,sizeof(buf));
	}

It can be seen that even in the low-speed mode of HID, the sending interval is reduced to an incredible 500ns, that is, 128 bytes can be sent in 1us, and 128MB can be sent in 1s, which is definitely enough for most projects. If the high-speed CDC mode is used, it will be even faster, and sending hundreds of MB in 1s is no problem.

donatello1996

Upload project files

cruelfox

That's nonsense. You are only using an oscilloscope to determine the interval time of the call USBD_CUSTOM_HID_SendReport(&hUsbDeviceHS,buf,sizeof(buf));

The clock of USB HS interface ULPI is only 60MHz, so it is impossible to have a receiving and sending speed exceeding 60MB/s.

donatello1996

cruelfox posted on 2020-8-4 17:49 That's nonsense. You are just judging by using an oscilloscope. USBD_CUSTOM_HID_SendReport(&hUsbDeviceHS,buf,sizeof(buf)); This...

What is the relationship between the 60MHz clock and the data rate of 128MB/s that can be sent? 60MHz is just the frequency of the USB clock level. The clock can flip 60M times in one second. As long as the CPU sends a 64-byte data packet to the USBHS buffer when the clock flips once, it means that the transmission is successful. Whether the receiving end can receive these data packets normally and accurately has nothing to do with the sending end?

cruelfox

donatello1996 posted on 2020-8-4 18:13 What does a 60MHz clock have to do with the data rate of 128MB/s that can be sent? 60MHz is just the frequency of the USB clock level. The clock can...

Your function just returns, and the data is not sent out.

The HID message is of Interrupt Transfer type, and data can only be sent when the host is polling.

This is not SPI... Even 480Mbps SPI can only transfer 60MB/s at most.

donatello1996

cruelfox posted on 2020-8-4 21:28 Yours is just a function return, the data is not sent out. The HID message is of Interrupt Transfer type, only the host polling...

Whether the data is successfully sent out needs to be received and counted by the computer host computer, which is not a problem that the STM32 needs to worry about. Regardless of how long the polling interval is, the amount of data successfully sent has nothing to do with the 60MHz clock.

cruelfox

donatello1996 Published on 2020-8-5 09:58 Whether the data is successfully sent out requires the computer host to receive and count it. This is not a problem that STM32 needs to worry about. Let’s not talk about polling first...

Yes, what you think of as "successful transmission" has nothing to do with this, and it doesn't matter whether the USB module exists or not. As long as the function is not stuck there, it is successful.

littleshrimp

Judging from the parameters of USB2.0 alone, the maximum speed is 480Mbps, and even if the maximum speed of the protocol is not considered, it will not exceed 60MB/S.

If you look at the USB3320 data sheet, the maximum clock is 60MHz. The bus width between it and STM32 is only 1byte, so the maximum communication rate between it and STM32 will not exceed 60MHz.

donatello1996

littleshrimp posted on 2020-8-6 17:37 Just looking at the parameters of USB2.0, the maximum rate of 480Mbps will not exceed 60MB/S even if the protocol is not considered. If you look at the data sheet of USB3320, the maximum rate...

Pictures speak louder than words, very convincing, thumbs up! Since the official manual says that it will not exceed 60MB/s, then it will definitely not exceed that, but I have to write a host computer to verify the specific value, this point must be realistic. The point of my argument with the person above is that the USB clock and the amount of data sent per second should not be discussed together. I think these are two completely different concepts. The amount of data sent is slightly related to the USB clock, but it is definitely not a simple 1-to-1 relationship. The USB controller of the F769 master obtains the working clock from the USB clock source and sends a frame of data from the buffer within the specified period. So the specific amount of data sent in one second is related to the size of a frame of data and the clock cycle occupied. This is a binary relationship, not a simple 1-to-1 relationship.

littleshrimp

donatello1996 posted on 2020-8-6 18:38 The picture speaks for itself, it is convincing, thumbs up! Since the official manual says it will not exceed 60MB/s, then it will definitely not exceed that, but how much should it be...

USBD_CUSTOM_HID_SendReport function has return value

Try it and check if the return value is USBD_OK before operating GPIO

Measure the waveform to see what the interval is.

freebsder

It's interesting to dig deeper.

donatello1996

littleshrimp posted on 2020-8-6 19:54 The USBD_CUSTOM_HID_SendReport function has a return value. Try it. When the return value is USBD_OK, operate GPIO and measure the wave...

OK, I'll try it out this week. I'd also like to know how the USBHID performance of F769 works.

donatello1996

freebsder posted on 2020-8-6 22:02 It’s quite interesting to dig deeper.

The Taoist priest laughed

Bubb1e

The blogger still doesn't know much about the USB related content of stm32.

Bubb1e

donatello1996 posted on 2020-8-6 18:38 The picture speaks for itself, it is convincing, thumbs up! Since the official manual says it will not exceed 60MB/s, then it will definitely not exceed that, but how much should it be...

The amount of data sent is closely related to the clock frequency, which determines the flip frequency of your IO port.

Bubb1e

donatello1996 posted on 2020-8-4 18:13 What does a 60MHz clock have to do with the data rate of 128MB/s that can be sent? 60MHz is just the frequency of the USB clock level. The clock can...

So how do you write 64 bytes of data when the clock flips once? Does the data bus of stm32 have a bit width of 64 bytes?