Изменение Конфигурации Устройства

Сервисы Управления Конфигурации позволяют конфигурирующему программному обеспечению заменить конфигурацию устройства USB на другую конфигурацию из набора конфигураций, перечисленных в устройстве. Операция завершается успешно, если скорости передачи данных, используемые всеми конечными точками в новой конфигурации удовлетворяют возможностям USB с текущим расписанием. Если новая конфигурация отклонена, остается предыдущая конфигурация.

Сервисы Управления Конфигурации позволяют конфигурирующему программному обеспечению возвратить устройство USB в не сконфигурированное состояние.

Изохронные(ISO)Транзакции

Транзакции ISO имеют фазу маркера и данных, но нет фазы квитирования, как показано на Рисунке 8-14. Хост выдает или маркер IN или маркер OUT, за которым следует фаза данных, в которой конечная точка (для IN) или хост (для OUT) передает данные. Транзакции ISO не поддерживают фазу квитирования или возможность повторной передачи.

Рисунок 8-14.   Формат Изохронной Транзакции

Транзакции ISO не поддерживают последовательность переключения, и PID данных -  всегда DATA0. Приемник пакета не анализирует PID данных.

Изохронные(Isochronous) Передачи

Изохронные данные непрерывны и при создании в реальном масштабе времени и при передачи и при потреблении. Timing related information is implied by the steady rate at which isochronous data is received and transferred.  Изохронные данные должны доставляться в скорости их поступления, чтобы поддержать синхронизацию.  В дополнение к скорости доставки, изохронные данные могут быть также чувствительны к задержкам доставки. For isochronous pipes, the bandwidth required is typically based upon the sampling characteristics of the associated function.  Требуемое время отклика связано с наличием буферизации в каждой конечной точке.

Типичный пример изохронных данных речевая информация. Если скорость поставки этих потоков данных не поддерживается, произойдут сбои в потоке данных  благодаря переполнению или обнулению буферов или кадров. Even if data is delivered at the appropriate rate, delivery delays may degrade applications requiring real-time turn around, such as telephony-based audio conferencing. 

Своевременная поставка изохронных данных обеспечена за счет возможных случайных потерь в потоке данных. Другими словами, любая ошибка в электрической передаче не исправляется аппаратно путем повторений. На практике, средняя частота передачи ошибочных битов в USB шине, как ожидается,  будет достаточно маленькой, что не будет проблемой. Изохронные потоки данных в USB занимают выделенную часть пропускной способности USB шины, это гарантирует, что данные могут доставляться с нужной скоростью. USB разработана так, чтобы были минимальные задержки изохронных передач данных.

Изохронные Передачи

В не-USB среде, изохронные передачи имеют тесную связь с постоянной скоростью и терпимыми к ошибкам передачами. В USB среде, запрашивая изохронный тип передачи запросчик обеспечивается следующим:(In the USB environment, requesting an isochronous transfer type provides the requester with the following)

Гарантируемый доступ к пропускной способности USB с ограниченным временем отклика

Пока канал обеспечивается  данными, гарантируется постоянная скорость передачи данных через канал

В случае неудачной поставки из-за ошибки, никаких повторении поставки данных не предпринимается

В то время как изохронный тип передачи USB разработан для поддержки изохронных источников и адресатов,но не требуется, чтобы программное обеспечение, использующее этот тип передачи фактически было изохронно, в порядке использования этого типа передачи. (While the USB isochronous transfer type is designed to support isochronous sources and destinations, it is not required that software using this transfer type actually be isochronous in order to use the transfer type) Раздел 5.10 предоставляет больше подробностей о специальных рассмотрениях обработки изохронных данных в USB.

Изохронные Передачи Данных

Каждый буфер, поставленный в очередь для изохронного канала требуется, чтобы быть видимым как поток выборок.(Each buffer queued for an isochronous pipe is required to be viewable as a stream of samples.) Как и для всех передач по каналу, клиент устанавливает стратегию для использования этого изохронного канала, включая соответствующий интервал обслуживания для этого клиента. Потерянные или отсутствующие байты, которые обнаружены на входе, и проблемы передачи, которые отмечены на выходе, указываются клиенту.

Клиент занимая очередь первого буфера, запускает сервис потока в канале.(The client queues a first buffer, starting the pipe streaming service.) Чтобы поддерживать непрерывную поточную модель передачи, используемую во всех изохронных передачах, очереди клиентов дополнительно буферируются перед, удалением из текущего буфера.(To maintain the continuous streaming transfer model used in all isochronous transfers, the client queues an additional buffer before the current buffer is retired.)

Требуется, чтобы USBD было разрешено предоставить просмотр потока выборок потоку данных клиента.(The USBD is required to be able to provide a sample stream view of the client’s data stream.) Другими словами, при использовании метода синхронизации определенного клиентом, точное пакетирование данных скрыто от клиента.(In other words, using the client’s specified method of synchronization, the precise packetization of the data is hidden from the client.) Дополнительно, данная транзакция всегда полностью содержится внутри некоторого буфера данных клиента.

Для выходного канала, клиент предоставляет буфер данных. USBD распределяет данные по кадрам в течении периода обслуживания, используя выбранный клиентом метод синхронизации.

Для входного канала, клиент должен предоставить пустой буфер, достаточно большой, чтобы удержать максимальное число байтов, поставляемых в период обслуживания устройством клиента. Система USB разделяет определенную USB упаковочную информацию от потока так, что байты непрерывны в буфере клиента.(The USB system strips USB defined packaging information from the stream such that bytes are contiguous in the client’s buffer.) При указании на отсутствие или на недопустимые байты, USBD оставляет пространство, которое байты заняли бы на в буфере и идентифицируют ошибку. Одно из следствий использования метода без синхронизации, - это то, что это зарезервированное место учитывается в максимальном размере пакета. Уведомление об удалении буфера происходит, когда завершается IRP. Обратите внимание, что входной буфер не должен быть полным когда возвращается клиенту.

USBD необязательно может предоставлять дополнительные просмотры изохронных потоков данных. Также требуется, чтобы USBD  был способен предоставить просмотр потока пакетов потоку данных клиента.

Изохронные Устройства

USB включает каркас для изохронных устройств, который определяет Типы Синхронизации(Synchronization Types), как изохронные конечные точки обеспечивают обратную связь скорости передачи данных, и как они могут быть соединены вместе.(USB includes a framework for isochronous devices which defines Synchronization Types, how isochronous endpoints provide data rate feedback, and how they can be connected together.) Изохронные устройства включают выборку аналоговых устройств; например, звуковые и телефонные устройства, и синхронные устройства данных.(Isochronous devices include sampled analog devices; for example, audio and telephony devices, and synchronous data devices.) Тип Синхронизации классифицирует конечную точку согласно ее возможности по синхронизации скорость передачи данных со скоростью передачи данных конечной точки, с которой она соединена. Обратная связь обеспечивается точным указанием требуемой скорости передачи данных, относительно SOF частоты. Способность создавать соединения зависит от качества соединения(make), которое требуется, типа синхронизации конечной точки, и возможности приложения хоста, которое создает соединение. Дополнительное, в зависимости от приложения может потребоваться информация определяющая Класса Устройства.(Additional Device Class-specific information may be required, depending on the application.)

Следует обратить внимание, что термин “данные” используется в очень широком смысле , и может относиться к данным, который представляет выборку(sampled) аналоговой информации (подобно звуку), или это может быть большее количество абстрактной информации. “Скорость передачи данных” относится к скорости, в которой аналоговая информация является простой, или к скорости, в которой данные синхронизированы.(“Data rate” refers to the rate at which analog information is sampled, or the rate at which data is clocked.)

Следующая информация определяет требования к соединению изохронных конечных точек(The following information is required in order to determine how to connect isochronous endpoints):

Тип Синхронизации

-         Асинхронный - несинхронизированный, хотя стоки обеспечивают обратную связь скорости передачи данных (Asynchronous - unsynchronized, although sinks provide data rate feedback)

-         Синхронный - синхронизированный к SOF USB

-         Адаптивный - используется синхронизированная обратная связь или информация о скорости передачи упреждающих данных(Adaptive - synchronized using feedback or feedforward data rate information)

Доступные скорости передачи данных

Доступные форматы данных

Тип Синхронизации и информация о скорости передачи данных необходимы, чтобы определить, существует ли точное соответствие скоростей передачи данных между источником и стоком(sink), или существует ли приемлемый процесс преобразования, который позволил бы источнику быть соединенным со стоком. За это ответственно приложение, которое определяет, может ли обеспечиваться соединение внутри доступных обрабатываемых ресурсов и других ограничений (типа задержки) (It is the responsibility of the application to determine whether the connection can be supported within available processing resources and other constraints.) Специфические классы устройства USB определяют, как описать Тип Синхронизации и информацию о скорости передачи данных.

Соответствие формата данных и преобразование также требуется для соединения, но это - не уникальное требование для изохронных соединений. Подробности относительно преобразования формата могут быть найдены в других документах, связанных со специфическими форматами.

Изоляция Питания

Рисунок 7-24 Основывается на условии того, что локальное питание совместно с upstream и downstream портами используют общую землю. Vbus, однако, изолирован от Vbus порта upstream. Имеется дополнительное требование, чтобы земля корпуса (если существует только один) концентратора с независимым питанием была изолирована DC от земли сигнала USB. Земля корпуса соединяется с землей 120 Vac силовым кабелем, и нет никакой гарантии, что земля AC двух различных выводов находится в том же самом потенциале. Отказ соблюдать эту предосторожность может приводить к большим низко частотным токам, проходящим по земле USB.

Эксплуатация Канала USBD

Каналы - это метод, с помощью которого конечная точка устройства связана с объектом программного обеспечения хоста. Каналы принадлежат точно одному такому объекту на хосте. Хотя базисная концепция канала - одинаков для всех независимо от владельца, некоторое различие возможностей, предоставляемых клиенту USBD, происходят в двух группах каналов:

Создаваемые по умолчанию каналы, которые принадлежат и управляются USBD

Все другие каналы, которые принадлежат и управляются клиентами USBD

К создаваемым по умолчанию каналам никогда непосредственно не обращаются клиенты, хотя они(каналы) часто используются, чтобы выполнять некоторую часть клиентских запросов, переданных через механизмы команды.

Электрические параметры

В USB шине сигнал и мощность передаются по четырехпроводному кабелю, показанному на Рисунке 4-2. Передача сигналов происходит по двум проводам и только от точки к точке. Сигналы в каждом сегменте являются дифференциальными и перемещаются по кабелю с 90 W встроенным импедансом(The signals on each segment are differentially driven into a cable of 90 W intrinsic impedance.) Чувствительность дифференциального приемника шинных сигналов должна быть не менее 200 мВ что соответствует обычному режиму отказов.

Имеются два режима передачи сигналов. Полно скоростной побитный режим USB передачи информации со скоростью 12 Мб. Также определен ограниченный по возможности низко скоростной режим передачи сигналов, в 1.5 Мб.  Низко скоростной режим позволяет работать при меньшем уровне защиты от электромагнитных помех(EMI).  Оба режима могут одновременно обеспечиваться в той же самой USB системе с помощью переключения режима между передачами в устройстве.  Низко скоростной режим определен, чтобы поддерживать ограниченное число низко скоростных устройств типа мышей, так как более общее его использование ухудшило бы производительность шины. 

