Usb serial standard

Feedback will be sent to Microsoft: By pressing the submit button, your feedback will be used to improve Microsoft products and services. Privacy policy. This section provides information about device, configuration, interface, and endpoint descriptors and ways to retrieve them from a USB device.

The host software obtains descriptors from an attached device by sending various standard control requests to the default endpoint Get Descriptor requests, see USB specification section 9.

Those requests specify the type of descriptor to retrieve. In response to such requests, the device sends descriptors that include information about the device, its configurations, interfaces and the related endpoints.

Device descriptors contain information about the whole device. Configuration descriptors contain information about each device configuration. String descriptors contain Unicode text strings. Each configuration exposes it's configuration descriptor that indicates number of interfaces and power characteristics. Each interface exposes an interface descriptor for each of its alternate settings that contains information about the class and the number of endpoints.

Each endpoint within each interface exposes endpoint descriptors that indicate the endpoint type and the maximum packet size.

At device level, the device exposes a device descriptor and an endpoint descriptor for the default endpoint. At configuration level, the device exposes a configuration descriptor for Configuration 0. At interface level, it exposes one interface descriptor for Alternate Setting 0. At the endpoint level, it exposes three endpoint descriptors.

Every Universal Serial Bus USB device must be able to provide a single device descriptor that contains relevant information about the device. Windows uses that information to derive various sets of information.

For example, the idVendor and idProduct fields specify vendor and product identifiers, respectively. Windows uses those field values to construct a hardware ID for the device. To achieve this, when a device is attached to the bus it is assigned a unique number or address by the host for the time it is connected. In addition to the address, the device also contains endpoints.

These are the actual sources and destinations for communications between the host and the device. Endpoints can only operate in one direction, i. Although each device can have sixteen input and sixteen output endpoints, it is very rare for them all to be used.

The zero endpoints are used for a variety of activities including auto-detection and configuration of the device on the bus and the two zero endpoints are the only ones accessible until the device is properly connected on the bus.

The communication within USB is based around the concept of using data pipes. These can be considered as being logical channels within the data flow on the bus. In reality, a USB data pipe is a connection from the host controller to a logical entity within a device, i. Because pipes correspond to endpoints, the terms are sometimes used interchangeably.

The host then uses the concept of a data pipe to ensure the data to and from a device is correctly directed or the source is known. The data pipe uses a combination of the address, endpoint and also the direction to define it. To communicate with the zero endpoints a special form of data pipe is needed because it needs to be used to establish the initial communication. It is called the Default Control Pipe and it can be used when the initial physical connection is made. For USB 1 and 2 a four wire system is employed.

As detailed elsewhere, the cables carry: power, ground and then there is a twisted pair for the differential data transfer. For USB 3, new lines were introduced. The use of twisted pairs and differential signalling reduces the effects of external interference that may picked up.

It also reduces the effect of any hum loops, etc that could cause issues. The kit is the most suitable to study USB samples included in this documentation set. Introduces you to USB driver development. Provides information about choosing the most appropriate model for providing a USB driver for your device. Getting started with USB client driver development. USB device driver programming reference. If you are developing an xHCI host controller that is not compliant with the specification or developing a custom non-xHCI hardware such as a virtual host controller , you can write a host controller driver that communicates with UCX.

For example, consider a wireless dock that supports USB devices. Developing Windows drivers for USB host controllers. You can develop a controller driver that handles all USB data transfers and commands sent by the host to the device. Developing Windows drivers for USB function controllers. You can write a driver for the connector that communicates with the Microsoft-provided class extension module: UcmCx to handle scenarios related to Type-C connectors such as, which ports support Type-C, which ports support power delivery.

Windows includes in-box client drivers for ChipIdea and Synopsys controllers. For other controllers, Microsoft provides a set of programming interfaces that allow the dual-role class extension UrsCx and its client driver to communicate with each other to handle the role-switching capability of a dual-role controller.

To configure power management features of Usbser. AddReg section. Describe the registry entry in an extended properties OS feature descriptor. Set the bPropertyData field to "0x" or "0x". The property values are stored as little-endian bit integers. For more information, see Microsoft OS Descriptors. If you install Usbser. Starting in Windows 10, a Windows app can send requests to Usbser. SerialCommunication namespace.

The classes provide functionality to discover such serial device, read and write data, and control serial-specific properties for flow control, such as setting baud rate, signal states. For more information, see:. Configuring a Communications Resource.