Now we need a few descriptors
Since the control endpoint has been successfully initialized, this section will deal with the structure and definition of the standard descriptors.
Last updated
Since the control endpoint has been successfully initialized, this section will deal with the structure and definition of the standard descriptors.
Last updated
This part of the tutorial only deals with the standard descriptors, i.e. the device, configuration, interface and endpoint descriptor, so that the host gets a rough picture of the connected USB device. The class-specific descriptors follow in a later part and allow the host to round off the rough picture of the connected USB device and finally load the appropriate driver for the device. But first we need to understand how a descriptor is structured and how we can communicate with the host.
Each USB-enabled device must have at least one device and at least one complete configuration descriptor. The configuration descriptor is further subdivided into the configuration descriptor itself, at least one interface descriptor and at least one end point descriptor. The software must therefore contain the following descriptors:
Device descriptor
Configuration descriptor
Interface descriptor
Endpoint descriptor
The descriptors all have a fixed structure, which is described in Chapter 9.6 of the USB specification.
Let's take a look at how the individual descriptors are structured ...
The device descriptor is always the first descriptor requested by the host as soon as the USB device is connected to the bus. It has the task of providing the host with general information about the connected device. Each USB-enabled device has a control endpoint, the size of which is described in the device descriptor. The host must know this size early enough so that communication with the device can run without errors. Each USB-capable device may only have one device descriptor and it should be described by the following structure:
The addition __attribute__ ((packed)) instructs the compiler to reserve only the memory that is actually required and not to insert any padding bytes. In this way, the data sent by the host can be copied into the memory to cast them into a corresponding structure variable.
Now we need a variable for the device descriptor:
With the help of the PROGMEM attribute, the descriptor is not copied from the flash to the SRAM by the startup code when the program is started.
As a consequence, the data must be read directly from the program memory, which means that other assembler instructions must be used.
The PROGMEM attribute is not neccessary needed for the function of the USB driver. Rather, it represents an optimization that ensures that large data structures are not copied into the SRAM. Ideally, large data structures (such as bitmaps for displays) or constant strings are declared via PROGMEM to save SRAM and to shorten the start time of the program.
The initialized device descriptor must now be fed with some values:
I have entered the individual constants, definitions and macros of the standard descriptors in a corresponding include file so that the entered values are easier to understand. Since this descriptor is not yet a complete mouse, but an example descriptor, the class Vendor, i.e. manufacturer-specific, is entered as the device class. The vendor and product ID can be freely selected if it is not a commercial product. However, you should be careful that other devices do not already use the same id, otherwise there may be problems with the drivers.
The other descriptors are created in the same way as the device descriptor ...
When requesting the configuration descriptor, in addition to the configuration descriptor, the interface descriptors and endpoint descriptors are also transmitted. Therefore, the individual descriptors are used as members for a new configuration structure, which represents an individual configuration of the device:
Then the descriptors are filled with some data:
With these descriptors, too, I had the individual fields filled with macros or corresponding constants.
The descriptors are test descriptors to practice communication between the host and the microcontroller. It is not yet a final mouse descriptor or something else because some fields have to be filled in differently. This information will be added later to update the descriptors.
Finally, a few optional string descriptors were declared:
String descriptors store a zero-terminated string in UNICODE format. Therefore, an wider character (w_char_t) is used as the data type for the string.
This is 16 bits on an AVR and can therefore ideally store a single UNICODE character.
Unlike the previous descriptors, the string descriptors are only filled with a string. The conversion of a character string into a corresponding descriptor is carried out via macros:
A special string descriptor is the descriptor with the id 0:
This string returns at least one language id. Using the available language IDs, the application on the host can determine the supported languages and thus read the corresponding descriptors. The macro CONV_LANG converts a primary language and a sub language into the corresponding language ID and transfers this language as an array to the macro LANG_TO_STRING_DESCRIPTOR, which then generates the string descriptor with the id 0.