Синхронизация передается закодировано наряду с дифференциальными данными. Синхронизация кодируется схемой - NRZI с заполнением бит, чтобы гарантировать правильную передачу(adequate transitions). SYNC поле предшествует каждому пакету, чтобы позволить приемнику(ам) синхронизировать свои частоты восстанавливаемых бит(bit recovery clocks).

Рисунок 4-2. USB Кабель

Проводники VBus и GND служат для подводки питания (+5В) к устройствам, которые запитываются от шины. USB позволяет иметь кабельный сегмент длиной до нескольких метров,  выбор соответствующего датчика проводника соответствует определенному снижению IR и другим атрибутам типа бюджета мощности устройства и кабельной гибкости.(USB allows cable segments of variable lengths up to several meters by choosing the appropriate conductor gauge to match the specified IR drop and other attributes such as device power budget and cable flexibility)Чтобы обеспечивать гарантируемые входные уровни напряжения и соответствующий импеданс, используются согласующие сопротивления(biased termination) на каждом конце кабеля.  Согласующие сопротивления также разрешают обнаружение  присоединений и отсоединений в каждом порте и дифференцируют между быстродействующими и низко скоростными устройства. (The terminations also permit the detection of attach and detach at each port and differentiate between full speed and low speed devices. 

)

Электрическое Рассмотрение Интерфейса

Хост обеспечивает мощностью присоединенные к корневому концентратору устройства USB. Количество мощности, предоставляемой порту определено в обсуждении концентраторов в Главе 11.

Кадр Сигнала начала блока (Synch)

Этот запрос используется, чтобы установить и затем сообщать кадр синхронизации конечной точки(This request is used to set and then report an endpoint’s synchronization frame.)

bmRequestType		bRequest		wValue		wIndex		wLength		Данные
00000010B		synch_frame		Нуль		Конечная точка		Два		Номер Кадра

Когда конечная точка поддерживает изохронные передачи, конечная точка может также требовать изменить размер по кадровой передачи согласно специфическому шаблону.(When an endpoint supports isochronous transfers, the endpoint may also require per frame transfers to vary in size according to a specific pattern.) Хост и конечная точка должен договориться о том, в каком кадре начать повторять шаблон.(The host and the endpoint must agree on which frame the repeating pattern begins.) Этот запрос заставляет конечную точку начинать контролировать номер SOF кадра, чтобы проследить позицию данного кадра в шаблоне.  Номер кадра, в котором начался шаблон,  возвращается хосту. Этот тот номер кадра, который передан конечной точке последним SOF до первого кадра шаблона.

Это значение используется только в изохронных передачах данных, использующих неявную синхронизацию шаблона. Если конечная точка не изохронная или не использует этот метод, этот запрос не обеспечивается конечной точкой и возвращает останов.

Начальный кадр сбрасывается в нуль сбросом устройства или,  конфигурируя конечную точку через запрос SetConfiguration или SetInterface.

Каналы

USB канал - соединение между конечной точкой на устройстве и программным обеспечением на хосте. Каналы представляют возможность перемещаться данным между программным обеспечением на хосте через буфер памяти и конечной точкой на устройстве.  Есть два различных, взаимно исключающих, режима связи в канале:

Поток. Данные, перемещающиеся через канал не имеют никакой определенной USB структуры.

Сообщение. Данные, перемещающиеся через канал имеют некоторую определенную USB структуру.

USB не интерпретирует содержание данных, которые она доставляет по каналу. Даже при том, что канал сообщений требует, чтобы структура данных была согласована с определением USB, содержание данных не интерпретируется USB.

Дополнительно, каналы связаны с :

Требованием доступа на шине USB и использования пропускной способности.

Тип передачи.

Характеристики связанные с конечной точкой типа направление и максимальные размеры полезной нагрузки данных (The associated endpoint’s characteristics such as directional ity and maximum data payload sizes). Полезная нагрузка данных(The data payload) - данные, которые переносятся в полях данных, пакета данных внутри транзакции шины (как определено в Главе 8).

Каналы появляются, когда устройство USB сконфигурировано. Так как Конечная Точка 0 всегда сконфигурирована, как только устройство включается, всегда есть канал для Конечной Точки 0. Этот канал называется Создаваемый по Умолчанию Канал. Этот канал используется программным обеспечением системы, чтобы осуществить идентификацию устройства и определить требования к конфигурации, и сконфигурировать устройство(This pipe is used by system software to determine device identification and configuration requirements, and to configure the device). Создаваемый по Умолчанию Канал может также использоваться  специфически программным обеспечением устройства после того, как устройство сконфигурировано. Программное обеспечение системы USB сохраняет право “монопольного использования” Создаваемого по Умолчанию Канала и добивается не(!!!) использования канала другим клиентским программным обеспечением(USB system software retains “ownership” of the Default Pipe and mediates use of the pipe by other client software.)

Клиентское программного обеспечения обычно запрашивает передачу данных в канале с помощью Пакетов Запроса Ввода - Вывода (IRPs) и затем или ждет или сообщает что они завершены (A software client normally requests data transfers via I/O Request Packets (IRPs) to a pipe and then either waits or is notified when they are completed). Подробности относительно IRPs определены в операционной системе специфическим способом. Эта спецификация использует термин простого обращения к запросу идентификации клиентским программным обеспечением для перемещения данных между собой (хостом) и конечной точкой устройства в соответствующем направлении(This specification uses the term to simply refer to an identifiable request by a software client to move data between itself (on the host) and an endpoint of a device in an appropriate direction). Клиентское программного обеспечения может заставлять канал возвратить все ожидающие обработки IRPs, если это требуется. Клиентскому программному обеспечению сообщают, что IRP завершен, когда транзакции шины, связанные с ним завершены или успешно или из-за ошибок.

Если нет никаких задержанных(pending) IRPs или движения в канале, то канал неактивен и хост контроллер не будет выполнять никаких действие относительно канала; то есть, конечная точка для такого канала не будет видна любыми транзакциями шины направленными к ней. Какие либо действия будут выполняться шиной связанные с каналом тогда, когда IRPs - задержаны для этого канала.

Если в не-изохронном канале происходит условие ОСТАНОВА(STALL) (обратитесь к Главе 8) или происходят три ошибки на шине в любом пакете IRP, IRP отменяется/удаляется, все ожидающие обработки IRPs также удаляются, и никакой последующие IRPs не принимаются, пока клиентское программного обеспечения не восстановится в рабочее состояния (в зависимости от способа заложенного при разработки) и подтвердит ОСТАНОВ(STALL) или условие ошибки через вызов USBD. Соответствующее состояние информирует клиентское программного обеспечения касательно специфического результата IRP для версий ошибки ОСТАНОВА (обратитесь к Главе 10)(An appropriate status informs the software client of the specific IRP result for error versus STALL ).  Поведение при изохронном канале описано в Разделе 5.6.



IRP может требовать, чтобы несколько полезных нагрузок данных чтобы переместить данные клиента по шины (An IRP may require multiple data payloads to move the client data over the bus). Все данные заказанные IRP разбиваются на пакеты, все кроме последнего будут иметь максимально возможный размер пакета, последний содержит остаток от полного IRP. Рассмотрим описание каждого специфического типа передачи более подробно. Для такого IRP, короткие входные пакеты (то есть, меньшие, чем максимально установленый размер полезной нагрузки данных) полностью не заполняются,  IRP буфер данных может иметь одно из двух возможных значений в зависимости от того что ожидает клиент(For such an IRP, short packets (i.e., less than maximum sized data payloads) on input that do not completely fill an IRP data buffer can have one of two possible meanings depending upon the expectations of a client).

Клиент может ожидать переменную с размером данных в IRP(A client can expect a variable sized amount of data in an IRP). В этом случае, короткий пакет, который не заполнит буфер данных IRP может использоваться просто как межзонный(inband) разделитель, чтобы указать “ конец модуля данных”.(In this case, a short packet that does not fill an IRP data buffer can be used simply as an inband delimiter to indicate “end of unit of data.” ) IRP нужно удалить без ошибки, и хост контроллер должен перейти к следующему IRP.

Клиент может ожидать определенное по размеру количество данных. В этом случае, короткий пакет, который не заполнит буфер данных IRP - индицирует ошибку. IRP нужно удалить, канал должен быть остановлен, и любые задержанные IRPs связанные с каналом должны также удаляться.

Так как хост контроллер должен вести себя по-разному в двух случаях и он не может знать сам какой способ поведения выбрать для данного IRP, поэтому возможно указать в IRP желаемое поведение клиента.

Конечная точка может сообщать хосту, что она занята, отвечая NAK. NAKs не используются как условие удаления при возврате IRP клиентскому программному обеспечению.(NAKs are not used as a retire condition for returning an IRP to a software client.) Можно столкнуться с любом числом NAKs в течении обработки данного IRP. Ответ NAK не означает ошибку в транзакции и не считается одной из трех ошибок, описанных выше.

Каналы Клиентов

Любой канал, не принадлежащий и не управляемый USBD может принадлежать и управляться клиентом USBD. С точки зрения USBD, канал принадлежит одиночному клиенту. Фактически, совместная группа клиентов может управлять предоставленным каналом, они ведут себя как одиночная координированная сущность при использовании канала.

Клиент ответственен за обеспечение размера буфера, требуемого для обслуживания скорости передачи данных в канале внутри интервала обслуживания, достижимого клиентом. Дополнительные требования буферизации для рабочей области определены системой USB.

Каналы Сообщений

Каналы Сообщений взаимодействуют с конечной точкой не так, как потоки в каналах. Сначала, хост посылает запрос устройству USB. Этот запрос сопровождается передачей(ами) данных в соответствующем направлении. В заключение, следует несколько позже стадия состояния являющаяся ответом от конечной точки(Finally, a status stage follows at some later time by a response from the endpoint.) Чтобы разместить образец запроса/данных/состояния, каналы сообщений делают поток связи структурированным, что позволяет командам быть достоверно идентифицированными и сообщенными (In order to accommodate the request / data / status paradigm, message pipes impose a structure on the communication flow which allows commands to be reliably identified and communicated). Каналы Сообщений позволяют потоку связи иметь два направления, хотя в потоке связи может преобладать и одно направление. Создаваемый по умолчанию канала с Конечной точки 0, является всегда каналом сообщений.

Программное обеспечение системы USB гарантирует, что множество запросов не будут одновременно посланы конечной точке. Во время обращения к конечной точке требуется только один сервис запроса сообщения(An endpoint is only required to service a single message request at a time per endpoint). Несколько клиентских программных обеспечений на хосте могут делать запросы через Создаваемый по умолчанию канал, но они посылают их конечной точке в порядке "первым пришел", "первым вышел". Конечная точка может управлять потоком информации при перемещении данных и фазами состояния, основанных на способности ответить на транзакции хоста (обратитесь к Главе 8 для более подробного ознакомления)(An endpoint can control the flow of information during the data and status stages based on its ability to respond to the host transactions).

Конечной точке обычно не будет послано следующее сообщение от хоста, пока обработка текущего сообщения в конечной точке не будет завершено. Однако, имеются условия ошибки, в следствии чего передача сообщения может быть прервана хостом, и конечной точке может быть послано новое сообщение преждевременно (в зависимости от планов ). В зависимости от планов программного обеспечения, управляющего каналом сообщения, при ошибке в некоторой части IRP удаляется текущий IRP и все поставленные в очередь IRPs. Клиентскому программному обеспечению, которое запросило IRP, сообщают о завершении IRP с индикацией соответствующей ошибки.

