Introduction - University of Washington



Universal Serial BusMotivationEmerged as result of difficulties associated withCost configuration attachment Peripheral devices to personal computerCreates method of attaching and accessing devicesReduces costSimplifies attachment and configurationFrom end user perspectiveSolves several technical issuesAssociated with old style peripheralsI/O LegacyPeripherals typically Mapped into CPU’s I/O address spaceAssigned specific IRQ lineSome cases DMA channelSuch scheme consumes many I/O resourcesInterruptsMost critical issue centered aroundAllocation of interruptsExacerbated on ISA bus based devicesDo not reliably support sharable interruptsShortage of interrupts had become major problemI/O AddressesI/O address conflicts Quite common in PC environmentAttachmentNo hot attachment of peripheralsConsider booting without a mouse attachedMost peripheral devices not usable without rebooting systemSystem software must Detect deviceLoad necessary driversCostCost of implementing I/O systems based upon legacy technologyFairly highCablesAssociated connectorsPotential need for expansion cardsNew SolutionGoalsShould overcome existing shortcomingsProvide room for growth and expansionNeedsSingle connector typeAbility to attach many peripherals to same connectorMethod to ease resource conflictsAutomatic detection and configuration of peripheral devicesLow cost for system and peripheral implementersEnhanced performance capabilitySupport for attaching new peripheralsSupport for legacy software and hardwareLow power implementation - support for green systemsUSB ApproachI/O resource limitations no longer existEach device residing on USB is assigned an address known only to USB subsystemDoes not consume any system resourcesUSB supports up to 127 addressesDoes pose limitation on number of addresses in single installationEach USB device supports number of ports called endpointsCan be accessed indirectlyOverviewTypical systemUSB host controllerResides on PCI busFetches transaction list that describes USB transactionsScheduled by systemFor delivery over USBExecutes transaction list by performing each transaction in listAll USB transactions initiated by USB softwareTypically originate in USB device driverThat wishes to communicate with its associated deviceUSB driver provides interface between USB device driver - on peripheral deviceUSB host controller - typically in PC Software is responsible for translatingClient requests Into transactionsDirected to or from target USB devicePrimary ComponentsHardwareHost controller / Root HubHubsDevicesSoftwareUSB Device driversUSB DriverController Driver1011555201930Host SystemClient SoftwareUSB System SoftwareUSB Host Controller / HUBUSB DeviceFunctionUSB Logical DevicesUSB Bus InterfaceUSB DriverUSB Device Driver1 ms packets00Host SystemClient SoftwareUSB System SoftwareUSB Host Controller / HUBUSB DeviceFunctionUSB Logical DevicesUSB Bus InterfaceUSB DriverUSB Device Driver1 ms packetsUSB Device Drivers - Host Side - Client SoftwareThese are the client drivers Located on host sideTop boxThey issue requests to USB driverSecond boxUse IRP - Interrupt Request PacketsInitiate transfer to or from target USB deviceExampleUSB keyboard driverMust initiate interrupt transferEstablishing an IRPSupplying memory buffer into which data will be transferredBy USB keyboardNote: Client driver has no knowledge of USB serial transfer mechanismsAll transactions transpire through lower level software packagesExactly what we wantUSB Driver - Host Side - Client DriverSecond box USB system softwareUSB driver knows Characteristics of USB target deviceHow to communicate with device via USBUSB CharacteristicsDetected by driver when it parses device descriptorsDone during device configurationAt power up When new device added to systemExamplesAmount of bandwidth necessary during transfer of each frameService only during nth frameWhen IRP received by USB client driver - on host side USB driver organizes request into individual transactionsExecuted during series of 1 ms framesDriver sets up transactions based upon knowledge of USB device requirementsNeeds of client driverLimitations / capabilities of USBUSB driver may be Shipped with operating systemAdded as extension via loadable device driverUSB Host Controller Driver - Host Side - Client DriverSecond box USB system softwareHost Controller Driver - HCDSchedules transactionsTo be broadcast over USBScheduled by host controller driverBuilding series of transaction listsEach listConsists of pending transactionsTargeted for one or more USB devices attached to bus Arise from various USB device driversTransaction lists executed at 1 ms intervalsTransaction or frame listDefines sequence of transactions to be performed During each 1 ms frameNote - Single block transfer requested by USB clientMay be performed as series of transactionsScheduled during consecutive 1 ms framesUSB host controllerInitiates transactions via root hub or hubsEach 1 ms frame begins with a start of frame - SOF - transactionFollowed by serial transmission of all frames in current listUSB Host Controller / Root HubAll communication on USBOriginates at host under software controlHave basic tree type architectureHost hardware consists ofUSB host controllerInitiates transactions over USBRoot hubProvides attachment points or portsFor USB devicesTwo USB host controller designs have been developedOpen host controllerUniversal host controllerEach performs same basic jobImplemented in slightly different waysThe Host ControllerIn either case host controller responsible for generating transactionsScheduled by host softwareHost controller driver -HCD Builds linked list of data structures - called transfer descriptorsList defines transactions scheduled to be performedDuring given frameData structures contain all information host controller needsTo generate transactionsUSB device addressType of transferDirection of transferAddress of device driver’s memory buffer - remember 472WritesPerforms writes to target deviceBy reading data to be deliveredFrom memory bufferBuffer supplied by individual USB device driver - top boxPerform parallel to serial conversionCreate USB transactionForward to root hub for transmission on busReads Performs reads from target deviceBy building read transactionSend to root hubHub transmits read transaction over USBTarget device Recognizes That it’s being addressedData is being requestedDevice transmits data back to root hubRoot hub forwards data to host controllerHost controllerPerforms serial to parallel conversionTransfers data to device driver’s memory bufferBuffer supplied by individual USB device driver - top boxRoot HubTransactions generated by host controllerForwarded to root hubTo be transmitted to USBConsequently every USB transactionOriginates at root hubRoot Hub Provides connection pointsFor USB devicesPerforms following key operationsControls power to USB portsEnables and disables portsRecognizes devices attached to portsSets and reports status eventsAssociated with each portConsists of hub controller and repeaterHub controller responds to accesses made to hub itselfRepeater forwards transactions to and from USB and host controller10960107620RepeaterHub ControllerRepeaterPower SupplyPort 1Port 1DataSystem PowerEnable / DisableData to / from Host ControllerData00RepeaterHub ControllerRepeaterPower SupplyPort 1Port 1DataSystem PowerEnable / DisableData to / from Host ControllerDataUSB HubsIn addition to root hubUSB supports additional hubsPermit extension of USB systemProvide means for attaching one or more USB portsAdditional peripheral devicesUSB hubs integrated into devices such as keyboardsCalled compound devicesCan also be implemented as stand alone devicesHubs may be bus or self poweredBus powered hubs limited in amount of power availableHubs contain two major functional elementsHub controllerRepeaterHubs must recognize That device has been attached or detachedReport event when host software polls hub6400805715USB Host ControllerRoot HubHubHubHubDeviceDeviceDeviceDeviceDeviceCompound USB DevicePCI Bus00USB Host ControllerRoot HubHubHubHubDeviceDeviceDeviceDeviceDeviceCompound USB DevicePCI BusHub ControllerContains USB interfaceDescriptors needed to identify device as a hubHub controller gathersHub and port status informationDetect connection and removal of devicesOther status info as wellReceives commands from host software Control various aspects of hubs operationPoweringEnabling portsEtc.Hub RepeaterTraffic arriving at hubMust be forwardedUpstream - towards hostDownstream - away from hostTransmissions originating at host arrive on hub’s root portForwarded to all enabled portsWhen target device responds to host initiated transactionRepeater must transmit response upstreamUSB Devices - On Client SideDevice descriptorsUSB devices contain descriptorsSpecify devices attributes and characteristicsInformation specifies to host softwareVariety of features and capabilities needed toConfigure deviceLocate USB client software driverUSB device driver may also use device descriptorsTo determine additional informationNeeded to access device in proper fashionMechanism referred to as Device FrameworkMust be understood by software toConfigure and access device correctlyUSB DevicesHigh-Speed DevicesHigh speed devicesSee all transactions broadcast over USBCan be implemented as full feature devicesAccept and send serial data at maximum rate of 12 Mbyte / secLow-Speed DevicesLimited in Throughput - 1.5 Mbyte / secFeature supportSee only transactions that follow preamble packetLow speed ports remain disabled during full speed transactionsFull speed bus traffic Prevented from being sent over low-speed cablesPreamble packetsSpecify following transaction will be broadcast at low speedHubs enable low-speed portsAfter detecting preamble packetLow-speed devices now accept low-speed bus activityUSB Communications ModelUnlike devices residing on other common bus structuresUSB devices do not directly consume system resourcesNot mapped into memory or I/O address spaceDo not use IRQ lines or DMA channelsAll transactions originate from host systemOnly system resources neededUSB memory locations used by USB system softwareMemory and I/O address space and IRQ line used byUSB host controllerDesign eliminates much of difficulty encountered With standard peripheral implementationsCommunications FlowUSB client initiates transferWhen it calls USB system software and requests transferUSB client drivers supplyMemory buffer used to store data when Sending or receiving from deviceRemember 472 modelEach transfer between Register or endpoint and Client driverIn USB deviceOccurs via communication pipeEstablished by USB system software during device configurationUSB system software Splits client’s request into individual transactionsConsistent with bus bandwidth requirements and USB protocol mechanismsRequests passed to USB Host Controller DriverTransaction to be performed then scheduledHost controller performs transactionBased upon contents of transfer descriptor build by HCDHCD knows all information necessary to perform required transactionKey informationAddress of target USB deviceType of transfer to be performedSize of data packetLocation of client’s memory bufferHost controller fetches transfer descriptorsThat have been built by HCDEach descriptor defines given transaction that must be performedTo satisfy client’s transfer requestEach transaction results in data being transferred From client’s buffer to USB deviceFrom USB device to bufferWhen entire transfer completedUSB system software notifies client driverInformation TransferTransfers initiated by client driverWhen it issues transfer request to USB driverUltimately transaction performed via lowlevel packetized transactionsLet’s examine each layer involvedTransfersEach USB function designed with collectionRegisters or endpointsUsed by client driver to access that functionEach endpoint Has particular transfer characteristics it supportsExampleInformation transferred to speakerMust continue at constant ratePrevents distortionOther endpoints may have different characteristicsRequire different transfer typesTransfer TypesFollowing transfer types supported by USBIsochronousBulkInterruptControlHigh speed transfer Supports all 4Low speed transferSupports only last twoClient drivers understand nature of transferRelated to each endpoint associated with its particular functionInformation determined by reading descriptors from deviceUSB Driver IRPs and FramesWhen client driver wishes to perform transfer to / from endpointCalls USB driver to initiate transferRequested transfer called IO Request Packet - IRPSome transfers require movement of large block of dataUSB is shared busCannot typically perform large block transferAll at one timeTo accommodate such transfersTransfer split up into smaller segments over longer period of timeSegments called transactionsSuch scheme ensures USB bandwidth can beAllocated amongst other USB devices on busUSB communication based upon transferring dataRegular intervals called framesEach is 1 msEach USB devices requires portion of USB bandwidthBe allocated to it during each 1 ms frameAllocation depends upon Required throughput of deviceAs specified in device descriptorAvailable bandwidth not required by other devicesAs device is attached and configuredSystem software parses device descriptorsTo determine required bandwidthIf requirements can be metDevice is configuredOtherwiseDevice not configuredUser notifiedHost Controller Driver and TransactionsHost controller driver Receives packet requests from USB driverSchedules them to be performedDuring a series of framesScheduling order based upon algorithm Defined by host controller driverAlgorithm Based upon transfer capabilities other limitations of systemScheduling performed by building series of data structuresCalled transfer descriptorsThese define each sequential transaction to be performedHost controller Reads and interprets the descriptorsExecutes the USB transaction describedUSB transaction comprises three phases1. Token phase Define type of transaction2. Data packet phase3. Handshake packet phaseAll USB transfers implemented to guarantee data deliveryExcept isochronousProvides feedback to senderWhether or not data received without errorDevice DescriptorsDevice describes itself to host softwareNumber of descriptorsDescriptors includeDevice DescriptorEach device has single descriptorContains information aboutDefault communication pipe used to configure deviceGeneral information about deviceAlso identifies number of possible configurations device supportsConfiguration DescriptorDevice has configuration descriptorFor each configuration device supportsExampleHigh power device may support low power modeHas configuration for each power modeDescriptor contains general informationAbout configurationDefines number of interfaces for deviceWhen used in this configurationInterface DescriptorGiven configuration may haveMultiple interfaces it supportsExampleCD RomMay require 3 device driversDriver for devices mass storage capabilityAudio device driver for playing musicVideo image driver for displaying imagesInterface descriptorsProvide general information about interfaceIndicates class of deviceSupported by this interfaceNumber of endpoint descriptors used when communicating with interfaceEndpoint DescriptorDevice interface contains multiple endpointsEach defines point of communicationDescriptor provides information such asTransfer type supported by endpointIsochronousBulkInterruptControlMaximum transfer rate supportedString DescriptorsCan be defined for Overall deviceGiven configurationEach interface definitionDescribe configuration and interfacesIn unicodeCan be displayed and read by userClass Specific DescriptorsProvide means of developing descriptors not covered by USB standardAnalogous to pragma statements in C or C++Device Framework or LayersProtocol stack supports 3 logical layersDescribe relationship betweenHost hardware and softwareCorresponding view exists in each USB deviceSeparate layers provided to Simplify understanding of USB communicationLet’s examineUSB Bus Interface LayerProvides for low level transfer of data over USBThis is the physical layer in stackConsists ofPhysical connectionElectrical signaling environmentPacket transfer mechanismLayer represents actual transfer of data across USB cableBetween host system and USB devicesHost side comprisesHost controller and hubClient side comprisesUSB interface within the deviceUSB Device LayerUSB Device layerRepresents portion of USB Comprehends actual USB Communication mechanismNature of transfers required by USB functional deviceLayer comprises USB system software on host sideLogical view of USB device on client sideUSB views logical device as collection of endpointsThat comprise a functional interfaceUSB system software provides services neededTo interface client software with its USB functionHas specific knowledge of USB transfer mechanismsMust allocate bus bandwidth to collection of USB devicesLogical USB device represents collection of endpointsThrough which client communicates with its functionSystem software views endpoints via device descriptorsSuch descriptors parsed during configurationTo obtain transfer characteristics of given deviceDescriptors and system software’s knowledge of USB transfer mechanismPermit bandwidth to be reserved for each functional device When it’s configuredSystem software performs variety of functionsDevice attachment and detachment detectionDevice configurationBandwidth allocationManaging control flow between client and deviceManaging data flow between client and deviceCollecting status and transaction statisticsTransaction schedulingControlling electrical interfaceFunction LayerLayer represents relationship betweenClient software Devices functional interfaceEach interfaceConsists of particular class of deviceClass driver designed to manipulateUSB client software cannot access associated function directlySuch scheme contrasts with PCI, ISA, etcResult of not being mapped directly into memory or I/O spaceDevice drivers must use USB programming interface To access associated deviceUSB clients view USB device asInterface which they know how to manipulateUSB system software must report to clientsInterface typeOther device characteristicsUSB Peripheral ConnectionUSB Provides single type of connectorFor attaching peripheral to systemSupports two different speeds of deviceLow speed devices - 1.5 Mbyte / secHigh speed devices - 12 Mbyte / secAll USB devices attach via USB hubHub provides one or more portsHub may have either high or low speed device attachedDevice’s speed detected when attached to hubEach port must support High and low speed devicesUnless has permanently attached deviceWhen transaction initiated by hostAll high speed devices and all hubs see transactionEach transaction has address fieldIdentifies targeted device or hubLow speed devices only see low-speed transactionsPreceded by high speed preambleDirects all hubs to enable low speed portsSub uses differential signalingFor serial communication between root hub and USB devicesPower supplied to USB devicesUSB cableLocal power supplyAssociated with the deviceThe Physical EnvironmentConnectors designed to permit any USB peripheral deviceTo be attached to hub portLow-speed CablesIntended only for 1.5Mbyte/sec signalingMaximum cable length cannot exceed 3 metersAlso referred to as Sub-channel cableAs noted only intended for 1.5 Mb/sec signalingSued in sub-channel applications where wider bandwidth not requiredDifferential signaling pairMay be non-twisted 28 AWG stranded conductorsUsed to reduce effects of noiseLow speed cables do not require shieldingHigh-speed CablesRequire twisted shielded pairMaximum Cable length is 5 metersPropagation delay is 30 ns over length of cableWhen operating in range of 1-16 MHzIf cannot be metCable must be shortenedExcept for differences noted aboveLow and high speed cables are identicalCables and Cable PowerCable power is 5 VdcCan be used to power peripheral devicesProvides up to 500 maMay be as little as 100 ma1097280210820Differential Signal Pair28 AWGUnshielded and Untwisted in low speed cableTwisted and shielded in full speed cablePower Pair20-28 AWG00Differential Signal Pair28 AWGUnshielded and Untwisted in low speed cableTwisted and shielded in full speed cablePower Pair20-28 AWGSignaling EnvironmentUSB serial data is NRZI encoded prior to transmissionNon-Return to Zero Inverted Signaling is differentialHelps to Mitigate affects of noise on linesEnsure data integrityConfigured as follows:59690040005NRZI EncoderNRZI DecoderD+Cable SegmentD-Differential DriverDifferential Receiver00NRZI EncoderNRZI DecoderD+Cable SegmentD-Differential DriverDifferential ReceiverDetecting Device Attachment and SpeedPrior to transmission to client deviceHost software must detect presence of device on busUSB designed to automatically detect presence (absence) of deviceWhen attached to (removed from) USBSame mechanism used to determine speed of client deviceLow speed or full speedDetectionDetection accomplished by monitoring differential data linesAfter cable power applied to portWhen no device attachedPull down resistors on D+ and D- ensure both data lines near groundUSB devices must provide pull-up resistorOn either D+ or D-Based upon speed of deviceD+ for full speedD- for low speedConnections appear as When device attached Current flows through voltage dividerPull-down is 15 K Pull-up is 1.5 KSignal on data line increases to about 90% of VccWhen hub detects One of data lines approaching VccOther near groundKnows device attachedBy knowing which line is highCan ascertain which kind of device has been attachedThus when D+ or D- rises above 2.0 Vdc for greater than 2.5 secDevice detected as attachedRemoval detected when both linesFall below 0.8 Vdc for greater than 2.5 secWhen device attached or removedStatus bits set or reset to indicate stateHost software polls hub periodically to check for attachment or detachmentNRZI EncodingData transferred on USBEncoded using NRZI encodingHelps to ensure high data integrity without requiring clockSuch scheme has been used for many yearsScheme shown asDataTransitions in data stream represent 0sNo transitions represent 1sEncoderNRZI encoder must maintain synchronization with incoming data streamTo correctly sample bitsData stream must be sampled within data windowTo detect whether transition has occurred since last bit timeDecoderDecoder samples data stream during each bit timeTo check for transitionsTransitions in data streamPermit decoder to maintain sync with incoming dataObserveLong series of consecutive 1sResults in no transitionsEventually receiver will loose syncSolutionUse bit stuffingBit StuffingForces transitions into NRZI data streamWhen 6 consecutive 1s encounteredEnsures receiver detects transitionEvery 7th bit timeEnables receiver to maintain syncTransmitter is responsible for inserting 0 bit into data streamDifferential Pair SignalingAs noted using differential pair signalingNoise reduction etcAs implemented in USBUses half duplex schemeDevice on either end can receive or transmitOnly one direction at a timeHalf duplex schemeRequires drivers be placed into high impedance stateWhen not transmitting dataTwo single ended receivers also used to detect bus statesExample drivers look like the followingUSB Transfers and TransactionsTransfersUSB supports 4 transfer typesInterrupt transferUsed for devices typically though of as interrupt drivenIn legacy PC applicationsExampleKeyboardUSB does not support interruptTherefor such devices must be periodically polledPolling rate clearly criticalData must not be lostNot so frequent that bus bandwidth is wastedBulk transferUsed for transferring large blocks of dataTypically such transfers have no periodic requirementExample Print jobIsochronous transferSuch transfers require constant delivery rateApplications must ensure rate matchingBetween sender and receiverExampleUSB microphone and speakerWant to ensure no data distortionResults from transferControl transferUsed to transfer specific requests to USB deviceMost commonly used during device configurationTransactionsTypically consist of three phasesToken packet phaseData packet phaseHandshake phase64008024130Token PhaseData Packet PhaseHandshake Packet PhaseSingle Transaction00Token PhaseData Packet PhaseHandshake Packet PhaseSingle TransactionToken Packet PhaseEach transaction begins with token phaseDefines type of transactionDevice address also included in this phaseWhen transaction targets specific deviceTwo kinds of tokens Stand alone Not followed by additional packetsOthersFollowed by one or two additional packetsData Packet PhasePayload associated with the transferCan carry maximum of 1023 bytes during each single transactionHowever max payload depends upon Transfer type being performedHandshake Packet PhaseAll USB transfers implemented To guarantee data deliveryExcept isochronousNo handshake phaseProvides feedback to sender of dataIf transaction occurred without errorsIf errors occurRetries attemptedPacketsPacket is mechanism used to perform all USB transactionsFormat given as follows82296010795Synchronization SequencePacket IDPacket Packet Specific InformationCRC BitsEOP00Synchronization SequencePacket IDPacket Packet Specific InformationCRC BitsEOPSynchronization SequenceSequence consists of 8 bits7 consecutive 0s1 single 1Recall 0s encode the transitions on differential data linesSynchronization sequence also alerts receiverData packet on wayWill immediately follow sync sequencePacket IdentifiersDefine purpose and content of given packetGrouped into 3 major categoriesToken packetsData packetsHandshake packetsSpecial packetsCurrently only special packet is preamble Used to signal low speed transactionsFormat and length of packet depends upon its typeToken packets 4 bytesData packets Variable lengthDepends upon transfer typeBulk transfers Limited to 64 bytes durning each transactionIsochronous transfersSet at 1024 bytesConfiguration ProcessHost software is responsible for Detecting and configuringAll devices attached to root hubProcess commonly referred to as USB device enumerationEnumeration begins at root hubEach hub port powered in turnWhen poweredHub determines if Low, full speed, no device attachedIf device presentStatus bits within hub set to indicate device presentPort enabledIssues USB reset to deviceAssigns unique addressCompletes configurationProcess repeated until all devices attached to root hubIdentified and configuredConfigurationRoot HubHost software begins enumeration by configuring root hubRecall two designs have been definedOpen Host ControllerUniversal Host ControllerEach provides same basic functionalityIndividual Device IsolationInitially each attached device isolated from hubSince all ports initially disabledHost software detects presence of device when power appliedRecall earlier discussionNext each attached device issued reset commandReset to Address ZeroResetting device forces it to respond to Default device addressZeroFollowing resetEvery USB device responds to address zeroUsing such a scheme Configuration software can read every device’s descriptorAt same default addressAddress AssignmentDuring configurationEach device assigned unique addressDevice will respond to that address tehreafterWith such a schemePossibility of address contention eliminatedConfiguration VerificationDuring configuration host software probes each deviceMust determineEndpoints associated with deviceIf endpoints can be accommodated based upon remaining free bandwidthIf bus power required by device can be accommodatedDevices may have one or more configurationsEach configuration descriptorRepresents different set of resources that can be chosenHost software ensures that all required resource requests can be satisfiedIf cannot - configuration refusedPower RequirementsHost software must verifyBus power required by deviceCan be supplied by hub portDuring configurationDevice specified to consume no more than 100 mA of bus currentMax bus power needed specified in configuration descriptorBus BandwidthHost software must verify that bus bandwidth required by device Can be satisfiedEach configurationDefines set of endpointsEach endpoint must specify amount to USB bandwidth it requiresIf sufficient bandwidth availableCommunication pipe set upSuch set up reserves required bandwidthAfter successfully allocating bandwidth to each endpoint within deviceDevice can be configuredIf bandwidth not availableOther configurations checkedIf every configuration exceeds bandwidthDevice not configuredConfiguration Value AssignedOnce configuration selectedHost software configures deviceDone by assigning configuration value that corresponds toChosen configurationConfiguration value obtained fromSelected configuration descriptorDevice can now Be accessed by client softwareConsume the max amount of current specified in its configurationClient Software NotificationOnce device successfully configuredUSB system must locate appropriateClass driver or driversDesignated to access deviceUSB class drivers must be notified that Device has been installedMust be provided with information regardingCharacteristicsCapabilities of deviceExact procedure USB system software uses to identifyUSB device driver etcOperating system dependentUSB Device ConfigurationPrior to configuring a deviceHub to which device connectedMust have already been configured and had power applied to portsNext hub and configuration software must detect Connected deviceTo convey device information back to hostDevice implementers must create device descriptorsThese reflect Characteristics Behaviour of deviceStandard descriptors includeDevice DescriptorDescribes number of configurations supported by deviceConfiguration DescriptorsSpecifies one or more interfacesDefines certain attributes associated with this configurationInterface DescriptorsDefines number of endpoints related to interfaceDefines certain attributes associated with interfaceEndpoint DescriptorsSpecify attributes associated with given endpointInformation needed by host softwareTo determine how endpoint should be accessedString DescriptorsOptional descriptorsConsist of UNICODE string that provides human readable informationThat can be displayedClass-Specific DescriptorsGiven device may require additional descriptorsAs defined by particular device class specDevice ClassesImportant aspect of device configurationDetermine which class particular device belongsDevice’s class definitionProvides information used by host and client softwareTo determine how a device isControlledAccessedHost software uses informationIdentify corresponding device driverClass driver uses informationCan use information to determine specific characteristics of deviceDevice classes defined in individual specificationsAt present following device classes are definedHID Device Class - Human Interface DevicesCommunication Devcie ClassMonitor Device ClassMass Storage Device ClassAudio Device Class ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download