HID firmware modification (hidtouartexample)

1. Modification of descriptors:

1.1 Configuration Descriptor Modification:

Modifies the size of the HID report Descriptor's bytes in the HID descriptor under the configuration descriptor. Modify the value to the number of bytes written by the HID report descriptor.

1.2 Specifies the endpoint, type (input, output), and data length of the endpoint used in the endpoint descriptor under the configuration descriptor.

1.3 Define your own reports in the HID report descriptor (difficult)

In the example above, the input report (device sending data to PC) and output report (PC sending data to device) are defined separately.

The Report_count entry for each report defines how much data is included in each report (up to a maximum of 64 Byte,report IDs per report, which cannot exceed the 63,hid protocol, so the maximum value is 63).

The report size item definition for each of the reports, the number of significant digits for each data in the report, if in bytes, the value should be 8.

2. Data sending and receiving

2.1 Data Processing Modification Local summary

Each MCU has its own USB processing example, the underlying USB ISE settings, each interrupt control has provided related processing functions, so do not have to delve into the underlying USB control. Just find the data to send, receive the related upper function, and make corresponding changes inside it. In the Silicon F340 Hidtouart example, the HID data is sent and received in a reporthandler.c file.

2.2 Modifying the local detail description

In the HID example, the data send and receive is done by calling the report handler function of the input instance object (in_vectortable) and Output instance object (out_vectortable) of the vectortableentry struct.

The function that calls the struct object is in the F3xx_usb0_reporthandler.c file.

void Reporthandler_in_isr (unsigned charr_id)

void Reporthandler_out (unsigned charr_id)

Completed in two functions

These two functions are called by the underlying function in the usb0_interruptserviceroutione.c file to see how the chip USB works to analyze the function workflow in this file.

The above Voidreporthandler_in_isr (unsigned char r_id) and voidreporthandler_out (unsigned char r_id) Two functions do not need to be modified to parse the contents of their internal functions visible, These two functions are sent and received by ReportID and then calling the corresponding upper report handler function. In this example, the Silicon Engineer uses a custom struct (vectortableentry) to associate the ReportID with the report handler function.

In_vectortable and out_vectortable are vectortableentry structure arrays, and the number of arrays corresponds to the number of the report defined by the report descriptor. The in_vectortablesize and out_vectortablesize macro definitions correspond to them.

The image example has been modified by myself, and the input and output of the original example are more than one control report ID and handler function.

As mentioned above, the bottom how to work and call the related functions we can not scrutiny, mainly find the data input, output processing function, in this case the input function is in_data, the output function is out_data. (The method of finding is as above analyzed)

In the Silicon lab example, the change in the F3xx_usb0_reporthandler.c file is:

void In_data (void)

void Out_data (void)

Two functions, the two functions are processing the data to be sent and the data received.

I modified the following functions as follows:

Compare the original examples to understand deeper understanding.

Note that Out_data is not a data-sending function, and in_data is not a data-receiving function. In the application we have to send the data in the corresponding location according to our own requirements and to deal with the received data.

Generally speaking, the data received in the lower computer does not have a separate function, which is determined by the USB transmission mode, the USB read and write is initiated by the host, the slave is only the answer, so the next computer to receive data, by the underlying hardware Ise automatic completion, and then generate interrupts, The USB interrupt handler in the General sample program takes the data out and places it in the corresponding receive buffer, as in this example, out_packet in the Out_data function. So the main is to find the interrupt processing received the data placed in buffer and the buffer processing function (such as Out_packet), and then docking to receive the data on their own request processing and the main function can be linked.

The data sent by the lower computer will usually have a separate function, and the corresponding data buffer is sent. In this case, the Sendpacket function. Follow the example description to read the sample program carefully, looking for data sending function is not difficult. In this example, you can compare the original example to deepen your understanding as shown below.

In the Hidtouart example, the const vectortableentryin_vectortable[in_vectortablesize] in F3XX_USB0_REPORTHANDLER.C is also modified to In_ Vectortablesize changed from 2 to 1, that is, send and receive each as long as a report, the previous example sent and received respectively control and data two report.

3. In the case of continuous read and write, after removing the UART portion of the example, the interrupt Processing section also changes one place:

When the data to be read is removed, the flag is zeroed out.

4. Changes to transfer buffer size:

In addition to modifying the buffer size in the descriptor definition contained in 1, be aware that the buffer size is changed in both functions under the Reporthandler.c file.

5. Modification of PID & vid