Канал сообщений к устройству требует один номер конечной точки устройства в обоих направлениях (Входные(IN) и Выходные(OUT) маркеры). USB не позволяет каналу сообщений быть связанным с различными номерами конечной точки для каждого направления.

Каналы Сообщений поддерживают передачи типа управления, объясняемые ниже.

Категории Ошибок в Пакете

USB использует три механизма обнаружения ошибок: нарушения вставки бита, контроль битов PID, и CRC. Нарушение вставки бит существует, если приемник пакета обнаруживает передачу последовательно семи или более бит без разделителя (J -> K или K -> J), обнаруживаемых на физических линиях D+ и D-, между началом и концом пакета. Ошибка PID существует, если четыре контрольные биты PID не соответствуют битам идентификатора пакета. Ошибка CRC существует, если остаток вычисленной контрольной суммы принятого пакета не равен нулю.

За исключением маркера SOF, любой разрушенный пакет игнорируется приемником и отбрасываются любые данные или другая информация полей которая пришла с пакетом.  В Таблица 8-6 перечислены механизмы обнаружения ошибок, типы пакетов, к которым они применяются, и соответствующий ответ приемника пакета.

Таблица 8-6.  Типы Ошибок в Пакете

Поле		Ошибка		Действие
PID		Проверка PID, Вставка бит		Игнорирование пакета
Адрес		Вставка бит, CRC Адреса		Игнорирование маркера
Номер Кадра		Вставка бит, CRC Номера Кадра		Игнорирование поля Номера Кадра
Данные		Вставка бит, CRC Данных		Отбрасывание данных

Классы Устройств

Требования по мощности источников и стоков различных классов устройства может быть упрощена с введением концепции нагрузки на модуль. Нагрузка на модуль определена в 100 мA.

USB разделяет устройства по тому к какой категории по потреблению мощности они относятся; существуют следующие категории:

Питающиеся от шины концентраторы- Потребляют всю мощность любыми внутренними функциям и downstream портами от мощности штырьков коннектора USB. Могут составлять одну подключенную нагрузку и общее количество пяти нагрузок, которые разделены между любыми внедренными функциями и внешними портами. Внешние порты питающегося от шины концентратора могут обеспечивать только одну нагрузку на порт независимо от потребляемого тока другими портами того же концентратора. Концентратор должен быть способен обеспечить этот текущий порт, когда концентратор находится в активном или подвешеннои ожидания.

Концентраторы с независимым питанием - Мощность для внутренних функций и downstream портов берется не от USB, хотя интерфейс USB может составлять одну нагрузку upstream соединения, что позволить интерфейсу функционировать, когда оставшийся концентратор не под питанием.( Power for the internal functions and downstream ports does not come from USB, although the USB interface may draw up to one load from its upstream connection to allow the interface to function when the remainder of the hub is powered down.) Концентратор должен быть способен обеспечить до пяти нагрузочных модуле на всех внешних downstream портах даже, когда концентратор находится в состоянии ожидания.

Мало мощные подключенные к шине функции- Вся мощность для этих устройств берется от коннектора USB. Они могут потреблять не больше, чем одну модульную нагрузку в любое время.

Высоко мощные подключенные к шине функции  - Вся мощность для этих устройств берется от коннектора USB. Они должны потреблять не больше, чем одну модульную нагрузку при включении и могут составлять до пяти модульных нагрузок после того, как сконфигурированы.

Функции с независимым питанием - Может составлять одну нагрузку на upstream соединение, что позволит интерфейсу функционировать, когда остаток от концентратора выключен.(May draw up to one load from their upstream connection to allow the interface to function when the remainder of the hub is powered down.) Вся остальная мощность берется от внешних (к USB) источников.

Концентратор на хосте в настольном компьютере - это концентратор с независимым питанием. Тот же самый концентратор в ноутбуке может быть определен, как с независимым питанием или как питающимся от шины концентратором.

Все устройства или питающиеся от шины или с независимым питанием, могут только потреблять (как сток), ток из шины. Они не должны обеспечивать ток вверх по иерархии хосту или порту концентратора.  При включении, все устройства должны обеспечить, чтобы их upstream порт был не работающим(enabled), так чтобы устройство было способно получить передачу сигналов сброса, и что максимально действующий ток, потребляемый устройством является одной  модульной нагрузкой. Если устройство потребляет мощность от шины, внутреннее питание получаемое от Vbus должно быть устойчиво внутри 100 мс для достижения Vbus

4.4 В.(If a device draws power from the bus, its internal supply derived from Vbus

must be stable within 100 ms of Vbus reaching 4.4 V.) Все устройства, которые потребляют мощность от шины, должны быть способны, переходить в подвешенное состояние и уменьшают свое потребление тока от Vbus до менее чем 500 мкА (обратитесь к Разделу 7.1.4.4 и Разделу 9.2.5.1).

Клиентское Программное Обеспечение

Клиентское программное обеспечение определяет то, что должны сделать передачи с функцией (Client software determines what transfers need to be made with a function.) Оно использует интерфейсы определенные соответствующей операционной системой, чтобы запросить IRPs.(It uses appropriate operating system specific interfaces to request IRPs.) Клиентское программное обеспечение  знает только необходимый набор каналов (то есть, интерфейс) для управления своей функцией. (Client software is only aware of the set of pipes (i.e., the interface) it needs to manipulate its function.) Клиент знает и твердо придерживается всех правил доступа к шине(all bus access) и ограничений пропускной способности как описано ранее для каждого типа передачи. Запросы, сделанные клиентским программным обеспечением представляются через интерфейс USBD.

Некоторые клиенты могут управлять функциями USB через другие интерфейсы класса устройства, определенные операционной системой и сами могут не обращаться напрямую к USBD. Однако, всегда имеется некоторый клиент на самом нижнем уровне(some lowest level client), который обращается к USBD, чтобы передать IRPs к USBD. Все представленные IRPs требуют твердо придержаться ранее оговоренного набора ограничений пропускных способностей, когда устройство было присоединено к шине и сконфигурировано. Если функция перемещает данные из не USB среды в USB, драйвер, который непосредственно управляет функциями аппаратных средств через память, или доступы Ввода - вывода, является самым низким клиентским программным обеспечением в USB среде, теперь взаимодействуя с USBD управляет этой функцией USB. (If a function is moved from a non-USB environment to USB, the driver that would have directly manipulated the function hardware via memory or I/O accesses is the lowest client software in the USB environment that now interacts with USBD to manipulate its USB function.)

После того, как клиентское программное обеспечение запросило передачу функции, и запрос обслужился, клиентское программное обеспечение получает сообщение о состоянии завершения IRP.(After client software has requested a transfer of its function and the request has been serviced, the client software gets notified of the completion status of the IRP.) Если передача содержит функцию передачи данных хостом, клиентское программное обеспечение может обращаться к данным в буфере данных, связанным с завершенным IRP. (If the transfer involved function to host data transfer, the client software can access the data in the data buffer associated with the completed IRP.)

Интерфейс USBD определен в Главе 10.

Кодирование / Декодирование Данных

USB использует NRZI кодирование данных при передачи пакетов. При кодировании NRZI, 1 не представляется никаким изменением уровня, а 0 представляется изменением уровня.  Рисунок 7-11 показывает поток данных и NRZI эквивалент и Рисунок 7-12 является блок-схемой NRZI. Высокий уровень представляет состояние J на линиях данных в этом и последующих рисунках, показывающих NRZI кодирование. Строка нулей заставляет NRZI данные переключать в каждое время передачи бита. Строка единиц вызывает длительные периоды без переходов в данных.

Рисунок 7-11.  Кодирование Данных NRZI

Рисунок 7-12.  Блок-схема NRZI

Концентратор, Получающий Сброс на Корневом Порте

Сигнал сброса к концентратору определен только в направлении вниз по иерархии, которое от корневого порта концентратора.(Reset signaling to a hub is defined only in the downstream direction which is at the hubs’ root port.) Активный концентратор может начинать последовательность сброса, если он обнаруживает в течении 2.5 мс или дольше непрерывный сигнал SE0 и должен завершить последовательность сброса не позднее истечения 5.5 мс непрерывного SE0. Нижнее ограничение в 2.5 мс установлено необходимостью предотвратить интерпретацию низко скоростных стробов EOP (которые имеют длину до 1.3 мс) как сброса. Подвешенный концентратор должен интерпретировать начало границы сброса как событие сигнала возобновления и начинать последовательность пробуждения. Концентратор должен быть активен и завершить сброс не позже чем 10 мс после завершения сигнала сброса( The hub must be awake and have completed reset no later than 10 ms the completion of reset signaling)

После завершения сброса контроллер концентратора находится в следующем состоянии:

Адрес назначенный по умолчанию контроллеру концентратора = 0

Управляющие биты концентратора установлены в значения по умолчанию

Повторитель Концентратора находится в состоянии WFSOP

Все downstream порты в состоянии Powered Off (концентраторы с возможностью переключения мощности)

Все downstream порты в состоянии Disconnected (концентраторы без возможности переключения мощности)

Если шина содержит концентраторы с переключающими мощность портами, не гарантируется распространение сброса хоста во всех направлениях вниз по иерархии. Хост должен гарантировать, что каждый уровень сброшен, когда он проходит через процесс перенумерации, и сброс перенумерации выполнен на уровне базисного уровня.(The host has to guarantee that each tier is reset when it goes through the enumeration process, and the enumeration reset is done on a tier by tier basis.) ( Однако, устройства без питания(powered off) действительно сброшены, если они выключены достаточно долго, и устройства/концентраторы с независимым  питанием находящиеся ниже их сбрасывают себя и свои downstream порты.)

Концентраторы

Концентраторы - это ключевой элемент в PnP архитектуре USB. Рисунок 4-3 показывает типичный концентратор. Концентраторы нужны для того, чтобы упростить связность USB из перспективы пользователя и обеспечивают помехоустойчивость за низкую цену и сложность. 

Концентраторы - это монтажные сосредоточители и они дают возможности множеству характеристик присоединения к USB шине. Точки присоединения упоминаются как порты.  Каждый концентратор разветвляет одиночную точку присоединения в множество точек присоединения. Архитектура поддерживает конкатенацию множества концентраторов.

Порт концентратора от верхнего уровня(upstream) иерархии подсоединяет концентратор к хосту.  Каждый из других портов концентратора к нижнему уровню(downstream) иерархии позволяет соединяться с другими концентраторами или функциями. Концентраторы могут обнаружить присоединение и отсоединение в каждом downstream порте и дают возможность распределению мощности на downstream устройства. С каждым downstream портом можно индивидуально работать и конфигурировать как на полное так и низкое быстродействие. Концентратор изолирует порты с низким быстродействием от высокоскоростных сигналов.

Концентратор состоит из двух частей: Контроллер Концентратора и Повторитель Концентратора. Повторитель - управляемый протоколом переключатель между upstream и downstream портами. Он также имеет аппаратную поддержку сброса и приостановки / возобновления передачи сигналов.  Контроллер обеспечивает интерфейса регистрирования (interface reqisters), что позволяет иметь двустороннюю связь с хостом.  Специфическое состояние концентратора и команды управления разрешают хосту конфигурировать концентратор, контролировать(to monitor) и управлять портами.

