Адаптивный тип
Адаптивные конечные точки - конечные точки наиболее способные по возможностям. Они способны к источнику или стока данным во всяком случае внутри своего операционного диапазона.(They are able to source or sink data at any rate within their operating range. Adaptive source endpoints produce data at a rate which is controlled by the data sink.) Сток обеспечивает обратную связь (обратитесь к Раздел 5.10.4.2) к источнику, которая позволяет источнику знать требуемую стоком скорость передачи данных. Адаптивные конечные точки могут связываться со всеми типами конечных точек стока. Для адаптивных конечных точек стока, информация о скорости передачи данных внедрена в поток данных. Среднее число выборок, полученных в течение определенного среднего времени, определяет мгновенную скорость передачи данных. Если это число изменения в течение операции, соответственно корректируется скорость передачи данных.
Диапазон скорости операции передачи данных, может центрироваться вокруг((The data rate operating range may center around) одной скорости (например, 8 кГц), выбираться между несколькими программируемыми или автоматически обнаруженными скоростями передачи данных (32 кГц, 44.1 кГц, 48 кГц, …), или может быть внутри одного или нескольких диапазонов (например, от 5 кГц до 12 кГц,от 44 кГц до 49 кГц). Адаптивные устройства должны сообщить свои возможности программирования в дескриптор специфического класса конечной точки как описано в спецификации их Класса Устройства (Adaptive devices must report their programming capabilities in the class specific endpoint descriptor as described in their Device Class specification)
Пример адаптивного источника - CD проигрыватель, который содержит полностью адаптивный типовой преобразователь скорости (SRC-sample rate converter) такой, чтобы частота выборки вывода больше не должна быть 44.1 кГц, но может быть что-нибудь внутри операционного диапазона SRC (An example of an adaptive source is a CD player that contains a fully adaptive sample rate converter (SRC) so that the output sample frequency no longer needs to be 44.1 kHz but can be anything within the operating range of the SRC.) Адаптивные стоки включают такие конечные точки как высококачественные цифровые колонки, headsets, и т.д.
Асинхронный тип
Асинхронные конечные точки не могут синхронизировать по SOF или любым другим часам в области(domain) USB .Они являются источником или стоком изохронного потока данных или с фиксированной скоростью передачи данных (одно частотные конечные точки), при ограниченном числе скоростей передачи данных (32 кГц, 44.1 кГц, 48 кГц, …), или с непрерывно программируемой скоростью передачи данных.(They source or sink an isochronous data stream at either a fixed data rate (single frequency endpoints), a limited number of data rates (32 kHz, 44.1 kHz, 48 kHz, …), or a continuously programmable data rate. ) Если скорость передачи данных программируема, она устанавливается в течение инициализации изохронной конечной точки.( If the data rate is programmable, it is set during initialization of the isochronous endpoint.) Асинхронные устройства должны сообщить свои возможности программирования в дескриптор определяющего класс конечной точки как описано в спецификации их Класса Устройства. (Asynchronous devices must report their programming capabilities in the class specific endpoint descriptor as described in their Device Class specification.) Скорость передачи данных внешние прикреплена к USB часами или свободно выполняющимися внутренними часами. (The data rate is locked to a clock external to USB or to a free running internal clock.) Эти устройства помещают накладные расходы согласования скоростей передачи данных, в другое место окружения USB . Асинхронные конечные точки источника несут свою информацию о скорости передачи данных неявно в числе выборок, которые они производят за кадр. Асинхронные конечные точки стока должны явно обеспечить информацией об обратной связи адаптивный драйвер (обратитесь к Разделу 5.10.4.2).(Asynchronous sink endpoints must provide explicit feedback information to an adaptive driver ).
Пример асинхронного источника - звуковой проигрыватель CD, который выдает данные базируясь на внутренних часах или резонаторе. Другой пример - приемник Цифрового Звукового Радиовещания (DAB) или Цифровой Спутниковый Приемник (DSR). Здесь также, типовая скорость фиксирована на радиопередающей стороне и не управляется USB.
Асинхронными конечными точками стока могли бы быть дешевые колонки, выполняющиеся от своих внутренних типовых часов.
Другой случай возникает, когда имеются два или больше устройств, присоединенных к USB, которые должны иметь главное управление для порождения SOF, чтобы функционировать как синхронные устройства. (Another case arises when there are two or more devices present on USB that need to have mastership control over SOF generation in order to operate as synchronous devices.) Это могло бы случаться, если бы имелись два телефонных устройства, и каждый из них был бы прикреплен к различным внешним часам.(This could happen if there were two telephony devices, each locked to a different external clock.) Одно телефонное устройство могло бы быть в цифровой форме соединено с PBX, который не синхронизирован с ISDN. Другое устройство могло бы быть соединено непосредственно с ISDN. Каждое устройство будет источником или стоком данных на/из стороны сети с внешним управлением скорости.(Each device will source or sink data to/from the network side at an externally driven rate.) Так как только одно из устройств может брать главенство по SOF, другие стоки или истоки данных будут по скорости асинхронны к SOF. (Since only one of the devices can take mastership over SOF, the other will sink or source data at a rate which is asynchronous to SOF.) Этот пример указывает, что каждому устройству, способному к главенству по SOF возможно придется функционировать как асинхронное устройство.
Babble и Восстановления при Потери Активности
USB должна быть способна обнаружить и восстановиться от условий, которые заставляют ее ждать конца пакета неопределенно долго или которые оставляют входную шину в каком-либо другом состоянии, а не в остановленном(idle) состоянии при окончании кадра. Потеря активности (LOA - Lost of Activity) характеризуется SOP, при отсутствии активности шины (шина остается в J или K состоянии) и отсутствием EOP в конце кадра. Babble характеризуется появлением SOP, при активности шины, пришедшим после конца кадра.(Babble is characterized by an SOP followed by the presence of bus activity past the end of a frame.) LOA и babble имеют возможность(potential) или заблокировать шину или принудительно начать следующий кадр. Но такая ситуация не приемлема, и появление этого должны быть предотвращено. Как USB компонент, отвечает за управление связью, так концентраторы ответственны за обнаружение babble/LOA и восстановление от этого. Все устройства USB, которые будут не в состоянии завершать свою передачу до окончания кадра, не допускаются к передачи конца прошлого кадр, и с помощью самого близкого концентратора отключается порт, к которому присоединено неисправное устройство.(All USB devices that fail to complete their transmission at the end of a frame are prevented from transmitting past a frame’s end by having the nearest hub disable the port to which the offending device is attached.) Детально механизм восстановления концентратора от babble/LOA описывается в Разделе 11.4.3.
Глава 9
Каркас Устройства USB
Базисные Механизмы Связи
Этот раздел описывает более подробно базисные механизмы связи которые обеспечиваются уровнем Устройства USB.
Битовое Поле Изменения Состояния Концентратора и Порта
Битовое Поле Изменения Состояния Концентратора и Порта, показанное на Рисунок 11-20, указывает, испытал ли концентратор или порт изменение состояния. Это битовое поле также указывает какой порт(ы) имел изменение в состоянии.(This bitmap also indicates which port(s) have had a change in status.) Концентратор возвращает это значение конечной точке Изменения Состояния. Концентраторы сообщают это значение в виде байтов. То есть если концентратор имеет шесть портов, он возвращает байт и в те биты которые отвечают за не допустимые порты записывает нули. Системное программное обеспечение знает число портов на концентраторе (это записано в дескрипторе концентратора) и декодирует соответственно Битовое Поле Изменения Состояния Концентратора и Порта. Концентратор сообщает любые изменения в состоянии концентратора в бите 0 Битового Поля Изменения Состояния Концентратора и Порта.
Размер Битового Поля Изменения Состояния Концентратора изменяется от минимального размера в один байт. Концентраторы сообщают количество битов равное имеющимся портам на концентраторе, подчиняясь требованию степени детализации в байт (то есть, укладываясь в минимальное число байт).
Рисунок 11-20. Битовое Поле Изменения Состояния Концентратора и Порта
Конечная точка Изменения Состояния в любое время опрашивается хост контроллером и при наличии ненулевых бит Изменения Состояния, возвращается Битовое Поле Изменения Состояния Концентратора и Порта. Концентраторы производят выборку изменений в Конце кадра (EOF2) при подготовке к потенциальной передаче данных в последующем кадре USB. Если было обнаружено изменение, то данные будут перемещены через конечную точку Изменения Состояния в последующем кадре USB. На Рисунок 11-21 показан механизм осуществляющий выборку битов изменений порта и концентратора.
Рисунок 11-21. Пример Выборки Бита Изменения Концентратора и Порта
BRequest
Это поле определяет специфический запрос. Биты Тип в поле bmRequestType изменяют значение этого поля. Эта спецификация только определяет значения для поля bRequest, когда биты сброшены, чтобы обнулить признак стандартного запроса (обратитесь к Таблице 9-2).
Буферизация для Согласования Скорости
При условии, что имеются несколько часов, которые воздействуют на изохронные потоки связи в USB, буферизация требуется для согласовывания скоростей потоков связи в USB. Должна иметься доступная буферная область, и у конечной точки устройства и у клиентского программного обеспечения на стороне хоста. Эти буфера обеспечивают область для накопления данных, пока не придет время передачи, чтобы продвинуть их по USB. Определенные естественные, для устройства, скорости передачи данных, максимальный размер пакетов данных, которые продвигаются по шине, могут быть также вычислены. На рисунок 5-17 показаны уравнения, используемые, для определения размера буфера на устройстве и хосте и максимального размера пакета, который должен быть запрошен для поддержания требуемой скорости передачи данных. Эти уравнения позволяют для устройства и клиентского программного обеспечения для определенного время расчитать скорость часов обслуживания (переменную X), скорости часов выборку (переменная C), и размеры выборки(переменная S).(These equations allow a device and client software design time determined service clock rate (variable X), sample clock rate (variable C), and sample size). USB позволяет проходить только одной транзакцию за такт шины(USB only allows one transaction per bus clock.) Эти уравнения должны предоставить расчитанную информацию для выбора соответствующих размеров пакета, который конечная точка сообщит в информации о характеристики и соответствующих требований к буферу устройства/конечной точки и клиентского программного обеспечения(These equations should provide design information for selecting the appropriate packet size that an endpoint will report in its characteristic information and the appropriate buffer requirements for the device/endpoint and its client software). Рисунок 5-14 показывает фактический буфер, пакет, и значения часов для типичного изохронного примера.
Рисунок 5-17. Формулы Определения Размера Пакета и Буфера для Согласования Скорости Изохронных Передач
В модели данных USB принято, что устройства имеют некоторый естественный размер и скорость выборки. USB поддерживает передачу пакетов, которые являются кратными размеру выборки, что делает обработку восстановления при ошибках проще, когда изохронные транзакции повреждаются на шине.(USB supports the transmission of packets that are multiples of sample size to make error recovery handling easier when isochronous transactions are damaged on the bus.) Если устройство не имеет никакого естественного размера выборкм или если выборки большие чем пакет, необходимо описать размер выборки как один байт.(If a device has no natural sample size or if its samples are larger than a packet, it should describe its sample size as being one byte.) Если выборка разбита по пакетам данных, восстановление при ошибках может быть тяжелее, когда теряется произвольная транзакция. В некоторых случаях, может быть потеряна синхронизация данных, если приемник не знает, что в номере кадра каждая часть выборки передана.(In some cases, data synchronization can be lost unless the receiver knows in what frame number each partial sample is transmitted.) Кроме того, если число выборок может измениться необходимо исправление часов (например, для не - полученных часов устройства), это может быть трудно или неэффективно, зная что часть выборок передана.(Furthermore, if the number of samples can vary due to clock correction (e.g., for a non?derived device clock), it may be difficult or inefficient to know when a partial sample is transmitted.) Следовательно, USB не разбивает выборки по пакетам.
Глава 7
Электрические параметры
Bulk Передачи
Передачи типа bulk разработан, для поддержания устройств, которые должны передать относительно большие количества данных с сильно переменными временами(high variable times), где передача может быть отсрочена, пока пропускная способность не будет доступна. Запрос канала с типом передачи bulk обеспечивает запросчика следующим:
Доступ к USB на основании имеющейся пропускной способности (Access to the USB on a bandwidth available basis)
Повторение передач, при случающихся иногда неудачных доставках из-за ошибки на шине
Гарантируемая поставка данных, но никаких гарантий относительно пропускной способности или времени отклика
Передачи Bulk происходят только на основании имеющейся пропускной способности. Когда в USB много свободной пропускной способности, передачи bulk могут происходить относительно быстро; в то время как в USB мало доступной пропускной способностью, передачи bulk могут происходить(просачиваться - trickle) в течение относительно длительного периода времени.
Передачи Bulk могут создаваться или устройством или клиентом. Нет никакой периодичности или гарантии времени отклика. Когда все данные перемещены, или если превышен порог ошибок, IRP возвращается клиенту.
Bulk Транзакции
Тип транзакций Bulk характеризуется способностью гарантировать доставку данных без ошибок между хостом и функцией посредством обнаружения ошибок и повторений. Транзакции Bulk используют три фазы транзакции, состоящие из маркера, данных, и пакетов квитирования как показано на Рисунок 8-9. При некоторых условиях управлении потоком данных и остановке, фаза данных может быть заменена на квитирование, в результате получаются две фазы транзакций, в которых данные не передаются.
Рисунок 8-9. Формат Транзакции Bulk
Когда хост хочет получить данные bulk, он выдает маркер IN. Конечная точка функции отвечает, возвращая или пакет DATA или если это невозможно квитирование NAK или STALL. NAK указывает, что функция временно неспособна возвращать данные, в то время как STALL указывает, что конечная точка постоянно останавливается и требует вмешательства программного обеспечения хоста. Если хост получает пакет достоверных данных, он отвечает квитированием ACK. Если хост обнаруживает ошибку при получении данных, он вообще не возвращает пакет квитирования функции.
Когда хост хочет передавать данные bulk, он сначала выдает маркерный пакет OUT за которым следует пакет данных. Затем функция возвращает одно из трех квитирований. ACK указывает, что пакет данных был получен без ошибок и сообщает хосту о том что, он может посылать следующий пакет из последовательности. NAK указывает, что данные были получены без ошибок, но хост должен снова послать данные, потому что функция была в тот момент временно неспособна принимать данные (например, из-за заполнения буфера). Если конечная точка была остановлена, то возвращается STALL, чтобы указать, что хост не должен повторять передачу, потому что имеется условие ошибки в функции. Если пакет данных был получен с ошибками в CRC или во вставке бит, то квитирование не возвращается.
Рисунок 8-10 показывает использование последовательности бит, и данные PID для bulk чтения и записи. Синхронизация пакетов данных достигается с помощью использования бит переключения последовательности данных и PIDов DATA0/DATA1. Конечные точки Bulk должны иметь свои биты последовательности переключения, инициализированные с помощью отдельной управляющей конечной точки.
Рисунок 8-10. Bulk Чтения и Записи
Хост всегда инициализирует первую транзакцию передачи по шине как PID DATA0. Вторая транзакция использует PID DATA1, и последующие передачи данных чередуются для остатка от bulk передачи. Передатчик пакета данных переключается после получения ACK, и переключается после получения и принятия правильного пакета данных (обратитесь к Разделу 8.6).(The data packet transmitter toggles upon receipt of ACK, and the receiver toggles upon receipt and acceptance of a valid data packet)
Цель Документа
Потенциальные клиенты
Спецификация прежде всего направлена на разработчиков периферии и систем OEM, но и имеет ценную информацию для разработчиков платформы операционной системы / BIOS / драйвера устройства, адаптера IHV/ISV, и продавцов контроллера платформы / адаптера.
Польза
Эта версия спецификации Универсальной Последовательной Шины может использоваться для планирования создания новых изделий, раннего прототипа, и предварительной разработки программного обеспечения. Все конечные продукты должны быть согласованы со Спецификацией 1.0 Универсальной Последовательной Шины.
Цель Спецификации
Этот документ определяет промышленный стандарт Универсальной Последовательной Шины. Спецификация описывает атрибуты шины, определение протокола, типы транзакций, управление шиной, и интерфейс программирования, требуемого, чтобы разрабатывать и формировать системы и периферийные устройства, которые согласуются с этим стандартом.
Цель состоит в том, чтобы дать возможность устройствам различных продавцов функционировать в открытой архитектуре. Спецификация создана как расширение к архитектуре PC, охватывающей переносные, деловые настольные, и домашние среды. Подразумевается, что спецификация позволяет системе OEM и разработчикам периферии большое поле деятельности при создании гибких эксплуатационных изделий и различный рынок сбыта без проблем переноса устаревших интерфейсов или проигрышной совместимости.
Цели создания USB Шины
USB Шина разработана, чтобы быть расширением промышленного стандарта к архитектуре PC в фокусе политики Computer Telephony Integration (CTI), потребителя, и производительности приложении. Следующие критерии применялись в определении архитектуры USB Шины:
Легкая в использовании для расширения периферийных устройств PC
Дешевая и поддерживает скорости передачи до 12 МБ
Полная поддержка для передачи в реальном масштабе времени голоса, звука, и сжатого видео
Гибкий протокол для смешанного режима - изохронные передачи данных и асинхронная передача сообщений
Integration in commodity device technology Интеграция в технологию устройства
Поддержка различных конфигураций PC и форм факторов
Обеспечение стандартного интерфейса способного к быстрому распространению в изделиях
Обеспечение возможность создание новых классов устройств, которые увеличат возможность PC
Циклический Контроль по Избыточности
Циклические контроли по избыточности (CRC) используются для защиты всех полей кроме PID в маркерах и пакетах данных. В данном контексте, эти поля рассматривается как защищенные поля. PID не входит в проверку CRC пакета, содержащего CRC. Все CRC сгенерированы для соответственно своих полей в передатчике прежде, чем выполняется вставка бит. Точно так же CRC декодируются в приемнике после того, как были удалены вставленные биты. CRC Маркера и пакета данных обеспечивают 100 % - защиту от всех одиночных и двойных ошибок бит. Принято что неправильный CRC, указывает, что один или более защищенных полей искажены и заставляет приемник игнорировать эти поля, и в большинстве случаев весь пакет.
Для создания CRC и осуществления проверки, сдвиговые регистры в генераторе и проверочном устройстве работают по одной и той же схеме.(For CRC generation and checking, the shift registers in the generator and checker are seeded with an all ones pattern.) Для каждого посланного или полученного бита данных, старший бит записи текущего остатка XORed(складывается по модулю 2) с информационным разрядом и затем остаток сдвигается влево на один бит и младший бит записи устанавливается в 0. Если результат этого XOR(сложения) 1, то остаток XORed(складывается) с генерируемым полиномом.(If the result of that XOR is 1, then the remainder is XORed with the generator polynomial.)
Когда последний бит контрольного поля послан, CRC в генераторе инвертируется и посылается на проверочное устройство MSb (старшими битами) вперед. Когда последний бит CRC получен проверочным устройством, и не произошло никаких ошибок, остаток будет равен остаточному полиному.
Требования к вставке бита должны удовлетворять CRC, из-за этого возникает необходимость вставить нуль в конец CRC, если предшествующие шесть битов были все единицы.
CRC Данных
CRC данных - 16-битный полином применяемый к полю данных пакета данных. Полином генерируется по формуле:
G(X) = X16 + X15 + X2 + 1
Двоичная битовая маска, которая отображает этот полином: 1000000000000101. Если все данные и биты CRC получены без ошибки, 16-битный остаток будет 1000000000001101.
CRC маркеров
Для маркеров предусмотрено пяти-битное поле CRC и оно покрывает поля ADDR и ENDP маркеров IN, SETUP, и OUT или поле отметки времени маркера SOF. Полином генерируется по формуле:
G(X) = X5 + X2 + 1
Двоичная битовая маска, которая отображает этот полином: 00101. Если все биты маркера получены без ошибки, пяти-битный остаток в приемнике будет 01100.
Данные Разрушены или Не Приняты
Если данные не могут быть приняты, или полученный пакет данных разрушен, приемник выдает NAK или квитирование STALL, или приостанавливается, в зависимости от обстоятельств, при этом приемник не переключает свой бит последовательности. На Рисунок 8-17 показан случай, когда в ответ на транзакцию посылается NAK и затем повторяется передача. Любое не ACK квитирование или приостановка вызывает подобную реакцию. Передатчик, не получив квитирование ACK, не будет переключать свой бит последовательности. В результате, неудачная транзакция пакета данных оставляет биты последовательности передатчика и приемника, синхронизированными и непереключенными. Транзакция будет затем повторена и, в случае успешного завершения вызовет переключение битов последовательности и передатчика и приемника.
Рисунок 8-17. Отвергнутая Транзакция с Повторением
Дескриптор Концентратора
Таблица 11-9. Дескриптор Концентратора
Смещение | Поле | Размер | Описание | ||||
0 | bDescLength | 1 | Число байтов в этом дескрипторе, включая этот байт. | ||||
1 | bDescriptorType | 1 | Тип Дескриптора | ||||
2 | bNbrPorts | 1 | Число downstream портов, которые поддерживает этот концентратор. | ||||
3 | wHubCharacteristics | 2 | D1..D0: Режим Переключения Мощности
00 - Совместное переключение мощности (мощность всех портов за раз) 01 - Индивидуальное переключение мощности у порта 1X - Переключение мощности отсутствует (порты всегда под питание, когда концентратор включен и выключены, когда концентратор выключен). D2: Идентифицирует Составное Устройство 0 - Концентратор - не часть составного устройства 1 - Концентратор - часть составного устройства D4..D3: Режим Защиты от Сверхтоков 00 - Глобальная Защита от Сверхтоков. Концентратор сообщает о сверхтоке как суммирование всех токов портов, без прерывания состояние сверхтока индивидуального порта. 01 - Индивидуальная для Порта Защита от Сверхтоков. Концентратор сообщает о сверхтоке на базиса каждого порта. Каждый порт имеет индикатор сверхтока. 1X - Нет Защиты от Сверхтоков. Эта опция позволена только для питающихся от шины концентраторов, в которых не реализована защита от сверхтоков. D15..D5: Зарезервированы | ||||
5 | bPwrOn2PwrGood | 1 | Время (в 2 мс интервалах) от момента начала последовательности подачи мощности на порт, до установления нормальной мощности на этом порте. Системное программное обеспечение использует это значение, чтобы определить, как долго ждать перед обращением к запитаному порту . | ||||
6 | bHubContrCurrent | 1 | Максимальные требования по току к электроники контроллера концентратора в mA. | ||||
7 | DeviceRemovable | Переменная зависящая от числа портов на концентраторе | Указывает, имеет ли порт сменное присоединенное устройство. Если присоединено к порту не-сменное устройство, тот порт никогда не будет получать вставку уведомление изменения.( an insertion change notification.) Это поле сообщается со степенью детализации в байт. В байте, если порт не существует для данной позиции, в поле представляющего характеристики порта возвращается “0”.
Определение бита: 0 - Сменное устройство 1 - Не сменное устройство(постоянно присоединено) Это битовое поле определяет соответствие индивидуальных портов на концентраторе: Bit 0: Резервирован для будущего использования Bit 1: Порт 1 Bit 2: Порт 2 И т.д. Бит n: Порт n (В зависимости от реализации, максимум до 255 портов). | ||||
Variable | PortPwrCtrlMask | Переменная зависящая от числа портов на концентраторе | Указывает, воздействует или нет на порт запрос регулирования мощности в режиме группы. Порты, которые имеют в своем поле единицу всегда, требуют запрос SetPortFeature (PORT_POWER), чтобы управлять состоянием мощности порта.
Определение бит: 0 - Порт не замаскирован на возможность управления мощностью в режиме группы. 1 - На порт не воздействуют команды управления мощностью в режиме группы. Команды должны быть посланы этому порту, чтобы переключиться мощность вкл. и выкл. Это битовое поле определяет соответствие индивидуальных портов на концентраторе: Bit 0: Резервирован для будущего использования Bit 1: Порт 1 Bit 2: Порт 2 И т.д. Бит n: Порт n (В зависимости от реализации, максимум до 255 портов). |
Дескрипторы
Устройства USB сообщают свои атрибуты, использующие дескрипторы. Дескриптор - структура данных с определенным форматом. Каждый дескриптор начинается с поля шириной в байт, которое содержит общее число байтов в дескрипторе, который следует за полем шириной в байт, определяющее тип дескриптора.
Использование дескрипторов позволяет компактно хранить атрибуты индивидуальных конфигураций, потому что каждая конфигурация может многократно использовать дескрипторы или части дескрипторов из других конфигураций, которые имеют те же самые характеристики. Таким способом, дескрипторы похожи на индивидуальные записи данных в реляционной базе данных.
В соответствующих местах, дескрипторы содержат ссылки на строковые дескрипторы, которые предоставляют отображаемую информацию, описывающую дескриптор, в удобной для прочтения человеком форме. Включение строковых дескрипторов необязательно. Однако, поля ссылок внутри дескрипторов обязательны. Если устройство не поддерживает строковые дескрипторы, в строковых полях должны быть ссылки, сброшенные в нуль, чтобы указать, что нет доступных строковых дескрипторов.
Если дескриптор возвращается со значением в поле длины, которое является меньше чем определенно этой спецификацией, такой дескриптор недопустим и должны быть отклонен хостом. Если дескриптор возвращается со значением в поле длины, которое является большим чем определенно этой спецификацией, дополнительные байты, игнорируются хостом, но следующий дескриптор размещается используя возвращенную длину, а не ожидаемую длину.
Класс и определенные продавцом дескрипторы могу быть получены одним из двух способов. Класс и определенные продавцом дескрипторы, которые связаны со стандартными дескрипторами, возвращаются в том же самом буфере данных как стандартный дескриптор немедленно после связанного стандартного дескриптора.
Если, например, класс или определенный продавцом дескриптор связан с дескриптором интерфейса, связанные , класс или определенный продавцом дескриптор помещаются при возвращении в буфер между дескриптором интерфейса и дескрипторами конечной точки интерфейса, в ответ на запрос GET_CONFIGURATION_DESCRIPTOR. Длина стандартного дескриптора не увеличивается, чтобы разместить расширение для класса или определенного продавцом дескриптора. Класс или определенный продавцом дескриптор придерживаются того же самого формата как стандартные дескрипторы с полями длины и типа как первые два байта специфического дескриптора.
Класс или определенный продавцом дескриптор, которые не связаны со стандартным дескриптором, можно получить используя запросы класса или определенные продавцом.
Если класс требует любого специфического определения стандартных дескрипторов, определение класса должно включить такие требования как часть определения класса(If the class requires any specific definition of the standard descriptors, the class definition must include those requirements as part of the class definition.) Кроме того, если класс определяет набор расширяющий стандартных дескрипторов, они должны также быть полностью определены в определении класса(In addition, if the class defines a standard extended set of descriptors, they must also be fully defined in the class definition.) Любые определения расширений дескрипторов должны придерживаться подхода, используемого стандартными дескрипторами; например, все дескрипторы должны начаться с поля длины.
Дескрипторы Концентратора получаются базируясь на каркасе устройства USB. Дескрипторы Концентратора определяют устройство концентратора и порты на этом концентраторе. Хост обращается к дескрипторам концентратора через создаваемый по умолчанию канал концентратора.
USB Спецификация (обратитесь к Главе 9) определяет следующие дескрипторы:
Устройства
Конфигурации
Интерфейса
Конечной точки
Строковый (необязательный)
Класс концентратора определяет дополнительные дескрипторы (обратитесь к Разделу 11.11.2). Кроме того, в каркасе устройства USB допустимы определенные продавцом дескрипторы. Концентраторы поддерживают стандартные команды устройства USB как определено в Главе 9.
Динамически Отсоединение
Когда устройство отсоединяется из сети с мощностью, текущей в кабеле, индуктивность кабеля заставит произойти большой обратный скачек напряжение на открытом конце кабеля устройства. Этот обратный скачек напряжения не разрушителен. Соответствующие меры шунтирования на портах концентратора подавят любой парный шум. Диапазон частот этого шума обратно пропорционально зависит от длины кабеля, максимум 60 МГц для одного метра кабеля. Это требует некоторой низкой емкости, очень низкие блокировочные конденсаторы индуктивности на каждом коннекторе порта концентратора. Обратный скачек напряжения и шум, который он создает, также уменьшают шунтируемую емкостью на конец кабеля устройства. Также, должна иметься некоторая минимальная емкость на конец кабеля устройства для обеспечения того, чтобы индуктивный обратный скачек на открытом конце кабеля не заставил напряжение на конце устройства изменить полярность. Рекомендуется минимум 1.0 mФ шунт на Vbus.
Снова, штырьки сигнала защищены от чрезмерных напряжений в течение динамического отсоединения, углубление в коннекторе такое, что сначала вступают в контакт штырьки мощности.
Динамическое Присоединение и Отсоединение
Действие подключения или отключения концентратора или функции не должно воздействовать на функциональные возможности другого устройства на других сегментах сети. Отключение функции остановит транзакцию между этой функцией и хостом. Однако, концентратор, к которому эта функция была присоединена, восстановится от этого условия и предупредит хост, что порт был разъединен.
Динамическое Присоединение и Удаление
Устройства USB могут быть присоединены и удалены в любое время. Концентратор, который обеспечивает точку присоединения или порт, ответственен за сообщение о любом изменении в состоянии порта.
Хост разблокировывает порт концентратора, к которому устройство присоединено после обнаружения присоединения, которое также имеет эффект сброса устройства. Сброшенное устройство USB имеет следующие характеристики:
Отвечает на заданный по умолчанию адрес USB(Responds to the default USB address)
Несконфигурированный
Первоначально не подвешен(Is not initially suspended)
Когда устройство удалено из порта концентратора, хосту сообщается относительно удаления. Хост отвечает, отключая порт концентратора, к которому было присоединено устройство.
Добавление Устройств
USBDI должен предоставить механизм для драйвера концентратора, который сообщит USBD относительно добавления нового устройства к определенной части USB и восстанавливающий USBD ID нового устройства USB.(The USBDI must provide a mechanism for the hub driver to inform USBD of the addition of a new device to a specified USB and to retrieve the USBD ID of the new USB device. ) Задачи USBD включают назначение адреса устройства и подготовки создаваемого по умолчанию канала устройства для использования.
Доступ к Шине при Передачах (Bus Access for Transfers)
Выполнение любой передачи данных между хостом и устройством USB требует использования некоторой пропускной способности USB. Поддержка широкого разнообразия изохронных и асинхронных устройств требует, чтобы каждое требование устройства о передаче было приспособлено. Процесс назначения пропускной способности шины устройствам называется Управлением Передачи(Transfer Management). Имеются несколько сущностей на хосте, которые координируют информацию, перемещающуюся по USB: Клиентское программное обеспечение, Драйвер USB (USBD), и Драйвер Хост Контроллера (HCD). Разработчики этих сущностей должны знать ключевые концепции, связанные с доступом к шине:
Управление Передачей(Control Transfer) - сущности и объекты, которые поддерживают поток связи по USB.
Слежение За Транзакцией(Transaction Tracking) - механизмы USB, которые используются, чтобы проследить транзакции, как они двигаются через систему USB.
Время Шины(Bus Time) - время затрачиваемое на перемещение пакет информации в шине(Bus Time - The time it takes to move a packet of information over the bus.)
Размер Буфера Устройства/Программного Обеспечения - Пространство, требуемое, чтобы поддерживать транзакцию шины.
Восстановление Пропускной Способности Шины (Bus Bandwidth Reclamation) - Условия, при которых пропускная способность, которая была распределена для других передач, но не использовалась и теперь может быть заново использована передачами управления и bulk (Bus Bandwidth Reclamation - Conditions where bandwidth that was allocated to other transfers but was not used and can now be possibly reused by control and bulk transfers.)
Предыдущие разделы, сосредотачивались на том, как клиентское программное обеспечение устанавливает отношение с функцией и какие логические потоки существуют в каналах между двумя сущностями (The previous sections focused on how client software relates to a function and what the logical flows are over a pipe between the two entities.) Этот раздел сосредотачивается на различных частях хоста и как они должны взаимодействовать, для поддержания перемещения данных по USB. Эта информация может также быть интересна разработчикам устройств, чтобы понять аспекты того, что делает хост, когда клиент запрашивает передачу и как эта передача представляется(presented) устройству.
Драйвер Хост Контроллера
HCD ответственен за слежение за IRPs в продвижении и обеспечении пропускная способности USB и что максимальный кадр времени никогда не будут превышены.(HCD is responsible for tracking the IRPs in progress and ensuring that USB bandwidth and frame time maximums are never exceeded.) Когда IRPs сделаны(are made for) для канала, HCD добавляет их к списку транзакции. Когда IRP завершен, HCD сообщает запрашивающему клиенту программного обеспечения о состоянии завершения IRP. Если IRP содержал(involved) передачу данных от функции к клиенту программного обеспечения, данные были помещены в обозначенный клиентом буфер данных.(If the IRP involved data transfer from the function to the software client, the data was placed in the client-indicated data buffer.)
IRPs определены в операционной системе зависимым способом.(IRPs are defined in an operating system dependent manner.)
Драйвер Хост Контроллера (HCD- Host Controller Driver) это абстракция аппаратных средств хост контроллера и вида хост контроллера на передачу данных по USB. HCDI сталкивается со следующими требованиями:
Предоставляет абстракцию аппаратных средств хост контроллера.
Предоставляет абстракцию для передач данных хост контроллером по USB взаимосвязи.
Предоставляет абстракцию для распределения (и освобождения) ресурсов хост контроллера, для поддержания гарантируемого обслуживания устройства USB.
Представляет корневой концентратор и поведение согласно определению класса концентратора. Оно включает такую поддержку корневого концентратора, что драйвер концентратора взаимодействует с корневым концентратором, точно также как с любым другим концентратором. В частности даже при том, что корневой концентратор может быть выполнен в комбинации аппаратных средств и программного обеспечения, корневой концентратор отвечает первоначально на заданный по умолчанию адрес устройства (в зависимости от перспективы клиента), возвращает дескрипторную информацию, поддерживает наличие набора адресов устройств, и поддерживает другие запросы класса концентратора. Однако, транзакции шины могут нуждаться или нет в генерировании выполнения этого поведения возможного в данной закрытой интеграции, между хост контроллером и корневым концентратором.(However, bus transactions may or may not need to be generated to accomplish this behavior given the close integration possible between the host controller and the root hub.)
HCD предоставляет интерфейс программного обеспечения (HCDI), который осуществляет требуемые абстракции. Функция HCD должна предоставить абстракцию, которая скрывает подробности аппаратных средств хост контроллера. Ниже аппаратных средств хост контроллера - физический уровень USB и все присоединенные устройства USB.
HCD - это самый низкий уровень в стеке программного обеспечения USB. HCD имеет только одного клиента: Драйвер Универсальной Последовательной Шины (USBD- Universal Serial Bus Driver). USBD отображает(maps) запросы от многих клиентов к соответствующим HCD. Данный HCD может управлять многими хост контроллерами.
HCDI непосредственно не доступен клиенту.(The HCDI is not directly accessible from a client.) Следовательно, специфические требования интерфейса для HCDI здесь не рассматриваются.
Драйвер Универсальной Последовательной Шины
Драйвер Универсальной Последовательной Шины (USBD- Universal Serial Bus Driver) предоставляет набор механизмов с помощью которых компоненты операционной системы, обычно драйверы устройства обращаются к устройствам USB. USBD предоставляет только доступ к устройству USB. Реализация USBD зависит от операционной системы. Механизмы, предоставляемые USBD реализованы используя как соответствующие и увеличивающиеся по мере необходимости механизмы, предоставляемые средой операционной системы, в которой они выполняется.(The mechanisms provided by the USBD are implemented using as appropriate and augmenting as necessary the mechanisms provided by the operating system environment in which it runs.) Следующее обсуждение фокусируется на базисных возможностях, требуемых во всех реализациях USBD. Для специальных операции USBD внутри специфической среды, обратитесь к Руководству Среды Операционной Системы для USBD. Одиночный образец USBD направляет доступ к одному или более HCDs, что в свою очередь вызывает соединение с одним или более хост контроллером USB. Если допустимо управление установленного USBD то, оно зависит от среды операционной системы.(If allowed, how USBD instancing is managed is dependent upon the operating system environment.) Однако, с "точки зрения" клиента, USBD, с которым он связывается, управляет всеми присоединенными устройствами USB.
Драйвер USB
USBD включается как посредник в доступ к шины в двух основных случаях, во время присоединения устройства к шине в течение конфигурации и при нормальных передачах. (USBD is involved in mediating bus access at two general times while a device is attached to the bus during configuration and normal transfers.) Когда устройство присоединено и сконфигурировано, USBD включается, чтобы гарантировать, что требуемая конфигурация устройства может быть приспособлена в шине. USBD получает запросы конфигурации от конфигурирующегося программного обеспечения, которые описывают требуемую конфигурацию устройства: конечная(ые) точка(ки), тип(ы) передачи, период(ы) передач, размер(ы) данных, и т.д. USBD или принимает или отклоняет запрос конфигурации, основываясь на имеющейся пропускной способности и возможности приспособить этот тип запроса на шине. Если этот запрос принят, USBD создает канал для запросчика требуемого типа и с соответствующими ограничениями определенными для типа этой передачи.
Аспекты конфигурации USBD - обычно специфическая среда операционной системы и сложные способы конфигурации возможностей операционной системы, чтобы избежать определения дополнительных (избыточных) интерфейсов.(The configuration aspects of USBD are typically operating system environment specific and heavily leverage the configuration features of the operating system to avoid defining additional (redundant) interfaces.)
Как только устройство сконфигурировано, клиент программного обеспечения может запрашивать IRPs, чтобы переместить данные между ним и функцией конечных точек. (Once a device is configured, the software client can request IRPs to move data between it and its function endpoints.)
Физическая Топология Шины
Устройства USB физически соединены с хостом через звездообразную уровневую топологию, как показано на Рисунке 5-5. Присоединение точек USB обеспечивается специальным устройством USB, известного как концентратор. Дополнительные точки присоединения, обеспечиваемые концентратором называются портами. В хост внедрен концентратор называемый корневым концентратором. Хост обеспечивает один или более присоединеных пунктов через корневой концентратор. Устройства USB, которые обеспечивают хост дополнительными функциональными возможностями известны как функции. Чтобы предотвращать круговые присоединения, принято упорядочивание уровней,эта задача возложена на звездообразную топологию USB. Это приводит к древовидной конфигурации, иллюстрируемой Рисунком 5-5.
Рисунок 5-5. Физическая Топология USB Шины
Несколько функции могут быть упакованы вместе, что выглядит как одино физическое устройство. Например, клавиатура и шаровой указатель(trackball) могли бы быть объединенs в один пакет. Внутри пакета, каждая из функций постоянно присоединена к концентратору, он называется - внутренний концентратор, который соединен с USB. Когда множество функций объединены с концентратором в один пакете, они упоминаются как составное устройство. Для хоста составное устройство - тоже что отдельный концентратор с множеством присоединенных функций. Рисунок 5-5 также иллюстрирует составное устройство.
Физический Интерфейс
Физический интерфейс USB описан в электрической (Главе 7) и механической спецификациях (Главы 6) шины.
Физический Уровень
Физическая спецификация уровня описана в следующих подразделах.
Флуктуация Источника Данных
Источник данных может иметь некоторый разброс (флуктуацию) во временных перепадах передаваемых данных.(The source of data can have some variation (jitter) in the timing of edges of the data transmitted.) Время между любыми переходами данных это N * TPERIOD ± флуктуация времени, где ‘N’ - число битов между переходами. Флуктуация данных измеряется с той же самой емкостной загрузкой, используемой при максимального повышения и понижении времен и измеряется в точках пересечения линий данных как показано на Рисунок 7-17.(The data jitter is measured with the same capacitive load used for maximum rise and fall times and is measured at the crossover points of the data lines as shown in Figure 7-17)
Рисунок 7-17. Флуктуация Данных
Для полно скоростных передач, флуктуация времени для любых последовательных дифференциальных переходов данных должно быть в пределах 2.0 нс и в пределах 1.0 нс для любых сдвоенных дифференциальных переходов данных. (For full speed transmissions, the jitter time for any consecutive differential data transitions must be within ±2.0 ns and within ±1.0 ns for any set of paired differential data transitions.) Для низко скоростных передач, флуктуация времени для любых последовательных дифференциальных переходов данных должно быть в пределах ±25 нс и в пределах ±10 нс для любых сдвоенных дифференциальных переходов данных. Эти числа флуктуации включают временной разброс из-за дифференциальной буферной задержки и несоответствия повышения/понижения времен, внутренней флуктуация источника синхронизации и шума и других произвольных эффектов.
Флуктуация Приемника Данных
Приемники данных для всех типов устройств должны быть способны правильно декодировать дифференциальные данные при флуктуации. Чем большее одноразрядных ячеек любой край данных может занимать и все еще декодироваться, тем более надежная будет передача данных(The more of the bit cell that any data edge can occupy and still be decoded, the more reliable the data transfer will be.) Приемники данных требуются, чтобы декодировать дифференциальные переходы данных, которые происходят в окне плюс,минус от номинальной четверти одноразрядного регистра от номинальной (центрированной) позиции края данных.(Data receivers are required to decode differential data transitions that occur in a window plus and minus a nominal quarter bit cell from the nominal (centered) data edge position.) (Например может быть сформирован 4X oversampling конечный автомат DPLL, чтобы удовлетворить эти требования.)
Флуктуация будет вызвана несоответствиями задержек, обсужденными описанным выше и несоответствиями в скоростях передачи данных (частоты) источника и адресата. Запасы флуктуации данных для полного и низко скоростных режимов даны в Таблица 7-2 и Таблица 7-3. В этих таблицах представлены отдельные и общие значения для каждого источника флуктуации для последовательных (следующих) и сдвоенных переходов (These tables give the value and totals for each source of jitter for both consecutive (next) and paired transitions.) (Обратите внимание, что флуктуация компонента связанная с источником, или допуск частоты адресата был распределен соответствующему устройству (то есть, флуктуация источника включает бит, сдвинутый из-за исходной погрешности частоты при самом плохом случае интервала перехода данных)(Note that the jitter component related to the source or destination frequency tolerance has been allocated to the appropriate device (i.e., the source jitter includes bit shifts due to source frequency inaccuracy over the worst case data transition interval).) Флуктуациею выходного драйвера можно противопоставить точности часов специфически реализованного устройства, пока встречается спецификация флуктуации(The output driver jitter can be traded off against the device clock accuracy in a particular implementation as long as the jitter specification is met.)
Таблица представляющая запас флуктуации при низко скоростном режиме имеет дополнительную строку, потому что флуктуация, внесенная концентратором, к которому присоединено низко скоростное устройство, отличается от всех других устройств на пути данных (The low speed jitter budget table has an additional line in it because the jitter introduced by the hub to which the low speed device is attached is different from all the other devices in the data path.) Оставшиеся устройства функционируют с полно скоростными соглашениями передачи сигналов (хотя в низко скоростной скорости передачи данных).
Таблица 7-2. Запас Флуктуации в Полно Скоростном Режиме
HUBS |
5 |
Full Speed Freq. Tol. |
0.0025 |
||||||||||
MAX BITS/TRANS |
7 |
||||||||||||
Jitter Source |
Full Speed |
||||||||||||
Next Transition |
Paired Transition |
||||||||||||
Each (ns) |
Total (ns) |
Each (ns) |
Total (ns) |
||||||||||
Source Driver Jitter |
2.0 |
2.0 |
1.0 |
1.0 |
|||||||||
Source Freq. Tol. - Worst case |
0.21/bit |
1.5 |
0.21/bit |
3.0 |
|||||||||
Source Jitter Total |
|
3.5 |
|
4.0 |
|||||||||
Hub Jitter |
3.0 |
15.0 |
1.0 |
5.0 |
|||||||||
Jitter Spec |
|
18.5 |
|
9.0 |
|||||||||
Destination Freq. Tol. |
0.21/bit |
1.5 |
0.21/bit |
3.0 |
|||||||||
Rcv Jitter Budget |
20.0 |
|
12.0 |
||||||||||
HUBS |
5 |
Full Speed Freq. Tol. |
0.0025 |
||||||||||
MAX BITS/TRANS |
7 |
Low Speed. Freq. Tol. |
0.015 |
||||||||||
Jitter Source |
Low Speed - Upstream |
||||||||||||
Next Transition |
Paired Transition |
||||||||||||
Each (ns) |
Total (ns) |
Each (ns) |
Total (ns) |
||||||||||
Function Driver Jitter |
25.0 |
25.0 |
10.0 |
10.0 |
|||||||||
Function Freq. Tol - Worst Case |
10.0/bit |
70.0 |
10.0/bit |
140.0 |
|||||||||
Source (Function) Jitter Total |
|
95.0 |
|
150.0 |
|||||||||
Hub w/ Low Speed Device Jitter |
45.0 |
45.0 |
45.0 |
45.0 |
|||||||||
Remaining (Full Speed) Hubs' Jitter |
3.0 |
12.0 |
1.0 |
4.0 |
|||||||||
Jitter Spec |
|
152.0 |
|
200.0 |
|||||||||
Host Freq. Tol. |
1.7/bit |
12.0 |
1.7/bit |
24.0 |
|||||||||
Host Rcv Jitter Budget |
|
164.0 |
|
225.0 |
|||||||||
Таблица 7-3. Запас Флуктуации в Низко Скоростном Режиме(продолжение)
Jitter Source |
Low Speed - Downstream |
|||||||
Next Transition |
Paired Transition |
|||||||
Each (ns) |
Total (ns) |
Each (ns) |
Total (ns) |
|||||
Host Driver Jitter |
2.0 |
2.0 |
1.0 |
1.0 |
||||
Host Freq. Tol. - Worst Case |
1.7/bit |
12.0 |
1.7/bit |
24.0 |
||||
Source (Host) Jitter Total |
|
14.0 |
|
25.0 |
||||
Hub w/ Low Speed Device Jitter |
45.0 |
45.0 |
15.0 |
15.0 |
||||
Remaining (Full Speed) Hubs' Jitter |
3.0 |
12.0 |
1.0 |
4.0 |
||||
Jitter Spec |
|
75.0 |
|
45.0 |
||||
Function Freq. Tol. |
10.0/bit |
70.0 |
10.0/bit |
140.0 |
||||
Function Rcv Jitter Budget |
|
150.0 |
|
185.0 |
||||
Формат данных
Пакет установки имеет определенную USB структуру, которая размещает в пакете минимальный набор команд, требуемых для осуществления связи между хостом и устройством. Определение структуры допускает расширение определяемое продавцом для специфических команд устройства. Транзакции данных после установки не имеют никакой определенной USB структуры. Состояние транзакции также имеет определенную USB структуру. Специфические определения установки/данных передачи управления описаны в Разделе 8.5.2 и Главе 9.
USB не налагает никаких ограничений на структуру содержащую данные в потоке связи для изохронных каналов.
USB не налагает никаких ограничений на структуру содержащую данные в потоке связи для bulk каналов.
USB не налагает никаких ограничений на структуру содержащую данные в потоке связи для каналов прерывания.
Форматы Пакета
Этот раздел описывает форматы маркерных пакетов, данных, и пакетов квитирования. Поля внутри пакета отображаются в порядке, в котором биты поступают во входную шину, показанном на рисунках.
Форматы Поля Пакета
В данном разделе описываются форматы поля для маркерных пакетов, пакетов данных, и пакетов квитирования. Определение битов пакета отображаются в незакодированном формате.(Packet bit definitions are displayed in unencoded data format.) Результаты кодирования NRZI и вставки бита удалены для простоты понимания. Все пакеты имеют четкие разграничители начала и конца пакета. Начало пакета (SOP) который является частью поля SYNC, и разграничитель конца пакета (EOP) описаны в Главе 7.
Форматы Транзакции
Формат транзакции Пакета изменяется в зависимости от типа конечной точки. Имеются четыре типа конечных точек: bulk, управляющие, прерывания, и изохронные.
Формирование очереди IRPs
USBDI должен допускать очереди IRPs клиентов для данного канала. Когда IRPs возвращены клиенту, также возвращено состояние запроса. Механизм предоставляется USBD, для идентификации группы изохронных IRPs, чьи первые транзакции будут находиться в том же самом кадре.
Функции
Функция - устройство USB, которое способно передать или получить данные или управляющую информацию по шине. Функция обычно выполняется как отдельное периферийное устройство с кабелем, который подключается в порт концентратора. However, a physical package may implement multiple functions and an embedded hub with a single USB cable. Тогда оно называется составным устройством. Составное устройство появляется на хосте как концентратор с одним или более постоянно присоединяемыми устройствами USB.
Каждая функция содержит информацию о конфигурации, которая описывает ее возможности и требования к ресурсам. Прежде, чем функция может использоваться, она должна быть сконфигурирована хостом. Такая конфигурация включает в себя распределение пропускной способности USB и выбора специфических опции конфигурации функции.
Примеры функций:
Устройство для ввода координат типа мыши, планшета, или светового пера
Устройство ввода данных типа клавиатуры
Устройство вывода типа принтера
Телефонный адаптер типа ISDN
Функции с независимым питанием
Рисунок 7-27 Показывает функцию с независимым питанием. Контроллер функции(function controller) подключен или к upstream шине через регулятор малой мощности или к локальному питанию. Преимущество вышеупомянутой схемы, что здесь возможно обнаружение и перечень функции с независимым питанием, при выключеном локальном питании. Когда контроллер функции внешне подключен, максимальная мощность upstream, которую он может потреблять - одна модульная нагрузка, и блок регулирования должен выполнить ограничение тока наплыва. Количество мощности, может потреблять которую блок функции, ограничено только локальным питанием. Так как для локального питания не требуется запитывать любые downstream порты шины, не требуется и выполнять ограничение по току, плавное включение, или переключение мощности.
Функции с независимым питанием должны твердо придержаться тех же самых правил заземления и Vbus изоляции как и концентраторы с независимым питанием.
Рисунок 7-27. Функция с Независимым Питанием
Глобальное Подвешивание
Глобальное подвешивание используется, когда не требуется никакой связи где-либо на шине, и целая сеть помещается в подвешенное состояние. Хост сообщает о начале подвешивания, прекращая все передачи (включая SOF маркер). Поскольку каждое устройство на шине распознает отсутствие активности, и что шина находится в остановленном состоянии в течение соответствующего отрезка времени, оно переходит в подвешенное состояние. Поскольку концентраторы входят в состояние ожидания, они прекращают посылать низко скоростной EOP на любые downstream порты сконфигурированные для низко скоростных устройств.
Глобальное Подвешивание и Возобновление
Глобальное подвешивание инициализируется хостом, отключением downstream трафика на всей шине. Концентратор входит в состояние suspend, если он обнаруживает непрерывное состояние idle на корневой порте по крайней мере 3.0 мс. При переходе в состояние suspend, концентратор помещает повторитель в состояние WFSOP, оставляет(floats) все драйверы вывода, поддерживает статические значения всех битов управления и состояния, и сохраняет текущую информацию о состоянии для каждого из downstream портов. Подвешенный концентратор имеет выключенные часы, так что он не имеет понятие о времени и может только отвечать на переходы шины.
Возобновление работы концентратора может быть вызвано любым переходом шины на концентраторе, корневом порте или на downstream порте находящимся в состоянии enabled. Возобновление работы концентратора может также быть вызвано соединением/разъединением устройства на downstream порте в состояниях disconnected, disabled, или suspended. Если переход происходит на неблокированном downstream порте, тогда концентратор немедленно отражает переход от idle к возобновлению шины для этого порта, всем другим неблокированным downstream портам, и корневому порту. На Рисунок 11-12 показаны временные зависимости в течение последовательности возобновления, в которой устройство инициализирует пробуждение от концентратора.
Рисунок 11-12. Сигналы при Возобновлении
Имеются четыре временных параметра, которым должны придерживаться концентраторы, как показано на Рисунок 11-12. T = 0 представляет время, когда сигналы возобновления достигают порта. t1
- время, в которое концентратор должен ответить, введя возобновление на upstream порт и на всех разблокированных downstream портах. t2 это время, в которое концентратор должен прекратить инициировать возобновление вверх по иерархии на корневом порте и отражать нынешнее состояние шины , которое вводится от корневого порт на downstream портах.(is the time at which the hub must stop driving an upstream initiated resume to its root port and reflect the bus state now being driven to its root port onto its downstream ports.) Интервал t3 это время, когда концентратор должен генерировать вниз по иерархии K сигнал на устройство, которое вызвало возобновление. t4
это время, когда концентратор должен ждать, после обнаружения низко скоростного downstream EOP, пока он не сможет установить бит прерывания, указывающий, что возобновление произошло после выборочного подвешивания.
Когда устройство управляет переходом вверх по иерархии от idle к возобновлению концентратора, концентратор отвечает, вводя возобновленное (K) состояние на шину корневого порта и на все неблокированные downstream порты, включая порт, который вызвал возобновление. ( Разрешено вводить на обоих концах сегмента шины тоже самое состояние.) (It is acceptable to drive both ends of a bus segment to the same state.) После введения возобновленного состояния , концентратор начинает процесс возврата к полностью активному состоянию (например, перезапускать часы). Когда концентратор активен, он изменит(reverse) связь так, чтобы состояние K на корневом порте концентратора поддерживает K на downstream портах. (В данном случае принимается, что концентратор находящийся непосредственно над рассматриваемый концентратором получил сигнал возобновления и теперь вводит его вниз по иерархии.) Концентратор не может изменить связь быстрее чем 50 mс, ни медленнее чем 10 мс после получения возобновления с низу по иерархии. Параметр t2 также подразумевает, что концентратор должен быть полностью активен не позже чем через 10 мс после получения запроса возобновления.
Сигнал возобновления распространяется вверх по иерархии, пока не достигает хоста. Хост отражает сигнал возобновления вниз по иерархии по крайней мере 20 мс, что гарантирует, что все устройства будут иметь время, чтобы пробудиться и обнаружить переданный вниз по иерархии сигнал возобновления. Хост завершает последовательность возобновления, выводя EOP в течение двух низко скоростных времен передачи бита. EOP интерпретируется как допустимый конец пакета, заставляет все концентраторы разрушить свои связи и сообщает всем устройствам на шине, что последовательность возобновления завершена. Устройство, которое вызвало возобновление, должно ждать, пока не обнаружит EOP, который определяет, что последовательность возобновления завершилась.
Характеристики Драйвера USB
USB использует дифференциальный выходной драйвер (differential output driver) для управления сигналом данных USB на кабеле USB. Статическое колебание вывода драйвера в низком состоянии должно быть ниже VOL 0.3 В с 1.5 kW нагрузкой до 3.6 В, и в высоком состоянии должен быть выше VOH 2.8 В с 15 kW заземленной нагрузкой как проиллюстрировано в Таблица 7-4. (The static output swing of the driver in its low state must be below the VOL of 0.3 V with a 1.5 kW load to 3.6 V и in its high state must be above the VOH of 2.8 V with a 15 kW load to ground as listed in Таблице 7-4.) Колебание вывода между дифференциальным высоким и низким состоянием должны быть хорошо сбалансированы, чтобы минимизировать перекос сигнала. (The output swings between the differential high и low state must be well balanced to minimize signal skew.) Требуется управление скоростью переключения драйвера, чтобы минимизировать излучаемый шум и перекрестный разговор (Slew rate control on the driver is required to minimize the radiated noise и cross talk.) Выводы драйвера должны поддерживать возможность нахождения в третьем состоянии для работы в двунаправленной полу дуплексном режиме.(The driver’s outputs must support three-state operation to achieve bi-directional half duplex operation.) Также требуется высокий импеданс для изолирования порта от downstream устройств, которые только вставленными(hot inserted) или которые соединены, но выключены. Драйвер должен допустить напряжение на штырьках сигнала от -0.5 В до 3.8 В относительно локального заземленного эталона без повреждений (The driver must tolerate a voltage on the signal pins of -0.5 V to 3.8 V with respect to local ground reference without damage.) Он должно допустить это напряжение для 10.0 µс, в то время как драйвер активен и запущен, и допускать неопределенно состояние, когда драйвер находится в состоянии высокого импеданса. (It must tolerate this voltage for 10.0 µs while the driver is active и driving, и tolerate the condition indefinitely when the driver is in its high impedance state.)
Характеристики Низко Скоростного ( МБ) Драйвера
Низко скоростное соединение USB происходит по кабелю из неэкранированной(shielded) невитой пары с и максимальной длиной в 3 метра. Повышение и падение времени сигналов на этом кабеле должно быть большее чем 75 нс, чтобы хранить RFI эмиссию под ограничениями класса B FCC, и ограничивать менее чем 300 нс задержки синхронизации и перекосы передачи сигналов и искажения. (The rise и fall time of the signals on this cable must be greater than 75 ns to keep RFI emissions under FCC class B limits, и less than 300 ns to limit timing delays и signaling skews и distortions.) Драйвер должен достигнуть определенных статических уровней сигнала с гладким повышением и падением времени, и минимальным отражения сигнала и сглаживание при передачи по кабелю (см. Рисунок 7-3). The driver must reach the specified static signal levels with smooth rise и fall times, и minimal reflections и ringing when driving the cable. Этот кабель и драйвер используются только в сегментах сети между низко скоростными устройствами и портами, с которыми они соединены.
Рисунок 7-3. Временные Диаграммы Сигналов Низко Скоростного Драйвера
Характеристики Полно Скоростного ( МБ) Драйвера (Full Speed ( Mbs) Driver Characteristics)
Полно скоростное соединение USB происходит по кабелю из экранированной(shielded) витой пары с характеристикой импеданса (Z0) 90W ±15 % и максимальной длиной в 5 метров. Импеданс каждого из драйверов должен быть между 29 W и 44 W. Повышение на линии данных и падение времени должны быть между 4 нс и 20 нс, гладко повышаясь или падая (монотонно), и быть хорошо согласованными, чтобы минимизировать RFI эмиссию и сообщать о перекосе.(The data line rise и fall times must be between 4 ns и 20 ns, smoothly rising or falling (monotonic), и be well matched to minimize RFI emissions и signal skew.)
При CMOS реализации , импеданс драйвера будет обычно реализовываться драйвером CMOS с импедансом значительно меньше, чем его сопротивление, с дискретным добавочным резистором, составляющим равновесие (For a CMOS implementation, the driver impedance will typically be realized by a CMOS driver with an impedance significantly less than this resistance with a discrete series resistor making up the balance.) Рисунок 7-1 показывает пример того, как мог бы быть выполнен полно скоростной драйвер, используя два идентичных буфера CMOS, которые имеют выходной импеданс между 3W и 15W и два добавочных резистора 27W. Рисунок 7-2 показывает временные диаграммы полно скоростных сигналов драйвера.
Рисунок 7-1. Пример Схемы CMOS Полно Скоростного Драйвера
Рисунок 7-2. Временные Диаграммы Сигналов Полно Скоростного Драйвера
Характеристики Приемника
Дифференциальный вход приемника должен использоваться, чтобы принять сигнал данных USB. Приемник должен иметь входную чувствительность по крайней мере 200 мВ, когда оба дифференциальных входа данных находятся в диапазоне по крайней мере от 0.8 В до 2.5 В относительно локального заземленного эталона. ( The receiver must feature an input sensitivity of at least 200 mV when both differential data inputs are in the range of at least 0.8 V to 2.5 V with respect to its local ground reference.) Это называется общим диапазоном напряжения режима ввода.(This is called the common mode input voltage range.) Соответствующий прием данных также требуется, когда дифференциальные линии данных находятся вне основного диапазона режима, как показано на Рисунок 7-4. (Proper data reception is also required when the differential data lines are outside the common mode range, as shown in Рисунок 7-4.) Приемник должен допустить статические входные напряжения между -0.5 В и 3.8 В относительно локального заземленного эталона без повреждения.. (The receiver must tolerate static input voltages between ?0.5 V to 3.8 V with respect to its local ground reference without damage. В дополнение к дифференциальному приемнику, должен иметься собственный одно-входной приемник для каждой из двух линий данных (In addition to the differential receiver, there must be a single?ended receiver for each of the two data lines.) Приемники должны иметь порог переключения между 0.8 В и 2.0 В (входы ТТЛ). Рекомендуется, чтобы асимметричный приемник имел некоторый гистерезис, чтобы уменьшить чувствительность до шума. (It is recommended that the single-ended receiver have some hysteresis to reduce its sensitivity to noise.)
Рисунок 7-4. Дифференциальная Входная Чувствительность во Всем Основном Диапазоне Режима (Differential Input Sensitivity Over Entire Common Mode Range)
Характеристики Устройства
Всем устройствам USB присвоен уникальный адрес USB. Каждое устройство USB дополнительно поддерживает одну или большее количество конечных точек, с которыми хост может связываться. Все устройства USB должны поддерживать специально обозначенную конечную точку 0, по которой управление каналом USB будет присоединять устройство USB.
Связанная с Конечной точкой 0 информация, требуется, чтобы полностью описать устройство USB. Эта информация представлена следующими категориям:
Стандарт. Это - информация, чье описание является общим для всех устройств USB и включает пункты типа идентификации продавца, класс устройства, и управление питанием. Устройство, конфигурация, интерфейс, и описание конфигурации переноса конечной точки относятся к информации об устройстве. Детализированная информация про эти описатели может быть найдена в Главе 9.
Класс. Описание этой информации изменяется в зависимости от того к какому классу устройств принадлежит устройство USB.
Продавец USB. Продавец устройства USB может поместить здесь любую желаемую информацию. Формат ее не определен в этой спецификацией.
Дополнительно, каждое устройство USB несет управляющую информацию и информацию о состоянии USB. Все устройства USB поддерживают общий метод доступа через их канал управления USB.
Хост контроллер
Хост контроллер имеет доступ к списку транзакций и транслирует его в действия шины. Кроме того, хост контроллер обеспечивает механизм рапортов, с помощью которого может быть получено состояние транзакции (выполнена, задержана, остановлена, и т.д.). Хост контроллер преобразовывает транзакции в соответствующие зависимые от реализации действия, которые в результате перемещают пакеты USB по топологии шины, образованной в корневом концентраторе (The host controller converts transactions into appropriate implementation dependent activities that result in USB packets moving over the bus topology rooted in the root hub.)
Хост контроллер гарантирует, что определенные правила доступа к шине, повинуются протоколу; например, распределение меж-упаковочного времени, блокировки времени, переговоры, и т.д (The host controller ensures that the bus access rules defined by the protocol are obeyed; e.g., inter?packet timings, time-outs, babble, etc.) Интерфейс HCD обеспечивает способ с помощью которого хост контроллер участвует в следующем: позволено ли новому каналу иметь доступ к шине. Это выполнено, потому что реализации хост контроллера могут иметь ограничения / принуждения на минимальное время между транзакциями, которое они могут поддерживать при комбинациях транзакций шины (This is done because host controller implementations can have restrictions/constraints on the minimum inter?transaction times they may support for combinations of bus transactions.)
Интерфейс между списком транзакций и хост контроллером скрыт внутри HCD и в реализации хост контроллера. Хост контроллер обычно выполняется как аппаратное средство.
Хост USB
Может быть только один хост в любой USB системе. Интерфейс USB в главной компьютерной системе упоминается как хост контроллер. Хост контроллер может быть выполнен в комбинации аппаратных средств, программируемого оборудования, или программного обеспечения. Корневой концентратор(root hub) интегрирован внутрь хост системы, чтобы обеспечивать одну или большее количество точек подключения.
Дополнительная информация относительно хоста может быть найдена в Разделе 4.9 и в Главе 10, Хост USB: Аппаратные средства и Программное обеспечение.
Логический состав хоста показан на Рисунке 5-3:
Хост контроллер USB
Полное программное обеспечение системы USB (USB драйвер, драйвер хост контроллера, и программное обеспечение хоста)
Клиент
Рисунок 5-3. Состав Хоста
USB хост занимает уникальную позицию как объект координирования USB. В дополнение к особой физической позиции, хост имеет специфические обязательства что касается USB и подключенных устройств. Хост контролирует весь доступ к USB. Устройство USB получает доступ к шине только, когда доступ ему предоставит хост.(A USB device only gains access to the bus by being granted access by the host) Хост также ответственен за текущий контроль(monitoring) топологии USB.
Для полного рассмотрения хоста и режимов его работы, обратитесь к Главе 10, USB Хост: Программное обеспечение и оборудование.
Хост USB: Аппаратное и Программное обеспечение
Хост USB взаимодействует с устройствами USB через хост контроллер. Хост ответственен за следующее:
Обнаружение присоединения и удаления устройств USB
Управление потоком управления между хостом и устройствами USB
Управление потоком данных между хостом и устройствами USB
Сбор статистики о состоянии и активности
Обеспечение подачи ограниченного количества мощности на присоединенные устройства USB
Программное обеспечение системы USB на хосте управляет взаимодействиями между устройствами USB и хост-основанным программным обеспечением устройства. Имеются пять областей взаимодействия между программным обеспечением системы USB и программным обеспечением устройства, они следующие:
Перенумерация Устройств и конфигурация
Изохронные передачи данных
Асинхронные передачи данных
Управление питанием
Информация об устройстве и управление шины
Индикация Overcurrent supply current
Из соображений безопасности, все локально питающиеся концентраторы должны выполнить ограничение по току на своих downstream портах. Ни при каких условиях не может быть выдано больше чем 25 VA из любого порта концентратора USB. ( Фактическая точка сверхтока может быть ниже чем это изображено)(The actual overcurrent trip point may be lower than this figure). Если условие сверхтока происходит, даже если только одно мгновение, об этом должно быть сообщено на контроллер концентратора. Это выполняется через состояние сверхтока, которое отражается в запросах концентратора. Обнаруженное состояние сверхтока, входит в обнаружение сверхтока и очищается запросом хоста или после сброса.(The overcurrent detect state is entered on overcurrent detect and cleared by a host request or upon reset.) Обнаружение сверхтока должно отключить, все задетые(affected) порты. Если условие сверхтока вызвало постоянное разъединение мощности (типа разрыва плавкой перемычки), концентратор должен сообщить об этом появлением сброса или включением питания.
Защита от сверхтока может быть выполнена во всех downstream портах вместе, или для каждого порта в отдельности. Возможно, что порты будут разбиты на две или более подгруппы, каждый с собственной схемой защиты от сверхтока.
Информация об Архитектуре и Работы Концентратора(Hub Information Architecture and Operation)
Дескрипторы Концентратора, а также Состояние и Управление Концентратора/Порта доступны через создаваемый по умолчанию канал. Когда концентратор обнаруживает изменение на порте или когда концентратор изменяет собственное состояние, данные конечной точки Изменения Состояния передаются на хост в форме, определенной в Разделе 11.8.3.
USB концентраторы обнаруживают изменения в состоянии порта. Устройства, присоединенные к портам концентратора могут вызывать различные аппаратные события. Кроме этого, системное программное обеспечение хоста может вызывать изменения состояния концентратора, посылая команды концентратору. Так как имеются два источника изменений концентратора, концентраторы USB сообщают измененную информацию для каждого из вызванных аппаратно событий. Концентратор продолжает сообщать изменение состояния пока опрошенное специфическое событие не было успешно подтверждено хостом. При использовании этого механизма сообщений, системное программное обеспечение определяет те, изменения которые произошли начиная с последнего события, сообщенного концентратором. Этот подход делает возможным минимизировать информацию о состоянии устройства, которую должно нести системное программное обеспечение.
Рисунок 11-18. Связь Состояний, Изменения Состояний, и Информации Управления от Состояния Устройства
Программное обеспечение хоста использует канал прерывания, связанный с конечной точкой Изменения Состояния, чтобы обнаружить изменения в состоянии порта и концентратора.
Инициализация
Особенности инициализации USBD зависят от операционной системы. Когда инициализирована часть USB управляющая USBD, информация управления, для этой части USB также создана. Часть этой информации управления - заданный по умолчанию адрес устройства и создаваемый по умолчанию канал.
Всякий раз, когда устройство присоединено к USB, оно отвечает на специальный адрес известный как заданный по умолчанию адрес (обратитесь к Главе 9) пока драйвер концентратора не назначит ему уникальный адрес. Для того чтобы система USB, взаимодействовала с новым устройством, устройство с заданным по умолчанию адресом для этой части USB и этот заданный по умолчанию адрес устройства создаваемого по умолчанию канал, должен всегда быть доступен драйверу концентратора всякий раз, когда устройство присоединено. Заданный по умолчанию адрес устройства и создаваемый по умолчанию канал создаются системой USB, когда инициализировалась новая USB.
Инициализация Маркером SETUP
Передачи Управления используют маркер SETUP для инициализации битов последовательности хоста и функции. На Рисунок 8-15 показан хост, выдающий пакет SETUP к функции, за которым следует OUT транзакция. Числа в кругах отображают биты последовательности передатчика и приемника. Функция должна принять данные и подтвердить транзакцию с помощью ACK. Когда функция принимает транзакцию, она должна сбросить свой бит последовательности так, чтобы биты последовательности хоста и функции были равны 1 по окончанию транзакции SETUP.
Рисунок 8-15. Инициализация SETUP
Интерфейс
Этот дескриптор описывает специфический интерфейс в случае связанной конфигурации (This descriptor describes a specific interface provided by the associated configuration.) Конфигурация обеспечивает один или более интерфейсов, каждый с собственными дескрипторами конечной точки, описывающими уникальный набор конечных точек внутри конфигурации. Когда конфигурация поддерживает более чем один интерфейс, конечные точки для специфического интерфейса следуют сразу за дескриптором интерфейса в данных, возвращаемых запросом Get Configuration. Дескриптор интерфейса всегда возвращается как часть дескриптора конфигурации. К нему нельзя непосредственно обращаться запросом Get или Set Descriptor.
Интерфейс может включать альтернативные установки, которые позволяют изменять конечные точки и-или их характеристики после того, как устройство было сконфигурировано. В настройке по умолчанию для интерфейса, альтернатива всегда установлена в нуль. Запрос Set Interface используется, чтобы выбрать альтернативную установку или возвратиться к настройке по умолчанию. Запрос Get Interface возвращает выбранную альтернативную установку.
Альтернативные установки позволяют части конфигурации устройства быть измененными, в то время как другие интерфейсы остаются в работе. Если конфигурация имеет альтернативные установки для одного или более интерфейсов, дескриптор отдельного интерфейса и связанные с ним конечные точки включаются в каждую установку.
Если конфигурация устройства обеспечивает один интерфейс с двумя альтернативными установками, дескриптор конфигурации будет сопровождаться дескриптором интерфейса с полями bInterfaceNumber
и bAlternateSetting установленными в нуль и затем дескрипторами конечной точки для этой установки, сопровождаться другим дескриптором интерфейса и связанными с ним дескрипторами конечной точки. (If a device configuration supported a single interface with two alternate settings, the configuration descriptor would be followed by an interface descriptor with the bInterfaceNumber
and bAlternateSetting fields set to zero and then the endpoint descriptors for that setting, followed by another interface descriptor and its associated endpoint descriptors.) В дескрипторе второго интерфейса поле bInterfaceNumber, было бы также установлено в нуль, но поле bAlternateSetting
дескриптора второго интерфейса, было бы установлено в единицу.
Если интерфейс использует только нулевую конечной точки, никакие дескрипторы конечной точки не следуют за дескриптором интерфейса, и интерфейс определяет интерфейс запроса(the interface identifies a request interface), который использует создаваемый по умолчанию канал, присоединенный к нулевой конечной точки. В этом случае, поле bNumEndpoints
должно быть установлено в нуль.
Дескриптор интерфейса никогда не включает нулевую конечную точку в число конечных точек.
Смещение |
Поле |
Размер |
Значение |
Описание |
0 |
bLength |
1 |
Number |
Размер этого дескриптора в байтах |
1 |
bDescriptorType |
1 |
Constant |
Тип Дескриптора INTERFACE |
2 |
bInterfaceNumber |
1 |
Number |
Номер интерфейса. Zero-based value, идентифицирующее индекс в массиве параллельных интерфейсов, обеспечиваемых этой конфигурацией. |
3 |
bAlternateSetting |
1 |
Number |
Значение, используемое для выбора альтернативной установки определяемого предшествующим полем интерфейса |
4 |
bNumEndpoints |
1 |
Number |
Число конечных точек, используемых этим интерфейсом (не включая нулевую конечную точку). Если это значение 0, этот интерфейс использует только нулевую конечную точку. |
5 |
bInterfaceClass |
1 |
Class |
Код Класса (назначенный USB) Если это поле сброшено в 0, интерфейс не принадлежит никакому определенному USB классу устройств. Если это поле установлено в 0xFF, класс интерфейса определяется продавцом. Все другие значения зарезервированы для назначения USB. |
6 |
bInterfaceSubClass |
1 |
SubClass |
Код Подкласса (назначенный USB). Эти коды определяются значением поля bInterfaceClass. Если поле bInterfaceClass сброшено в 0, это поле должно также быть сброшено в 0. Если поле bInterfaceClass не установлено к 0xFF, все значения зарезервированы для назначения USB. |
Смещение |
Поле |
Размер |
Значение |
Описание |
7 |
bInterfaceProtocol |
1 |
Protocol |
Код Протокола (назначенный USB). Эти коды определяются значением полей bInterfaceClass и bInterfaceSubClass. Если интерфейс поддерживает запросы определяемые классом, этот код определяет протоколы, которые устройство использует как определено спецификацией класса устройства. Если это поле сброшено в 0, устройство не использует протокол определяемый классом на этом интерфейсе. Если это поле установлено к 0xFF, устройство использует для этого интерфейса протокол определенный продавцом. |
8 |
iInterface |
1 |
Index |
Индекс строкового дескриптора, описывающего этот интерфейс |
Использование Драйвера
Полно скоростные буфера используются на upstream портах (к хосту) всех концентраторов и полно скоростных функций. Все устройства с концентраторами должны быть полно скоростными устройствами. Полно скоростной драйвер будет использоваться, чтобы послать данные в обоих и скорости низко скоростных передач данных.(A full speed driver will be used to send data at both и low speed data rates.) Однако, передача сигналов всегда использует полно скоростные соглашения передачи сигналов (обратитесь к Таблица 7-1) и границы скорости.(However, the signaling always uses full speed signaling conventions (refer to Таблица 7-1) и edge rates.) Выполнение при скорости низко скоростных передач данных не изменяет характеристики драйвера.
Низко скоростные буфера используются на upstream портах низко скоростных функций. Downstream порты всех концентраторов (включая хост) нужны для обеспечения обеих характеристик драйвера, таким образом любой тип устройств может быть подключен к этим портам (см. Рисунок 7-5 и Рисунок 7-6). Низко скоростные драйверы только посылают со скоростью низко скоростной передачи данных, используя низко скоростные соглашения передачи сигналов (обратитесь к Таблица 7-1) и границы скорости.(Low speed drivers only send at the low speed data rate using low speed signaling conventions и edge rates.)
Использование Интерфейса(ов) и Конечной точки
Когда класс устройств стандартизирован, должны быть включены в определение класса устройства интерфейсы, используемые устройствами, и то, как используются конечные точки. Устройства могут далее расширять определение класса частными возможностями, пока они удовлетворяют основному определению класса.