Рисунок 4-3.Типичный Концентратор

Рисунок 4-4 иллюстрирует, как концентраторы обеспечивают связь в настольной компьютерной системе.

Рисунок 4-4.  Концентраторы в Настольной Компьютерной Системе

Концентраторы с независимым питанием

Концентраторы с независимым питанием имеют локальное питание, которое снабжает мощностью любые внедренные функциям и все downstream порты, как показано на Рисунке 7-24.  Мощность для контроллера концентратора, однако, может быть взята или из порта upstream (“гибридное” питание концентратора) или как локальное питание. Преимущество обеспечения контроллера концентратора питанием от upstream - это связь с хостом, возможная, даже если питание устройства остается выключенным. Это делает возможным различать неподключенное и не включенное устройство.

Рисунок 7-24.  Состав Концентратора с Независимым Питанием

Мощность предоставляется всем downstream портам от локального источника питания. Число портов, которые могут запитываться, ограничен только тем, сколько возможно локально предоставить питания и в соответствии с правилами безопасности. Приемлемый максимум - семь портов. Каждый порт должен быть способен к обеспечению по крайней мере пять модульных нагрузок. Однако, никакой одиночный порт не может поставлять больше чем 5.0 А, в соответствии с ограничением безопасности. Ограничение тока на downstream портах иногда необходимо разбить на разделы в две или большие подгруппы портов, чтобы предоставить достаточную мощность всем портам без того, чтобы превысить ограничение по току на один порт. Если все семь портов были смонтированы в параллель, доступный ток в данном порте будет 7 * 500 мА = 3.5 А.  Это - очень близко к ограничению безопасности. При реализации двух схем ограничения тока, максимально необходимый ток, при операции,  уменьшается до 1.5 - 2.0 A, что дает хороший запас по безопасности.

Конечная точка

Каждая конечная точка, используемая для интерфейса имеет собственный дескриптор.  Этот дескриптор содержит информацию, требуемую хостом, чтобы определить требования по пропускной способности каждой конечной точки. Дескриптор конечной точки всегда возвращается как часть дескриптора конфигурации.  К нему нельзя непосредственно обращаться запросом Get или Set Descriptor. Нет никакого дескриптора у нулевой конечной точки.

Смещение		Поле		Размер		Значение		Описание
0		bLength		1		Number		Размер этого дескриптора в байтах
1		bDescriptorType		1		Constant		Тип дескриптора ENDPOINT
2		bEndpointAddress		1		Endpoint		Адрес конечной точки на устройстве USB, описываемого этим дескриптором.  Адрес закодирован следующим образом: Bit 0..3:   Номер конечной точки Bit 4..6:   Зарезервированный, сброшен в 0 Bit 7:       Направление, игнорируется                 управляющими конечными                 точками          0        Выходная (OUT) конечная точка          1        Входная (IN) конечная точка

Смещение		Поле		Размер		Значение		Описание
3		bmAttributes		1		Bit Map		Это поле описывает атрибуты конечной точки, когда она сконфигурирована, используя bConfigurationValue. Bit 0 .. 1: Тип Передачи   00           Управление   01           Изохронные   10           Bulk   11           Прерывание                 Все другие биты зарезервированны
4		wMaxPacketSize		2		Number		Максимально возможный при посылке или получении размер пакета этой конечной точки, когда выбрана эта конфигурация. Для изохронных конечных точек, это значение используется, чтобы резервировать время шины в расписании, требуемой на кадр полезной нагрузки данных.(For isochronous endpoints, this value is used to reserve the bus time in the schedule, required for the per frame data payloads.) Канал может, на продолжающемся основании(on an ongoing basis), фактически использовать меньшее количество пропускной способности чем зарезервированное.  В случае необходимости, устройство сообщает фактическую пропускную способность, используемую через нормальные, не определенные USB механизмы. Конечные точки прерываний, bulk, и управления могут посылать меньшие полезные нагрузки данных, но завершение передачи, может потребовать а может и нет вмешательства в перезапуск.  Обратитесь к Главе 5 для подробной информации.
6		bInterval		1		Number		Интервал при опросе конечной точки для передач данных. Выражен в миллисекундах. Это поле игнорируется для конечных точек bulk и управления.  Для изохронных конечных точек это поле должно быть установлено в1. Для конечных точек прерывания, это поле может иметь значение от 1 до 255.

Конечные Точки Устройства

Конечная точка - уникально идентифицируемая часть устройства USB, которая является конечным пунктом назначения потока связи между хостом и устройством. Каждое логическое устройство USB состоит из набора независимых операционных(м/б операций) конечных точек.( Each USB logical device is composed of a collection of independently operating endpoints.) Программное обеспечение может связываться с устройством USB только через одну или более конечных точек. Каждое логическое устройство имеет уникальный адрес, назначенный системой во время присоединения устройства. Каждая конечная точка на устройстве имеет устройство (создается во время разработки), определяющее уникальный идентификатор, номер конечной точки.(Each endpoint on a device has a device (design time) determined unique identifier, the endpoint number.)  Комбинация адреса устройства и номера конечной точки позволяет однозначно обращаться к каждой конечной точке.

Конечная точка имеет характеристики, которые определяют тип требуемого сервиса передачи между конечной точкой и клиентским программным обеспечением. Конечные точки описывают себя(Endpoints describe themselves by):

Своими требованиями по доступу к частоте/времени отклика на шине(Their bus access frequency/latency requirements)

Своими требования к пропускной способности

Собственным номером конечной точки

Требованиями поведения при обработке ошибок

Максимальным размером пакета, который конечная точка способна посылать или получать

Типом передачи конечной точки (обратитесь к Разделу 5.4 для подробностей)

Для bulk и изохронных типов передачи, направлением перемещения данных между конечной точкой и хостом

Конечные точки находятся в неизвестном состоянии прежде, чем они будут сконфигурированы. К конечным точкам хост не может обратиться прежде, чем они будут сконфигурированы.

Конфигурация

Устройство USB должно быть сконфигурировано прежде, чем функция может использоваться. Хост ответственен за конфигурирование устройства USB. Хост обычно запрашивает информацию о конфигурации от устройства USB, чтобы определить возможности устройства.

Как часть процесса конфигурации, хост устанавливает конфигурацию устройства и, где необходимо, устанавливает максимальный размер пакета для конечных точек, когда требуются такие ограничения.

Внутри одной конфигурации, устройство может поддерживать множество интерфейсов.  Интерфейс - связанный набор конечных точек, которые представляют одну возможность или функцию устройства на хосте. Протокол используется, чтобы связаться с этим связанным набором конечных точек, и цель каждой конечной точки внутри интерфейса может быть определена как часть класса устройства или определена как класс определенный продавцом.

Кроме того, интерфейс внутри конфигурации может иметь альтернативные установки, которые переопределяют номер или характеристики связанных конечных точек. Если дело обстоит так, устройство должно поддерживать запросы Получение Интерфейса (Get Interface) и Установка Интерфейса (Set Interface), чтобы сообщить или выбрать вариант специфической установки для специфического интерфейса.

Внутри каждой конфигурации, каждый дескриптор интерфейса содержит поля, которые идентифицируют номер интерфейса и альтернативную установку. Интерфейсы пронумерованы от нуля до числа параллельных интерфейсов, обеспечиваемых конфигурацией, минус один. Альтернативные установки располагаются от нуля до числа альтернативных установок для специфического интерфейса, минус один. Настройка по умолчанию, когда устройство первоначально конфигурировано , ноль альтернативных установок.

В поддержку адаптивных драйверов устройства, которые способны управлять связанной группой устройств USB, дескрипторы устройства и интерфейса, содержат поля Класс, Подкласс, и Протокол.(In support of adaptive device drivers that are capable of managing a related group of USB devices, the device and interface descriptors contain Class, SubClass, and Protocol fields.) Эти поля используются, чтобы идентифицировать функцию(и), обеспечиваемую устройством USB и используемые протоколы, чтобы связаться с функцией(ями) устройства. Код класса назначен связанному классу устройств, который был определен как часть спецификации USB. Класс устройств далее подразделен на подклассы и внутри класса или подкласса код протокола определяет, как программное обеспечение хоста связывается с устройством.

Дескриптор конфигурации описывает информацию о специфической конфигурации устройства. Дескриптор содержит поле bConfigurationValue значение которого используется как параметр в запросе Set Configuration, заставляя устройство переходить в описанную конфигурацию.

Дескриптор описывает число интерфейсов, обеспеченных конфигурацией. Каждый интерфейс может функционировать независимо. Например, устройство ISDN могло бы быть сконфигурировано с двумя интерфейсами, каждый обеспечивает 64 КБ двунаправленный канал, имеющими отдельные источники или стоки данных на хосте.  Другая конфигурация могла бы представлять устройство ISDN как один интерфейс, соединяя два канала в один 128 КБ двунаправленный канал.

Когда хост запрашивает дескриптор конфигурации, возвращаются все дескрипторы относящиеся к интерфейсу и конечной точке (обратитесь к Разделу 9.4.2).

Устройство USB имеет один или более  дескрипторов конфигурации.  Каждая конфигурация имеет один или более интерфейсов, и каждый интерфейс имеет одну или более конечных точек. Конечная точка не общая для интерфейсов внутри одной конфигурации, если конечная точка не используется альтернативными установками того же самого интерфейса. Конечные точки могут быть общими для интерфейсов, которые являются частью различных конфигураций без этого ограничения.(Endpoints may be shared among interfaces that are part of different configurations without this restriction.)

Как только устройства сконфигурированы они могут поддерживать ограниченные установки конфигурации. Если специфический интерфейс имеет альтернативные установки, альтернатива может быть выбрана после конфигурации. Внутри интерфейса, максимальный размер пакета изохронной конечной точки может быть также скорректирован.

Смещение		Поле		Размер		Значение		Описание
0		bLength		1		Number		Размер этого дескриптора в байтах
1		bDescriptorType		1		Constant		CONFIGURATION
2		wTotalLength		2		Number		Общая длина данных, возвращаемых для этой конфигурации.  Включает объединенную длину всех дескрипторов (конфигурации, интерфейса, конечной точки, и класса или определений продавца) возвращенных для этой конфигурации.
4		bNumInterfaces		1		Number		Число интерфейсов, поддерживаемых этой конфигурацией
5		bConfigurationValue		1		Number		Значение, используемое как параметр, Set Configuration, при выборе этой конфигурации
6		iConfiguration		1		Index		Индекс строкового дескриптора, описывающего эту конфигурацию
7		bmAttributes		1		Bitmap		Характеристики конфигурации D7           Питание от Шины D6           Независимое питание D5           Удаленное Пробуждение D4..0      Зарезервированы (сброшены в 0)                 Устройства сконфигурированные на использование питания от шины и локальных источников устанавливают и D7 и D6. Фактический источник питания может быть определен во временя работы, используя запрос Get Status к устройству . Если конфигурация устройства поддерживает удаленное пробуждение, D5 установлен в 1.
Смещение		Поле		Размер		Значение		Описание
8		MaxPower		1		mA		Максимальное потребление мощности устройством USB от входной шины в этой специфической конфигурация, когда устройство полностью работоспособно. Выраженный в 2 мA модулях (т.е.,  50=100 мA). (Expressed in 2 mA units (i.e., 50 = 100 mA). Обратите внимание: конфигурация устройства сообщает, является ли конфигурация питающейся от шины или с независимым питанием. Состояние устройства сообщает, является ли устройство в настоящее время с независимым питанием.  Если устройство отсоединено от внешнего источника питания, оно модифицирует состояние устройства показывая, что оно больше не  независимо питающееся. Устройство не может увеличивать, потребляемую мощность от шины, когда оно теряет внешний источник питания, выше сообщенного конфигурацией количества. Если устройство может продолжать функционировать когда отсоединено от внешнего источника питания, оно продолжает это делать. Если устройство не может продолжать функционировать, оно отказывается от операций, которые больше не может поддерживать.  Программное обеспечение хоста может определить причину отказа,  проверяя состояние и отмечает потерю источника питания устройства.

Конфигурация Концентратора

Концентраторы конфигурируются с помощью стандартных команд конфигурации устройства USB. Не сконфигурированный концентратор ведет себя подобно всем другим не сконфигурированным устройствам, что касается требований мощности и адресуемости. Не сконфигурированные концентраторы не направляют мощность на downstream порты.  Конфигурирование концентратора разрешает работать конечной точке Изменения Состояния. Системное программное обеспечение выдает команды концентратору, чтобы подать и отключить мощность порта в соответствующее время.

Системное программное обеспечение исследует информацию дескриптора концентратора перед конфигурацией, чтобы определить характеристики концентратора. Исследуя характеристики концентратора, системное программное обеспечение гарантирует, что при запрещенной топологии мощности не произойдет подача питания на порты концентратора, что могло бы нарушить топологию мощности USB.

Конфигурация Системы

USB поддерживает присоединение к и отсоединение устройств USB,  из USB в любой момент времени.  Следовательно, перенумерация USB - это то действие, которое должно приспособить динамические изменения в физической топологии шины.

Конфигурация Устройства

Различное окружение операционной системы выполняет конфигурацию устройства, используя различные компоненты программного обеспечения и различные последовательности событий. Метод определенный операционной системой не допустим в системе USB. Однако, имеются некоторые базисные требования, которые должны быть выполнены в любой реализации системы USB. В некоторых операционных системах, эти требования выполняются существующим программным обеспечением хоста. В других, предоставляет возможности система USB.

Система USB принимает специализированного клиента USBD, называемого драйвером концентратора, который действует как фирма очистки для добавления устройств к и удаления устройств из специфического концентратора.(The USB system assumes a specialized client of the USBD, called a hub driver, which acts as a clearing house for addition of devices to and removal of devices from a particular hub.) Если только драйвер концентратора получает такие уведомления, он будет использовать дополнительное программное обеспечение хоста и других  клиентов USBD, способом зависящем от операционной системы, для распознавания и конфигурирования устройства. Эта модель, показана на Рисунок 10-4 служит основой дальнейшего обсуждения.

Рисунок 10-4.  Взаимодействие в Конфигурации

Когда устройство присоединено, драйвер концентратора получает уведомление от концентратора, обнаружившего изменение. Драйвер концентратора, используя информацию, предоставленную концентратором, запрашивает идентификатор устройства из USBD. USBD в свою очередь устанавливает создаваемый по умолчанию канал для этого устройства и возвращает идентификатор устройства драйверу концентратора.

Устройство теперь готово к конфигурированию для использования.  Для каждого устройства, имеются три типа конфигурации, которые должны быть выполнены прежде, чем это устройство будет готово к использованию:

1.       Конфигурация Устройства. Она включает установку всех параметров устройства USB и распределение всех ресурсов хоста USB, которые являются видимыми устройством.  Здесь выполняется, установление значений конфигурации на устройстве. Ограниченный набор изменений конфигурации, типа альтернативной установки, позволяется полностью не реконфигурировать устройство. Только если устройство сконфигурировано, то с его точки зрения оно готово к использованию.

2.       Конфигурация USB.  Чтобы фактически создать канал USBD, готовый для использования клиентом, клиент должен определить дополнительную информацию USB, не видимую на устройстве. Эта информация, известный как Стратегия для канала, описывает, как клиент использует канал. Она включает такие единицы как максимальное количество данных, которые клиент будет передавать в одном IRP, максимальный интервал обслуживания используемый клиентом, идентификация уведомления клиента, и так далее.

3.       Конфигурация функции.  Только если типы конфигурацию 1 и 2 были выполнены, канал полностью готов для использования с точки зрения USB. Однако, дополнительно может требоваться определяемая продавцом или классом установка прежде, чем канал может фактически использоваться клиентом. Эта конфигурация индивидуальный вопрос между устройством и клиентом и не стандартизирована USBD.

Следующие абзацы описывают требования устройства и конфигурации USB.

Фактическая конфигурация устройства выполняется программным обеспечением ответственным за конфигурирование.  В зависимости от специфической реализации операционной системы, программное обеспечение, ответственное за конфигурацию может включать:

Драйвер концентратора

Другое программное обеспечение хоста

Драйвер устройства

Конфигурирующее программное обеспечение сначала читает дескриптор устройства, затем запрашивает описание для каждой возможной конфигурации. Оно может использовать предоставленную информацию, чтобы загрузить особого клиента, типа драйвера устройства, который первоначально взаимодействует с устройством. Конфигурирующее программное обеспечение, возможно со вводом из этого драйвера устройства, выбирает конфигурацию для устройства.(The configuring software, perhaps with input from that device driver, chooses a configuration for the device.) Установка конфигурации устройства устанавливает все конечные точки на устройстве и возвращает набор интерфейсов, которые нужно использовать для передачи данных клиентам USBD. Каждый интерфейс - это набор каналов, принадлежащих одному клиенту.



Эта начальная конфигурация использует установки по умолчанию для интерфейсов и заданную по умолчанию пропускную способность для каждой конечной точки. Реализация USBD может дополнительно позволять клиенту определять альтернативные интерфейсы при выборе начальной конфигурации. Система USB проверит, что имеются ресурсы, требуемые для поддержки конечной точки и, если это так, выделит требуемую пропускную способность. Обратитесь к Разделу 10.3.2 для обсуждения управления ресурсами.

Устройство теперь сконфигурировано, но созданные каналы еще не готовы для использования. Конфигурация USB выполнена, когда клиент инициализирует каждый канал,  устанавливая стратегию, определяющую, как он будет взаимодействовать с каналом. Среди определяемой информации - максимальный интервал обслуживания клиента и информация его уведомления. Среди действий, предпринимаемых системой USB, в результате установки стратегии, определяется размер рабочей области буфер, требуемой сверх пространства буфера данных, обеспеченного клиентом. Размер требуемых буферов основан на эксплуатации, выбранной клиентом и на нуждах передачи в системе USB.

Клиент получает уведомления когда завершаются IRPs, успешно или из-за ошибок. Клиент может также пробуждаться независимо от уведомления USB, чтобы проверить состояние задержанных IRPs.

Клиент может также выбирать, делать модификацию конфигурации типа предоставления альтернативных установок для интерфейса или изменять   распределенную пропускную способность для особого канала. Чтобы выполнять эти изменения, интерфейс или канал, соответственно, должен быть неактивен.

Корректировка начала кадра

USBDI должен позволить главному(master) клиенту изменять число времен передачи бита в кадре USB. Клиент, желающий корректировать SOF, должен уже получить статус главного клиента от USBD (обратитесь к Разделу 10.5.3.2.5). Это изменения совершается, если только чаще, чем каждые 6 мс имеются неопределенные результаты.(Invoking this change more frequently than once every 6 ms has undefined results.)

Краткий обзор

Основные потоки и модель взаимосвязи USB показаны на Рисунке 10-1.

Рисунок 10-1.  Межуровневая Модель Связи

Хост и устройство четко разделены на уровни, представленные на Рисунке 10-1. Фактическая связь на хосте обозначена вертикальными стрелками. Соответствующие интерфейсы на устройстве зависят от реализации. Вся связь между хостом и устройством в конечном счете происходит по физическому проводу USB. Однако, имеются логические интерфейсы между каждым горизонтальным уровнем устройства и хоста. Эта связь, между резидентным клиентским программным обеспечением на хосте и функцией, обеспеченной устройством, обычно соответствует контракту основанному на потребностях приложения, использующего в настоящее время устройство и возможностях обеспечиваемых устройством.

Это взаимодействие клиент - функция создает требования для всех основных уровней и их интерфейсов.

Эта глава описывает эту модель с точки зрения хоста и уровней.  Рисунок 10-2 описывает, основанный на полном просмотре, представленном в Главе 5, вид хоста на связь с устройством.

Рисунок 10-2.  Связи в Хосте

Имеется только один хост в каждой USB.  Главные уровни хоста:

Интерфейс USB шины

Система USB

Клиент

Интерфейс шины USB регулирует взаимодействия на электрическом и протокольном уровнях (обратитесь к Главе 7 и Главе 8). С точки зрения взаимосвязи, подобный интерфейс USB шины обеспечивается и, устройством USB и хостом, как например Последовательный Модуль Управления Интерфейса (SIE - Serial Interface Engine). На хосте, однако, интерфейс шины USB имеет дополнительные обязательства из-за уникальной роли хоста в USB и выполняется как хост контроллер. Хост контроллер также имеет интегрированный или корневой концентратор, обеспечивающий присоединение узлов(points-точек) к хосту.

Система USB использует хост контроллер, чтобы управлять передачами данных между хостом и устройством USB. Интерфейс между системой USB и хост контроллером зависит от аппаратного определения(definition-описания) хост контроллера. Система USB, совместно с хост контроллером, выполняет трансляцию между видом клиента на передаваемые данных и транзакциями USB появляющихся при взаимосвязи. Это включает добавление поддержки любой возможности USB типа обрамлений(wrappers) протокола. Система USB также ответственна за управление ресурсами USB; например, пропускной способностью, так чтобы был возможен доступ клиента к USB.

Система USB имеет три базисных компонента:

Драйвер Хост Контроллера

Драйвер USB

Программное Обеспечение Хоста

Драйвер Хост Контроллера (HCD- Host Controller Driver) существует, чтобы более легко встроить(map) различные возможные реализации хост контроллера в систему USB, так чтобы клиент мог взаимодействовать с устройством без знания того, с каким хост контроллером соединено устройство. Драйвер USB (USBD- USB Driver) обеспечивает базисный интерфейс хоста (USBDI) для взаимодействия клиентов с устройствами USB.  Интерфейс между HCD и USBD известен как Интерфейс Драйвера Хост Контроллера (HCDI- Host Controller Driver Interface). Этот интерфейс никогда не доступен непосредственно клиентам и таким образом не определяется спецификацией USB. Однако особенности HCDI, определены каждой операционной системой, которая поддерживает различные реализации хост контроллера.

USBD обеспечивает механизмы передачи данных в форме Пакетов Запроса Ввода - Вывода (IRPS), которые состоят из запроса к каналу определенному передаваемыми по нему данными.(The USBD provides data transfer mechanisms in the form of I/O Request Packets (IRPs), which consist of a request to transport data across a specific pipe.) В дополнение к обеспечению механизмов передачи данных, USBD ответственен за представление клиентам в виде абстракции устройства USB, в котором можно управлять его состоянием и конфигурацией. Как часть этой абстракции, USBD обладает создаваемым по умолчанию каналом (см. Главу 5 и Главу 9) через который обращаются ко всем устройствам USB в виде стандартного управления USB. Этот создаваемый по умолчанию канал представляет логическую связь между USBD и абстракцией устройства USB как показано на Рисунке 10-2.

В некоторых операционных системах, доступно дополнительное не-USB программное обеспечение хоста, которое обеспечивает конфигурацию и механизмы загрузки драйверов устройств. В таких операционных системах, драйвер устройства должен использовать имеющиеся интерфейсы вместо непосредственного доступа к USBDI механизмам.



Клиентский уровень описывает все те сущности программного обеспечения, которые ответственны за непосредственно взаимодействие со своими периферийными устройствами. Когда каждое устройство независимо присоединено к системе, эти клиенты могли бы взаимодействовать непосредственно с периферийной аппаратурой. Общедоступные характеристики USB помещаются в стек программного обеспечения USB между клиентом и устройством; то есть клиент не может непосредственно обращаться к аппаратным средствам устройства.(The shared characteristics of USB place a USB software stack between the client and its device; that is, a client cannot directly access the device’s hardware.)

В целом, уровни хоста обеспечивают следующие возможности:

Обнаружение присоединения и удаления устройств USB

Управление стандартный потоком управления USB между хостом и устройствами USB

Управление потоком данных между хостом и устройствами USB

Сбор статистики состояний и действий

Управление электрическим интерфейсом между хост контроллером и  устройствами USB, включая средство ограничения количества мощности

Следующие разделы описывают эти обязательства и требования, включенные в USBDI более подробно. Фактические интерфейсы, используемые для специфической комбинации платформы хоста и операционной системы описаны в соответствующем Руководстве Среды Операционной системы.

Все концентраторы обеспечивают канал изменения состояния (см. Главу 11) по которому сообщаются изменения состояний концентраторов, и их портов.(All hubs provide a status change pipe (see Chapter 11) on which status changes for hubs and their ports are reported.) Это включает уведомление о том, что устройство USB присоединено или удалено от одного из их портов. Клиент USBD обычно, известный как драйвер концентратора, получает эти уведомления как владелец канала изменения состояния концентратора. Для присоединенных устройств, драйвер концентратора затем инициализирует процесс конфигурации устройства. В некоторых системах, этот драйвер концентратора является частью программного обеспечения хоста, предоставленного операционной системой для управляемых устройств.

Краткий Обзор Механизмов Программного Обеспечения

HCD и USBD представляют интерфейсы программного обеспечения, основанные на различных уровнях абстракции. Однако, ожидается что они будут функционировать вместе определенным способом удовлетворяя полному набору требований системы USB (см. Рисунок 10-2). Требования для USB стека программного обеспечения выражены прежде всего как требования к USBDI. Разделение режимов работы между USBD и HCD не определено. Однако, одно требование к HCDI должно быть выполнено - необходимо поддерживать, в определенном контексте операционной системы, несколько определений хост контроллеров.

HCD обеспечивает абстракцию хост контроллера и абстракцию вида хост контроллера на передачи данных по USB. USBD обеспечивает абстракцию устройства USB и передач данных между клиентом USBD и функции на устройстве USB. В целом, стек программного обеспечения USB действует как помощник для передачи данных между клиентом и функцией и как точка управляющая определенными USB интерфейсами устройства USB.(Overall, the USB software stack acts as a facilitator for transmitting data between the client and the function and as a control point for the USB-specific interfaces of the USB device.) Как часть помощи в передачи данных, программное обеспечение USB обеспечивает возможности организации буферизации данных и позволяет синхронизировать передачи данных к потребностям клиента и функции.

Специфические требования к USBDI описаны позже в этой главе. Правильные функции, которые выполняют эти требования,  описаны в  Руководстве Среды Операционной Системы для HCDI и USBDI. Процедуры, включаемые в выполняемые передачи данных через USBDI описаны ниже.

Квитирование

Конечные точки используют фазу квитирования транзакций USB, чтобы сообщить об ошибке и о необходимом потоке данных на хост. Конечные точки могут также получать квитирование от хоста, которое сообщает об условии ошибки. Типы квитирования, используемых конечной точкой изменяются согласно обеспечиваемому типу передачи. Эти типы квитирования описаны подробно в Главе 8.

Логическая Топология Шины

В то время как устройства физически присоединяются к USB в виде уровневой звездообразной топологии, хост связывается с каждым логическим устройством, как будто оно было непосредственно подсоединено к корневому порту. Это создает логический вид, иллюстрируемый Рисунком 5-6, который соответствует физической топологии, показанной на Рисунке 5-5. Концентраторы - также логические устройства, но они не показаны на Рисунке 5-6 для упрощения изображения. Даже при том, что хост и логические устройства при работе используют этот логический вид, хост имеет информацию о физической топологии, для поддержания обработки удаления концентраторов.(Even though most host/logical device activities use this logical perspective, the host maintains an awareness of physical topology to support processing the removal of hubs.)  Когда концентратор удален, все устройства, присоединенные к концентратору должны быть удалены из логического вида топологии хоста. Более полное описание концентраторов может быть найдено в Главе 11, Спецификации Концентратора.

Рисунок 5-6. Логическая Топология USB Шины

Ложные EOP

Ложные EOPы должны быть обработаны способом, который гарантирует, что текущий пакет передается полностью прежде, чем хост или любое другое устройство попытается передавать новый пакет. Если такое событие произошло, то должна образовываться коллизия на шине и возможность разрушить до двух последовательных транзакций.(If such an event were to occur, it would constitute a bus collision and have the ability to corrupt up to two consecutive transactions.) Обнаружение ложного EOP полагается на тот факт, что пакет, в котором был вставлен ложный EOP, появится как усеченный пакет с неправильным CRC. ( Последние 16 бит пакета будут иметь очень низкую вероятность появления корректного CRC.)

Хост и устройства обрабатывают ложную EOP ситуации по-разному. Когда устройство видит разрушенный пакет данных, оно не выдает ответ и ждет, когда хост пошлет следующую маркер. Такая схема гарантирует, что устройство не будет пытаться возвращать квитирование, в то время как хост может все еще передавать пакет данных. Если произошел ложный EOP, пакет данных хоста в конечном счете закончится, и устройство будет способно обнаружить следующий маркер. Если устройство выдает пакет данных, который принимается разрушенным, с ложным EOP, хост игнорирует пакет и не выдаст квитирование. Устройство, ожидающее квитирование от хоста, будет приостановлено(time out).

Если хост получает разрушенный пакет данных, это означает, что возможно присутствуют ложные EOP и он ждет в течение 16 времен передачи бита, чтобы увидеть, есть ли какой-нибудь трафик вверх по иерархии. Если не обнаружено никаких переходов шины внутри 16 битового интервала, и шина остается в состоянии IDLE, хост может выдавать следующий маркер. Иначе, хост ждет пока устройство закончит посылку остатка пакета. Ожидание с интервалом 16 бит гарантирует два условия. Первое условие гарантия того, что устройство закончит посылку пакета. Это гарантируется временной приостановкой (без переходов шины) большей чем в худшем случае 6-битовый интервал вставки бита.(This is guaranteed by a time-out interval (with no bus transitions) greater than the worst case 6-bit time bit stuff interval.) Второе условие - то, что таймер оборота шины передающего устройства должен гарантированно досчитать до конца(expire). Обратите внимание, что интервал временной приостановки чувствителен к скорости транзакции. Для полно скоростных транзакций, хост должен ждать 16 полно скоростных времен передачи бита; для низко скоростных транзакций, он должен ждать 16 низко скоростных времен передачи бита.

Если хост получает пакет данных с допустимым CRC, он понимает, что пакет весь и не нужно задерживаться в выдаче следующего маркера.

Ложный EOP

Обработка концентратором ложных EOP различно и зависит от того, работает ли концентратор как повторитель или доступен как устройство. Концентратор, действующий как повторитель очевидно распространяет сигналы, и не может дифференцировать между “хорошим” EOP и “ложным” EOP. Если любой EOP происходит, концентратор разрушит связь и подождет следующего SOP. Если передатчик продолжает посылать пакет, концентратор восстанавливает связь на следующем переходе от J к K. С точки зрения концентратора, ложный EOP заставит один пакет выглядеть как два отдельных пакета. Концентратор не участвует в обнаружение ошибки ложного EOP или процессе восстановления при работе в режиме повторителя.

Когда к концентратору обращаются как к устройству USB, контроллер концентратора обнаруживает и поправляется от ложных EOP также как любое другое устройство USB, как описано в Разделе 8.7.3.

Максимальная задержка сигнала от конца до конца

Устройство, ожидающее ответ на передачу объявит неверным транзакцию, если оно не увидит переход начала пакета (SOP) внутри истечения периода ожидания после конца передачи (после того, как SE0 перейдет к J состоянию в EOP). Это может происходить между маркером IN и следующим пакетом данных или между пакетом данных и пакетом квитирования (обратитесь к Главе 8). Устройство, ожидающее ответ не будет блокировано раньше 16 временами передачи бита и после 18 времен передачи бита, измеряемых на штырьках данных устройства после конца EOP.(The device expecting the response will not time out before 16 bit times and not after 18 bit times measured at the data pins of the device after the end of the EOP.)  Хост не будет начинать передачу маркера для следующей транзакции раньше 18 временами передачи бита (измеряемых на штырьках данных) после того, как он увидит конец пакета без ответа.

Рисунок 7-22 описывает конфигурацию шести переходов сигнала (кабелей), которые приводят к худшему случаю допустимой задержки сигнала. Максимальная задержка распространения от upstream конца кабеля концентратора к любому downstream коннектору порта составляет 70 нс.

Рисунок 7-22.  Модель самого  плохого случая задержки сигнала от конца до конца

Мало мощные подключенные к шине функции

Мало мощной функцией называют такую функцию, которая потребляет менее чем одну модульную нагрузку из кабеля USB при любых операциях. Блок регулятора должен ограничить и от тока наплыва и обеспечивать необходимое напряжение для соответствующих уровней передачи сигналов.  Рисунок 7-25 показывает типичную питающуюся от шины мало мощную функцию, типа мыши. Регулирование малой мощности может быть интегрировано в кремний функции. Для более высоких токов, в диапазоне от 20 mA до 100 mA, может использоваться линейный регулятор IC. Мало мощные функции должны быть способны оперировать с входным Vbus напряжением таким низким как 4.40 V, измеряемым на разъеме конца кабеля.

Рисунок 7-25.  Мало Мощная Функция

Маркерные пакеты

Рисунок 8-5 показывает форматы поля для маркерного пакета. Маркер состоит из PID, определяющего тип пакета  IN, OUT, или  SETUP, и полей ENDP и ADDR. Для транзакций OUT и SETUP, поле адреса и конечной точки однозначно определяет конечную точку, которая получит последующий пакет данных. Для входной(IN) транзакции, эти поля однозначно определяют конечную точку, которая должна передать пакет данных. Только хост может выдавать маркерные пакеты. PIDы входных(IN) пакетов определяют транзакцию данных от функции к хосту. PIDы входных(OUT) пакетов и пакетов установки(SETUP) определяют транзакцию данных от хоста к функции.

Рисунок 8-5.  Формат Маркера

Маркерные пакеты имеют пяти-битовый CRC, который покрывает поля адреса и конечной точки как показано выше. CRC не покрывает PID, который имеет собственное поле проверки. Маркер и пакеты SOF разграничены EOP после трех байтов поля данных пакета. Если пакет декодирует как допустимый маркер или SOF, но не завершается EOP после трех байтов, он должен рассматриваться как недопустимый и игнорироваться приемником.

Механические параметры

Механическая спецификация для кабелей и соединителей рассматривается в Главе 6. Все устройства имеют идущие к верхнему(upstream) уровню соединение. Идущие к верхнему и нижнему(downstream) уровню иерархии разъемы механически не взаимозаменяемы, таким образом удаляется возможность получения запрещенных кольцевых соединений в концентраторах.  Кабель имеет четыре проводника: витая пара для сигнала стандартного вида и пара для мощности в диапазоне разрешенных значений. The connector is four position, with shielded housing, specified robustness, and ease of attach-detach characteristics. 

Механизмы Управления

Управляющая информация может быть передана между хостом и  устройством USB, используя в-полосную или вне-полосную передачу сигналов(Control information may be passed between the host and a USB device using in-band or out-of-band signaling.) Смесь при передаче сигналов в полосе управляющей информации с данными в канале вне осведомленности хоста.(In-band signaling mixes control information with data in a pipe outside the awareness of the host.) Размещенная вне-полосы управляющая информация передается по отдельному каналу.(Out-of-band signaling places control information in a separate pipe.)

Имеется канал сообщения называемый создаваемым по умолчанию канал для каждого присоединенного устройства USB. Эта логическая связь между хостом и устройством USB используется для стандартного в USB потока управления типа перенумерации и конфигурации устройства. Создаваемый по умолчанию канал обеспечивает стандартный интерфейс для всех устройств USB. Создаваемый по умолчанию канал может также использоваться в виде зависящей устройства от связи, с помощью USBD, который обладает создаваемыми по умолчанию каналами всех устройств USB.

В частности устройство USB может разрешить использовать дополнительные каналы сообщений для передачи зависящей от устройства  управляющей информации.  Эти каналы используют тот же самый протокол связи как создаваемый по умолчанию канал, но перемещаемая информация специфична для устройства USB и не стандартизирована Спецификацией Универсальной Последовательной Шины.

USBD поддерживает совместное с клиентами использование создаваемого по умолчанию канала, которым он обладает и использует. Он также обеспечивает доступ к любым другим каналам управления, связанным с устройством.

Механизмы Устранения Неисправностей Концентратора

Концентраторы -ключевой компонент USB для установления связи между хостом и другими устройствами. Жизненно важно, чтобы любые неисправности связи, особенно, которые могли бы приводить к тупику, были обнаружены и предотвращены от появления. Концентраторы должны обработать неисправности связи только, когда они находятся в режиме повторителя. Концентраторы должны также быть способны обнаружить и восстановиться от потерянных или разрушенных пакетов, которые адресованы контроллеру концентратора. Так как контроллер концентратора, фактически, другое устройство USB, он должен твердо придержаться тех же самых правил истечения времени ожидания как другие устройства USB, как описано в Главе 8.

Меж-уровневое взаимодействие

Устройства USB логически разделены на часть интерфейса устройства USB, часть устройства, и функциональную часть. Хост логически разбит на разделы в хосте USB на часть интерфейса, составную часть программного обеспечения системы ( программное обеспечение системы USB и программное обеспечение хост системы), и часть программного обеспечения устройства.

Каждая из этих частей определена так, что отдельная USB задача ответственна только за одну часть. Хост USB и USB части устройства соотносятся как показано в таблице 4-1.

Таблица 4-1.  Соотношение Между Уровнями Хоста и Устройства

Часть Хоста USB		Часть Устройства USB
Программное обеспечение Устройства		Функция
Программное обеспечение Системы		Устройство
Интерфейс USB		Интерфейс USB

Модель Часов USB

Время присутствует в системе USB в виде часов. Фактически, имеются множество часов в системе USB, которые должны быть обдуманы:

Простые часы(Sample clock) - Эти часы определяют естественную скорость передачи выборок данных, перемещающихся между клиентским программным обеспечением хоста и функцией. Эти часы не должны отличаться в не-USB и USB реализациях.(This clock does not need to be different between non-USB and USB implementations.)

Часы Шины(Bus clock) - Эти часы работают с периодом в 1.000 мс (частота 1 кГц) и означают скорость Начала Кадра (SOF) пакетов на шине.(This clock runs at a 1.000 ms period (1 kHz frequency) and is indicated by the rate of Start of Frame(SOF) packets on the bus.) Эти часы несколько эквивалентны 8 МГц часам в не-USB примере. В случае USB, часы шины - часто часы более низкой частоты чем часы выборок, в то время как часы шины - почти всегда часы более высокой частоты чем часы выборок в случае не-USB.

Часы Обслуживания(Service clock) - Эти часы определяют скорость, с которой клиентское программное обеспечение выполняет обслуживание IRPs, которые возможно, накопились между выполнениями. Эти часы также могут быть теми же самыми в USB и не-USB случаях.

В большей части окружения операционной системы, которое существует сегодня, было бы не возможно поддерживать широкий диапазон изохронных потоков связи, если бы каждый драйвер устройства прерывался бы каждой  быстрой выборкой скорости(In most operating system environments that exist today, it is not possible to support a broad range of isochronous communication flows if each device driver must be interrupted for each sample for fast sample rates.) Следовательно, различные выборки, если это не множество пакетов, будут обработаны клиентским программным обеспечением и затем выданы хост контроллеру последовательно по шине согласно ранее оговоренным требованиям доступа к шине.(Therefore, multiple samples, if not multiple packets, will be processed by client software and then given to the host controller to sequence over the bus according to the prenegotiated bus access requirements.) На Рисунке 5-14 представлен пример окружения часов USB эквивалентного окружению не - USB часов показанного на Рисунке 5-13.

Рисунок 5-14. Изохронное Приложение USB

Рисунок 5- 14 показывает типичный путь прохождения информации туда и обратно из микрофона, устройства ввода данных, к колонкам, устройству вывода. Также показаны часы, пакеты, и включенная буферизация. Рисунок 5-14 будет исследоваться более подробно в следующих разделах.

Смысл этого примера это определение различий, представленного USB примера в сравнении с предыдущим не-USB примером. (The focus of this example is to identify the differences introduced by USB compared to the previous non?USB example.) Различия находятся в областях буферизации, синхронизации конкретных существующих часов USB шины, и задержки.(The differences are in the areas of buffering, synchronization given the existence of a USB bus clock, and delay.) Клиентское программное обеспечение высших драйверов устройства может быть не затронуто в большинстве случаев.(The client software above the device drivers can be unaffected in most cases.)

Начальная Конфигурация Устройства

Процесс конфигурации устройства начинается, когда концентратор сообщает через канал изменяя состояние соединения нового устройства  USB.(The device configuration process begins when a hub reports via its status change pipe the connection of a new USB device.)

Сервисы Управления Конфигурацией позволяют конфигурирующему программному обеспечению, выбрать конфигурацию устройства USB из набора конфигураций, перечисленных в устройстве.  Перед установкой конфигурации устройства, USBD проверяет что скорости передачи данных, используемые всеми конечными точками в конфигурации не превышают возможности USB при текущем расписании.

Начальный Интервала Кадра и Приспосабливаемость

USB определяет интервал кадра длиной 1.000 мс.  Интервал кадра измеряется от начала PID Начала Кадра (SOF) в одном кадре до той же самой точки в SOF маркере следующего кадра. Разрешен допуск в начальном интервале кадра ±0.05% (500 ppm). Этот допуск включает погрешности всех источников: начальная точность частоты, кристаллическая емкостная нагрузка, обеспечиваемое напряжение на генераторе, температура, и старение.

Хост контроллер должен уметь корректировать интервал кадра. Имеются два возможных компонента для приспосабливаемости интервала кадра.(There are two possible components to the frame interval adjustability.) Если скорость передачи данных хоста не точно 12.00 МБ, то точность начального интервала кадра ±0.05% может быть удовлетворена,  изменением заданного по умолчанию числа битов на кадр от номинальных 12,000. (If the host’s data rate clock is not exactly 12.00 Mbs, then the initial ±0.05% frame interval accuracy can be met by changing the default number of bits per frame from the nominal of 12,000.)  (Компоненте хост контроллера, которая имеет диапазон возможных значений частоты источника, вероятно, придется сделать величину этого начального кадра пересчитываемым программируемым значением.[A host controller component, that has a range of possible clock source values, may have to make this initial frame count a programmable value.] Диапазон этих значений дан в Разделе 7.1.9.) Требуется дополнительно приспосабливаемость ±15 полно скоростных времен передачи бита, чтобы позволить хосту синхронизироваться с внешнем эталонным временем (An additional adjustability of ±15 full speed bit times is required to allow the host to synchronize to an external time reference.) В течение нормальной операции шины интервал кадра может быть перепрограммирован не более, чем на одно полно скоростное временя передачи бита в каждой корректировки.(The frame interval can be reprogrammed by no more than one full speed bit time each adjustment during normal bus operation.)

Концентраторы и некоторые полно скоростные функции должны проследить интервал кадра. (Hubs and certain full speed functions need to track the frame interval.) Они также требуются, чтобы иметь достаточную приспосабливаемость синхронизации кадра, чтобы компенсировать собственный допуск частоты и прослеживать за диапазоном приспосабливаемости хоста  ±15 полно скоростных времен передачи бита.(They also are required to have sufficient frame timing adjustability to compensate for its own frequency tolerance and track the host’s ±15 full speed bit time adjustability range.)

Направление

Передачи Управления обеспечиваются двунаправленным потоком связи по каналам сообщений.

Изохронный канал - это поток в канале и, следовательно, всегда однонаправлен. Описание конечной точки показывает, является ли поток связи данного изохронного канала от хоста или к хосту. Если устройство требует двунаправленного изохронного потока связи, должны использоваться два изохронных канала, один в каждом направлении.

Bulk канал - поток в канале и, следовательно, для данного канала всегда имеется поток связи или в хост или из хоста. Если устройство требует двунаправленного bulk потока связи, два bulk канала должны использоваться, один в каждом направлении.

Канал прерывания - это поток в канале и следовательно всегда однонаправлен. Также, канал прерывания - это только вход(input) на хост. Выходные (Output) каналы прерывания не обеспечиваются USB.

Назначение Адреса

Все устройства USB используют заданный по умолчанию адрес когда первоначально включены или после того, как устройство сброшено. Каждому устройству USB назначается уникальный адрес хостом после присоединения или после того, как оно сброшено. Устройство USB удерживает назначенный адрес в то время как оно подвешено.

Устройство USB отвечает на запросы по создаваемому по умолчанию каналу, назначен ли устройству в настоящее время уникальный адрес или оно использует заданный по умолчанию адрес.

Когда устройство USB присоединено, хост ответственен за назначение уникального адреса устройству после того, как устройство было сброшено хостом и порт концентратора, к которому устройство присоединено, был разблокирован.

Некоторые Существующие Технологии

Существует несколько технологий, которые являются основными последовательными шинами. Каждая из этих шин была определена для специфического диапазона приложения(й). Некоторые из них представлены ниже:

Apple desktop bus (ADB)

Это внутренний небольшой последовательный интерфейс, который обеспечивает простой протокол чтения - записи поддерживающий до 16 устройств.  Стоимость аппаратного интерфейса, как оценивают специалисты, является очень низкой. ADB поддерживает скорости передачи данных до 90 КБ, что достаточно для связи с клавиатурами, устройствами управления или другими настольными устройствами ввода - вывода. 

Access.bus (A.b)

Шина Access.bus разработана Access.bus Industry Group, основана на технологии Phillips I2 C и программной модели DEC . Области применения Access.bus - прежде всего клавиатуры и устройства управления; однако, A.b более универсальна чем ADB. Спецификация протокола хорошо определила динамическое присоединение, арбитраж, пакеты данных, конфигурацию, и интерфейс программного обеспечения. В то время как адресацией предусмотрено до 127 устройств, практическая загрузка ограничена длиной кабеля и возможностями при разводки питания. Изменение 2.2 определяет шину для операции со скоростью 100 КБ, но технология имеет запас(headroom), что позволит повысить ее до 400 КБ, используя туже синхронизацию и провода.

IEEE P1394

IEEE P1394 - высокоэффективная последовательная шина. Пространство использования P1394 - прежде всего жесткий диск и видео периферия, которые могут требовать большие возможности по быстродействию шины более 100 МБ. Протокол поддерживает, и изохронные и асинхронные передачи по тому же самому набору четырех проводов, разъединенных на дифференциальные пары сигналов данных и синхронизации.  Спецификация P1394 очень хорошо определена и первое поколение устройств , базирующееся на спецификации IEEE, только поступает в торговлю. Текущий тариф P1394 позволяет рассматривать эту шину как конкурент дисковому интерфейсу SCSI , но не текущим настольным системам связи.

CHI

Concentration Highway Interface (CHI) был разработан AT&T для терминалов и цифровых коммутаторов. CHI - полнодуплексный последовательный интерфейс с мультиплексированием и разделением во времени, предназначен для передачи голоса в цифровом виде в системах связи. Протокол состоит из набора фиксированных временных интервалов, которые могут нести речевые данные и управляющую информацию. Текущая спецификация поддерживает скорости передачи данных до 4.096 МБ. CHI шина имеет четыре сигнальных провода : Синхронизация(Clock), Кадрирование(Framing), Получаемые данные(Receive data), и Передаваемые данные(Transmit data). Оба сигнала, Кадрирование и синхронизация задаются централизованно (т.е., PBX переключателем).

GeoPort

GeoPort был первоначально разработан Apple Computer Inc, прежде всего для поддержки телефонии на Macintosh. В настоящее время спецификация GeoPort поддерживает скорости передачи данных до 2   МБ и обеспечивает соединение точка-точка в радиусе 4 футов. Стандарт GeoPort определяет 9-штырьковый разъем (8 штырьков и факультативный 9-ый штырек мощности) и использует протокол RS-422.  Дополнительно, Apple определил альтернативный вариант 14-штырьковый разъем с увеличенной длиной кабеля. GeoPort протокол обеспечивает три различных операционных режима: Beaconing, TDM, и режимы передачи Packetized.  Apple в настоящее время имеет патент на спецификацию GeoPort.

Глава 4

Краткий обзор архитектуры

В этой главе представлен краткий обзор архитектуры USB Шины и ключевых концепций.  USB - кабельная шина, которая поддерживает обмен данных между хост компьютером и широким диапазоном одновременно подключенных периферийных устройств. Присоединенные периферийные устройства совместно используют пропускную способность USB через планируемый маркерный протокол хоста. Шина позволяет присоединять, конфигурировать, использовать, и отсоединять периферийные устройства, в то время как хост и другие периферийные устройства находится в работе. Это также упоминается как динамическое (или горячее) присоединение и удаление.

Следующие главы описывают различные компоненты USB более подробно.

Низко Скоростные Транзакции

USB поддерживает две скорости передач сигналов: полно скоростная передача сигналов при 12.0 МБ и низко скоростная передача сигналов при 1.5 МБ. Концентраторы отключают трафик вниз по иерархии шины от всех портов, к которым присоединены низко скоростные устройства во время полно скоростной передачи сигналов вниз по иерархии. Это требуется, как из-за EMI, так и для предотвращения любой возможности восприятия низко скоростным устройством полно скоростного пакет, адресованного ему. На Рисунок 8-19 показана низко скоростная IN транзакция, в которой хост выдает маркер и квитирование и принимает пакет данных.

Рисунок 8-19.  Низко Скоростная Транзакция

Все нисходящие пакеты, которые передаются на низко скоростные устройства требуют преамбулы. Преамбула состоит из SYNC, за которым следует PID, посылаемые в полно скоростном режиме. Концентраторы должны воспринимать PRE PID; все другие устройства USB должны игнорировать его и обрабатывать его как неопределенный. По окончанию PID преамбулы, хост должен ждать по крайней мере четырех полно скоростных времени передачи бита, в течение которых концентраторы должны завершить процесс конфигурирования своих разделов повторителя, для приема низко скоростной передачи сигналов. В течение указанного интервала, концентраторы должны установить свои полно скоростные и низко скоростные порты в соответствующие остановленные состояния. Концентраторы должны быть готовы принять низко скоростную передачу сигналов от хоста до окончания интервала установки концентратора. Правила низко скоростного соединения представлены ниже:

1.       Низко скоростные устройства определяются во время подключения и порты концентратора, с которыми они соединены, определяются как низко скоростные.

2.       Все низко скоростные пакеты перемещаемые вниз по иерархии должны предваряться преамбулой (посылаемой в полно скоростном режиме) которая включает выходные буферы низко скоростных портов концентратора.

3.       Низко скоростные выходные буферы порта концентратора выключаются после получения EOP и не включаются снова, пока не будет обнаружена PID преамбула.

4.       В случае upstream соединения не имеет значение, является ли порт концентратора полно или низко скоростным.

Низко скоростная передача сигналов начинается с выдачи хостом SYNC на низкой скорости, за которым следует остаток пакета. Конец пакета определяется Концом Пакета (EOP- End of Packet), при этом все концентраторы разрывают соединения и отключают любые порты, к которым присоединены низко скоростные устройства. Концентраторы не переключают порты для передачи сигналов вверх по иерархии; низко скоростные порты остаются разрешенными для низко и полно скоростной передачи сигналов в направлении вверх по иерархии.

Низко и полно скоростные транзакции поддерживают высокую степень унифицированности протокола. Не смотря на это, низко скоростная передача сигналов имеет некоторые ограничения, которые включают:

Полезная нагрузка данных ограниченна - максимум восемь байт.

На низкой скорости поддерживаются только передачи прерывания и управления.

Пакет SOF не получается низко скоростными устройствами.

Обеспечиваемые Типы Канала(Supported Pipe Types)

Обеспечивается четыре типа каналов, основанный на четырех типах передачи, описаных ниже.

Обнаружение Ошибки и Восстановление

USB обеспечивает надежное, в смысле ошибок, соединение на физическом уровне передачи сигналов. Это включает способность обнаружить подавляющее большинство возможных ошибок и исправление ошибок на основании типа транзакции. Например транзакции управления, требуют высокой степени надежности данных; они поддерживают целостность данных "точка-точка", используя обнаружение ошибок и повторение передачи. Транзакции ISO, в связи с требованиями пропускной способности и требованиями времени ожидания, не разрешают повторениям и должны допускать возникновение неисправимых ошибок.

Обнаружение ошибок

Основная частота передачи ошибочных битов USB среды, как ожидается,  будет close to that of a backplane и любые сбои очень вероятно по характеру будут непостоянными. Чтобы обеспечивать защиту против таких переходных процессов, каждый из этих пакетов включает в себя поля защиты от ошибки. Когда требуется целостность данных, например в устройствах данных без потерь, процедура восстановления при ошибках может вызываться аппаратным или программным обеспечением. 

Протокол включает отдельный ЦКЧ(CRC) для полей управления и данных каждого пакета.  Неправильный ЦКЧ(CRC), указывает что пакет разрушен. ЦКЧ (CRC) дает 100 % гарантию обнаружения одиночных и двойных ошибок в разрядах .

Обнаружение Отсоединения Устройства

Концентратор способен обнаружить событие отсоединения посредством обнаружения в downstream порте непрерывного SE0, сохраняющегося по крайней мере 2.5 мс. В ответ на событие отсоединения, концентратор помещает порт в Disconnected состояние и переводит выходные буферы в Hi-Z. Отсоединение устройства может быть обнаружено только, в то время когда нет никакого трафика вниз по иерархии на шине. Если питание убрано от порта, он должен ответить, отмечая событие отсоединения и помещая порт в Powered Off состояние. Это гарантирует что, если отсоединено устройство и добавляется новое, то будет подтверждено событие присоединения.(This guarantees if a device is detached and a new one added that the attach event will be acknowledged.)

Обработка данных

Хост контроллер ответственен за получение данных от системы USB и посылки их в USB и для получения данных из USB и посылки их в USB систему. Специфический формат, используемый для передачи данных между USB системой и хост контроллером зависит от реализации, и находится внутри правил поведения передачи, описанных в Главе 5.

Обработка Информации Изменения Порта

Концентраторы сообщают состояние порта через команды порта на базисе работоспособных портов. Программное обеспечение хоста подтверждает изменение порта,  очищая состояние изменения, соответствующее изменению состояния, сообщенного концентратором. Подтверждение очищает состояние изменения для этого порта, поэтому последующие передачи данных к конечной точке Изменения Состояния не сообщают предыдущее событие. Это позволяет процессу повторяться при дальнейших изменениях (см. Рисунок 11-19.)

 

Рисунок 11-19. Метод Обрабатывающий Состояние Порта(Port Status Handling Method)

Обработка Ошибки в Передаче

Хост контроллер должен быть способен к обнаружению следующих условий ошибки в передаче, которые определены с " точка зрения " хоста :

Условия истечения времени ожидания после передачи хостом маркера или пакета. Эти ошибки происходят, когда адресованная конечная точка не отвечает или когда структура передачи так сильно повреждена, что конечная точка к которой адресована передача не распознает ее.

Ошибки в данных, приводящие к потере или недопустимым передачам.

-         Хост контроллер посылает или получает пакет короче чем требуется при передачи; например, передача выходящая за EOF или хост контроллеру недостаточно имеющихся ресурсов.

-         Недопустимое поле CRC на полученном пакете данных.

Ошибки Протокола.

-         Недопустимый PID квитирования. Например, плохо сформированное или несоответствующее квитирование.

-         Ложный EOP.

-         Ошибка вставки бит.

Для каждой транзакции bulk, командной и прерывания, хост должен поддержать подсчет числа ошибок. Ошибки происходят в результате условий, описанных выше, а не из-за  NAKитирования запроса конечной точкой. Это значение отражает число произошедших ошибок в транзакции при передаче. Если подсчитанное число ошибок для данной транзакции достигает трех, хост удаляет передачу. Когда передача удалена из-за чрезмерных ошибок, будет указан последний тип ошибки. Изохронные транзакции передаются только один раз, независимо от результата, и, следовательно, никакой счет ошибки не поддерживается для этого типа передач.

---

---