Синхронизация Часов

Для изохронных данных, которыми нужно управлять надежно,  идентифицировано выше трех часов, которые должны быть синхронизированы в некотором режиме. (In order for isochronous data to be manipulated reliably, the three clocks identified above must be synchronized in some fashion. ) Если часы не синхронизированы, у нескольких часов могут присутствовать следующие атрибуты часов, что может быть нежелательно( If the clocks are not synchronized, several clock to clock attributes can be present that can be undesirable):

Дрейф часов(Clock drift) - Двое часов, которые должны выполняются с одной и той же скоростью, могут на практике иметь различную реализацию, в результате одни часы выполняются быстрее или медленнее чем другие, более чем длительные периоды времени.(over long periods of time) Если не исправить это различие, сравнением одних часов с другими, возможно появление слишком большого или слишком небольшое количества данных, когда ожидаемые данные всегда будут присутствовать в требуемое время .(If uncorrected, this variation of one clock compared to the other can lead to having too much or too little data when data is expected to always be present at the time required.)

Флуктуация Часов(Clock jitter) - Часы могут изменить свою частоту через какое-то время из-за изменений в температуре, и т.д. Они могут также измениться после того, как данные сравнения фактически поставлены, когда ожидалось были поставлены(This may also alter when data is actually delivered compared to when it is expected to be delivered.)

Часы, чтобы синхронизировать различия фазы (Clock to clock phase differences )- Если двое часов не скреплены по фазе, различное количество данных может быть доступно в различных точках в то время как такт частоты часов выходит из цикла через какое-то время.(If two clocks are not phase locked, different amounts of data may be available at different points in time as the beat frequency of the clocks cycle out over time.) Это может вести к квантованию/выборке связанных артефактов.(This can lead to quantization/sampling related artifacts.)

Часы шины обеспечивают центральные часы, по которыми аппаратные устройства USB и программное обеспечение могут синхронизироваться по одному уровню или другому (The bus clock provides a central clock with which USB hardware devices and software can synchronize to one degree or another.) Однако, программное обеспечение не будет, полностью способно точно прикрепиться к фазе или частоте часов шины в текущей, операционной системе, поддерживающей планирование “подобно реальному времени”, поддерживающееся в большинстве операционных систем PC.(However, the software will, in general, not be able to phase or frequency lock precisely to the bus clock given the current support for “real time-like” operating system scheduling support in most PC operating systems.) Однако программное обеспечение, выполняющееся на хосте может, знать, что данные, перемещаемые в USB упакованы. Для изохронных типов передачи, одиночный пакет данных перемещается точно, если только он один в кадре и часы кадра приемлемо точны.(For isochronous transfer types, a single packet of data is moved exactly once per frame and the frame clock is reasonably precise.) Предоставление программному обеспечению этой информации позволяет ему корректировать количество данных подогнанных им к фактическому кадру время, которое передается.(Providing the software with this information allows it to adjust the amount of data it processes to the actual frame time that has passed.)

Синхронизация Переключения Данных и Повторная Передача

USB обеспечивает механизм гарантированной синхронизации последовательности данных между передатчиком и приемником  данных при множестве транзакций. Этот механизм обеспечивает средства гарантирования того, что фаза квитирования транзакции интерпретируется правильно и передатчиком и приемником. Синхронизация достигается используя PID'ы DATA0 и DATA1 и отдельные биты последовательности переключения данных для передатчика и приемника данных. Биты последовательности приемника переключаются только, когда приемник способен принять данные и получает пакет данных без ошибок с правильным PID данных. Биты последовательности передатчика переключаются только, когда передатчик данных получает правильное квитирование ACK. Передатчик и приемник данных должны иметь синхронизированные биты последовательности, в начале транзакции.(The data transmitter and receiver must have their sequence bits synchronized at the start of a transaction.) Используемый механизм синхронизации зависит от типа транзакции. Синхронизация переключения данных не поддерживается для передач ISO.

Синхронизация Таймера Кадра

Таймер кадра синхронизирован с часами-источником концентратора и синхронизирован через SOF пакеты с кадром времени хоста.( The frame timer is clocked from the hub’s clock source and is synchronized via SOF packets to the host’s frame time.) Когда концентратор соединен с хостом впервые, таймер кадра концентратора не синхронизирован относительно хоста. Когда обнаружен первый маркер SOF таймера кадра сбрасывается и начинает отсчитывать, с частотой в 12 MHZ; он продолжит считать, пока не будет обнаружен следующий маркер SOF. В это время таймер кадра сбрасывается, и предыдущее значение счета сохраняется как посчитанная длина предыдущего кадра (PFL - previous frame length). Это значение модифицируется для каждого кадра, в котором обнаружен и представлен SOF, в счетчике часов концентратора, время кадр хоста.(This value is updated for each frame in which an SOF is detected and represents, in hub clock counts, the host’s frame time.) Таймер кадра рассматривается как блокированный с хостом, когда различие между подсчетом PFL и текущим подсчетом в конце кадра - меньше чем 2 и PFL лежит между FLmin и FLmax.

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

Восстановление при ошибках концентратора, как описано в Разделе 11.4.5,  осуществляется всякий раз, когда блокируется таймер кадра концентратора. Если таймер кадра не блокирован, таймер использует FLmin как заданная по умолчанию длина кадра.

Синхронный тип

Синхронные конечные точки могут иметь свою систему часов (свое понятие времени) управляемую из вне через SOF синхронизацию. Эти конечные точки должны делать одно из следующего:

Подчинение своих выборок часов к 1 мс SOF импульса сигнала времени (посредством программируемого PLL (Slaving their sample clock to the 1 ms SOF tick (by means of a programmable PLL).

Управление скорость USB генерированием SOF так, чтобы их скорость передачи данных стала автоматически прикрепленной к SOF.(Controlling the rate of  USB SOF generation so that their data rate becomes automatically locked to SOF.) В случае, если этим конечным точкам не предоставляют главенство над SOF(SOF mastership), они должны вырождаться в асинхронный режим работы (обратитесь к асинхронному примеру).

Синхронные конечные точки могут быть источником или стоком изохронного потока данных или с фиксированной скоростью передачи данных (одно частотные конечные точки), при ограниченном числе скоростей передачи данных (32 кГц, 44.1 кГц, 48 кГц, …), или с непрерывно программируемой скоростью передачи данных(Synchronous endpoints may source or sink isochronous data streams at either a fixed data rate (single frequency endpoints), a limited number of  data rates (32 kHz, 44.1 kHz, 48 kHz, …), or a continuously programmable data rate.) Если скорость программируется, операция скорости передачи данных устанавливается в течение инициализации изохронной конечной точки (If programmable, the operating data rate is set during initialization of the isochronous endpoint.) Число выборок или модулей данных, сгенерированных в ряде кадров USB детерминировано и периодично.(The number of samples or data units generated in a series of USB frames is deterministic and periodic.) Синхронные устройства должны сообщить свои возможности программирования в дескриптор специфического класса конечной точки как описано в спецификации их Класса Устройства.(Synchronous devices must report their programming capabilities in the class specific endpoint descriptor as described in their Device Class specification.)

Пример синхронного источника - цифровой микрофон, который синтезирует типовые часы по SOF и производит фиксированное число звуковых выборок каждый кадр USB. Другая возможность - поток поток со скоростью 64 килобайта в секунду из “модема” ISDN. Если USB порождение SOF прекрипляется к часам PSTN (возможно через то же самое устройство ISDN), порождение данных будет также прикреплено к SOF, и конечная точка будет производить поток данных неизменно 64 килобайта в секунду, ссылаясь к понятию SOF времени.( If the USB SOF generation is locked to the PSTN clock (perhaps through the same ISDN device), the data generation will also be locked to SOF and the endpoint will produce a stable 64 kb/s data stream, referenced to the SOF time notion.)

Сконфигурированное Состояние

Прежде, чем функция устройства USB  может использоваться, устройство должно быть сконфигурировано. В зависимости от вида устройства, в конфигурацию включена запись ненулевого значения в регистр конфигурации устройства. Конфигурирование устройства или по причине изменения альтернативных установок всех состояний и значений конфигурации, связанные с конечными точками в затронутых интерфейсах, установит свои значениям по умолчанию.(Configuring a device or changing an alternate setting causes all of the status and configuration values associated with endpoints in the affected interfaces to be set to their default values.) Это действие включает установку переключателя данных любой конечной точки, использущей переключатели данных, к значению DATA0.

Скорость Передачи Сигналов Данных

Скорость полно скоростной передачи данных номинально составляет 12 МБ. Допуск в скорости передачи данных для хоста, концентратора, и полно скоростных функций составляет ±0.25 % (2500 ppm). Точность скорости передачи данных хост контроллера должна быть известна точнее чем

±0.05% (500 ppm) чтобы точно совпасть с интервалом кадра. Этот допуск включает погрешности всех источников: начальная точность частоты, кристаллическая емкостная нагрузка, обеспечиваемое напряжение на генераторе, температура, и старение.

Скорость низко скоростной передачи данных номинально составляет 1.5 МБ. Разрешенный допуск частоты для низко скоростных функций ±1.5% (15000 ppm). Этот допуск включает погрешности всех источников: начальная точность частоты, кристаллическая емкостная нагрузка, обеспечиваемое напряжение на генераторе, температура, и старение. Флуктуация у скорости низко скоростной передачи данных должна быть меньше чем 10 нс. Этот допуск позволяет использовать резонаторы в дешевых, низко скоростных устройствах.

Слежение за SOF

Функции, поддерживающие изохронные каналы должны получить и понять лексему SOF, чтобы поддерживать предбуферирование как описано ранее. При условии, что SOFs могут быть разрушены, устройство должно быть подготовлено, чтобы оправиться от разрушенного SOF. Эти требования касаются только полно скоростных устройств при изохронных передачах, так как низко скоростные устройства не видят SOFs на шине.(These requirements limit isochronous transfers to full speed devices only, since low speed devices do not see SOFs on the bus.) Также, так как SOF пакеты могут быть повреждены при передачи, устройства поддерживающие изохронные передачи, должны уметь синтезировать существование SOF, который они не могут видеть из-за ошибки на шине.

Изохронные передачи требуют, чтобы  соответствующие данные были переданы в соответствующем кадре. USB требует, что, когда обеспечена изохронная передача к хост контроллеру, это идентифицирует номер кадра для первого кадра. (USB requires that when an isochronous transfer is presented to the host controller, it identifies the frame number for the first frame.) Хост контроллер не должен передать первую транзакцию прежде чем будет указан номер кадра. Каждая последующая транзакция из IRP должна передаваться в успешных(succeeding) кадрах. Если нет задержанных транзакций для текущего кадра, то хост контроллер ничего не передаст по изохронному каналу.(If there are no transactions pending for the current frame, then the host controller must not transmit anything for an isochronous pipe.) Если указаный номер кадра передан, хост контроллер должен пропустить (то есть, не передавать) все транзакции, пока номер соответствующий текущему кадру не достигнут.(If the indicated frame number is passed, the host controller must skip (i.e., not transmit) all transactions until the one corresponding to the current frame is reached.)

Слежение за Транзакцией

Функция USB видит поток данных, перемещающихся по шине в виде пакетов, как описано в Главе 8 (A USB function sees data flowing across the bus in packets as described in Chapter 8.) Хост контроллер использует некоторое зависимое от реализации представление, чтобы проследить какие пакеты передаются на/из какой конечной точки, в какое время или в каком порядке (The host controller uses some implementation dependent representation to track what packets to transfer to/from what endpoints at what time or in what order.) Большая часть клиентского программного обеспечения не хочет иметь дело с упакованными потоками связи, так как это включает степень сложности и зависимость взаимосвязи, что ограничивает реализацию. (Most client software does not want to deal with packetized communication flows since this involves a degree of complexity and interconnect dependency that limits the implementation.) Программное обеспечение системы USB(USBD и HCD) обеспечивает поддержку соответствия требований клиента по движению данных, пакетам на шине. Аппаратные средства и программное обеспечение хост контроллера используют IRPs, чтобы проследить информацию об одной или более транзакциях, которые объединяются, чтобы осуществить передачу информации между клиентским программным обеспечением и функцией. Рисунок 5-11 подводит итог, как организованы транзакции в IRPs для четырех типов передачи. Информация о деталях протокола для каждого типа передачи может быть найдена в Главе 8. Подробная информация о взглядах клиентского программного обеспечения на IRPs может быть найдена в Главе 10 и в специфической информации определяемой операционной системой для особой операционной системы.

Рисунок 5-11. Передачи для Потоков Связи

Даже при том, что IRPs прослеживают транзакции шины, которые должны происходить, при перемещении специфического потока данных по USB, хост контроллеры свободны от выбора того, как специфические транзакции шины перемещаются по шине, подчиняясь ограничениям определенным USB; например, точно одна транзакция за кадр для изохронных передач (Even though IRPs track the bus transactions that need to occur to move a specific data flow over USB, host controllers are free to choose how the particular bus transactions are moved over the bus subject to the USB defined constraints; e.g., exactly one transaction per frame for isochronous transfers.) В любом случае, конечная точка будет видеть транзакции в том порядке, в котором они появляются внутри IRP, если не происходят ошибки. Например, Рисунок 5-12 показывает два IRPs, по одному на каждый из двух каналов, где каждый IRP содержит три транзакции. Для любого типа передачи, свободный хост контроллер, перемещает первую транзакцию первого IRP, следом первую транзакцию второго IRP куда-нибудь в Кадр 1, вторые транзакции каждого IRP перемещает в противоположном порядке куда-нибудь в Кадр 2. Если это изохронные типы передач, у хост контроллера имеется единственная степенью свободы. Если это передачи управления или bulk, хост контроллер мог бы дополнительно переместить больше или меньше транзакции из любого IRP внутрь любого кадра. Функции не могут зависеть от наблюдения транзакций внутри IRP обратно к обратно внутри кадра.(Functions cannot depend on seeing transactions within an IRP back to back within a frame.)

Рисунок 5-12. Расположение Транзакций IRPs в Кадрах

Согласование Сигналов(Signal Termination)

Согласование концов концентратора USB и функции показано на Рисунке 7-5 и Рисунке 7-6. Полно скоростные и низко скоростные устройства различающиеся позицией подсоединенного к питанию резистора на конце downstream кабеля.(Full speed и low speed devices are differentiated by the position of the pull-up resistor on the downstream end of the cable.) Полно скоростные устройства согласованы как показано на Рисунок 7-5 с присоединенной к питанию линией D +.( Full speed devices are terminated as shown in Рисунок 7-5 with the pull-up on the D+ line) Низко скоростные устройства согласованы как показано на Рисунок 7-6 с присоединенной к питанию линией D-. 

Присоединенный к питанию согласующий резистор в 1.5 kW ±5 % имеет источник напряжения между 3.0 В и 3.6 В, связанный с локальной землей. (The pull-up terminator is a 1.5 kW ±5% resistor tied to a voltage source between 3.0 V и 3.6 V referenced to the local ground.) Присоединенные к земле согласующие - резисторы 15 kW ± 5 %, соединенные со своей локальной землей.(The pulldown terminators are resistors of 15 kW ±5% connected to their local ground.)

Рисунок 7-5.  Кабель Полно Скоростного Устройства и Подсоединение Резисторов

Рисунок 7-6. Кабель Низко Скоростного Устройства и Подсоединение Резисторов

Сохранение в Работе при Низкой Скорости

Все порты концентратора, с которыми соединены низко скоростные устройства, должны генерировать низко скоростной сохраняющий в работе строб, сгенерированный в начале кадра, который состоит из двух низко скоростных времен передачи бита SE0, за которыми следует J состояние по крайней мере 0.5 времени передачи бита. Низко скоростные устройства используют строб, чтобы не допустить себе перехода в подвешивание в отсутствии низко скоростного трафика на шине. Повторитель концентратора генерирует сохранение в работе от внутреннего SOF счетчика, и сохраняющий в работе строб должен начаться только после второго EOF и должен завершиться не позже чем EOP маркерного пакета.

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

1.       При переходе в подвешивание, сохранение в работе не должно выдаваться перед последним SOF.

2.       Концентратору позволено синтезировать не более, чем три сохраняющих в работе строба после получения последнего SOF.

3.       Сохранение в работе должно произойти не позже чем через один кадр после возобновления SOF.

Сообщение о Состоянии и Сервисы Восстановления При Ошибках

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

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

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

Сообщение Результатов Состояния(Reporting Status Results)

Стадия Состояние сообщает на хост результат предыдущих стадий передачи Установки и Данных. Возможно возвратить следующие три результата:

Последовательность команд, завершена успешно.

Последовательность команд не может завершиться из-за ошибки.

Функция все еще занята завершением команд.

Сообщение о Состоянии всегда имеет направление от функции к хосту. В таблице приведены типы ответов, требуемых для каждого результата. Передача управляющей записи возвращает информацию о Состоянии фазы данных передачи.( Control write transfers return status information on the data phase of the transfer.) Передача управляющего чтения возвращает информацию о Состоянии передач в фазе квитирования после того, как хост выдал пакет данных нулевой длины в течение предыдущей фазы данных.

Таблица 8-5.  Ответы Фазы Состояние

Ответ Состояние		Передача Управляющей Записи (посылается в течение фазы данных)		Передача Управляющего Чтения (посылается в течение фазы квитирования)
Функция завершена		Пакет данных нулевой длины		квитирование ACK
В функции ошибка		квитирование STALL		квитирование STALL
Функция занята		квитирование NAK		квитирование NAK

Для управляющего чтения, хост посылает пакет данных нулевой длины управляющей конечной точке.(For control reads, the host sends a zero length data packet to the control endpoint.) Ответное квитирование от конечной точки говорит о состоянии при завершении. NAK указывает, что функция все еще обрабатывает команду и что хост должен продолжить фазу состояние. ACK указывает, что функция завершила команду и готова принять новую команду, и STALL указывает, что произошла ошибка в функции, которая мешает завершить команду.

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

Если, в течение стадии Данных или Состояние, командная конечная точка посылает или запрашивает большее количество данных, чем было указано в стадии Установка, то она (???ей) должна возвратить STALL.( If, during a Data or Status stage, a command endpoint is sent more data or is requested to return more data than was indicated in the Setup stage, it should return a STALL.) Если управляющая конечная точка возвращает STALL в течение стадии Данных, то стадия Установка будет отсутствовать в этой передачи управления .

Состояние По Умолчанию

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

Состояние Под Напряжением

Устройства USB могут получать мощность от внешнего источника и-или от  концентратора USB, к которому они присоединены. Устройство USB питающееся из вне называется с независимым питанием. Эти устройства могут уже быть запитаны прежде, чем они присоединены к USB. Устройство может поддерживать конфигурацию, как с независимым питанием так и с питанием от шины. Некоторые устройства сконфигурированы для поддержания любого источника питания. Другие устройства сконфигурированы так, что могут использоваться, если устройство запитано из вне. Устройства сообщают свои возможности об источнике питания через Дескриптор Конфигурации. О текущем источнике питания сообщается как о части состояния устройства. Устройства могут изменять свои источники питания в любое время; например, от само- к питающимся от USB. Если конфигурация поддерживает оба режима питания, сообщение о максимальном питании для этой конфигурации будет максимальное питание  устройства при любом режиме.(If a configuration is capable of supporting both power modes, the power maximum reported for that configuration is the maximum the device will draw in either mode.) Устройство должно наблюдать этот максимум, независимо от режима. Если конфигурация поддерживает только один режим питания и источник питания устройства изменен, устройство потеряет текущую конфигурацию, адрес и возвратиться в присоединенное состояние.

Порт концентратора должен быть включен, чтобы обнаружить изменения состояния порта, включая присоединение и отсоединение. Концентраторы не обеспечивают никого вниз по иерархии мощностью, пока они не сконфигурируют, в какой точке они будут обеспечиваться питанием, учитывая требования их конфигурации и источника питания.  Устройство USB должно быть способно адресоваться внутри определенного периода времени, когда питание первоначально подано (обратитесь к Главе7). После того, как было обнаружено присоединение к порту, хост разрешит работать порту, который также сбросит устройство, присоединенное к порту.(After an attachment to a port has been detected, the host shall enable the port, which will also reset the device attached to the port.)

Состояния Порта Концентратора

Downstream порт концентратора может быть в одном из четырех или пяти возможных состояний и должен охватывать такие возможности как обнаружение соединения/разъединения, разблокированние/блокирование порта, подвешивание/возобновление, сброс, и, необязательно, переключение мощности. Концентраторы должны поддерживать независимые конечные автоматы порта на  базисе работоспособности downstream порта.(Hubs must support independent port state machines on a per downstream port basis.) Рисунок 11-4 иллюстрирует состояния порта не поддерживающего переключение мощности, а Рисунок 11-5 показывает состояния  порта поддерживающего переключение мощности. Состояния порта концентратора применяется только к downstream портам.

Рисунок 11-4.  Состояния Порта Концентратора Не Поддерживающего Переключение Мощности

Рисунок 11-5. Состояния Порта Концентратора Поддерживающего Переключение Мощности

Каждое из состояний описано ниже.

Выключенное питание(Powered off): Это состояние поддерживается только для портов, которые имеют переключение мощности, как показано на Рисунок 11-5. Переходы порта к состоянию powered off происходят, когда концентратор получает запрос ClearPortFeature(PORT_POWER), или когда концентратор обнаруживает на корневом порте сигнал сброса. Downstream порты концентратора также переходят к состоянию powered off, когда первоначально подается питание на концентратор. Порт в powered off состоянии не обеспечивает никакую мощность вниз по иерархии и буфера выходных сигналов помещены в Hi-Z состояние. Порт в powered off состоянии игнорирует всякое действие направленное вверх по иерархии шины по этому порту.

В разъединении(Disconnected):  Downstream порт концентратора, обеспечивающего переключение мощности переходит от powered off в disconnected состояние, когда мощность подается на порт через запрос SetPortFeature(PORT_POWER). Если концентратор не поддерживает переключение мощности, он переходит в состояние disconnected  после подачи питания или получения по корневому порту сброса. В состоянии disconnected, порт не может распространять любые сигналы в направлении вверх или вниз по иерархии. Однако, порт может обнаружить событие соединения (conn_det), которое устанавливает поле состояния в контроллере концентратора и вызывает переход состояния порта к disabled состоянию.

Conn_det утвержден, если downstream порт находится в disconnect состоянии и в течении 2.5 мс обнаруживается на шине непрерывнй не SE0 сигнал. Когда conn_det утвержден впервые, состояние шины idle может быть изменено или низко или полно скоростным устройством, и может быть или DIFF0 или DIFF1. Концентратор автоматически определяет тип устройства (низко или полно скоростное) по тому тянется ли D+ или D- вверх. Определение скорости устройства завершается перед переходами концентратора к disabled состоянию.

Заблокированное(Disabled):  Порт переходит в disabled состояние из состояния disconnected, когда он обнаруживает событие соединения (conn_det). Это требует для того, чтобы на порт сначала было подано питание, если концентратор поддерживает переключение мощности. Порт в disabled состоянии может только распространять направленные вниз по иерархии сигналы, являющиеся результатом запроса SetPortFeature (RESET); во все другое время, буферы вывода порта находятся в Hi-Z состоянии. В направлении вверх по иерархии, порт в состоянии disabled не распространяет никакие сигналы через концентратор к корневому порту, когда концентратор активен. Однако, некоторые события, типа разъединение, заставит распространяться сигналы возобновления вверх по иерархии к корневому порту, если концентратор находится в suspended состоянии. Событие разъединения (disc_det) заставит порт возвращаться к disconnect состоянию и установит поле состояния в контроллере концентратора. Disc_det утвержден всякий раз, когда порт обнаруживает в течении 2.5 мс непрерывный SE0, когда порт не распространяет downstream трафик. Прежде, чем событие разъединения может быть установлено концентратором, приостановленный концентратор должен сначала пробудиться.

Разблокированное(Enabled): Порт переходит к enabled состоянию после получения  запроса SetPortFeature (PORT_ENABLE) или SetPortFeature (PORT_RESET). В enabled состоянии порт распространяет все сигналы вниз по иерархии, трафик полно скоростных пакетов и сигнал сброса; распространяет трафик низко скоростных пакетов вниз по иерархии, когда предшествует PID преамбула. В состоянии enabled, порт распространяет все сигналы вверх по иерархии, включая полно и низко скоростные пакеты и сигналы продолжения. Порт переходит в disabled состояние, если он получает  запрос ClearPortFeature (PORT_ENABLE) или если происходит ошибка кадра (fr_error). Хост может выдать запрос ClearPortFeature (PORT_ENABLE) в любое время, и концентратор должен ответить, немедленно помещая порт в состоянии disabled. Порт в enabled состоянии будет переходить к disconnected состоянию, если происходит обнаружение разъединения.



Подвешенное(Suspended): Концентратор выборочно подвешивает все устройства downstream порта, когда он получает запрос SetPortFeature (PORT_SUSPEND). Этот запрос не должен заставить уже приостановленный порт прекращать распространять транзакцию на середине; то есть, текущая транзакция должна завершиться прежде, чем порт вводится в suspended состояние. Порт проявляет различное поведение связности подвешивания в зависимости от того, является ли концентратор активным или самостоятельно подвешен.( A port displays different suspend connectivity behavior depending on whether the hub is awake or is itself suspended.) Если концентратор активен, нет вверх и вниз по иерархии связи которая может распространяться через порт.( If the hub is awake, no upstream or downstream connectivity can propagate through the port.) Однако, если концентратор подвешен,то переход от idle к возобновлению, или от idle к SE0 на порте отражается на все другие не-disabled порты как переход от idle к возобновлению. Это поведение делает возможным подвесить последовательно множество концентраторов и все еще иметь устройство в нижней части способное пробудить всю шину.

Если концентратор подвешен, и действие шины происходит на подвешенном порте, сначала пробуждается концентратор. Согласование запроса возобновления с портом заставляет установить поле состояния в концентраторе. В ответе, хост опрашивает концентратор, чтобы считать изменения и  определения в поле состояния, которые произошли при возобновлении порта. Порт концентратора переходит в enabled состояние, когда возобновление завершено. Подробно сигналы порта концентратора для выборочного возобновления описаны в Разделе Ошибка! Источник ссылки не найден..

 Событие разъединения к подвешенному концентратору вызывает переход состояния концентратора к состоянию disconnected и устанавливает поле состояния контроллера концентратора, чтобы указать, что произошло разъединение. Не возможно поместить порт disconnected непосредственно в suspend режим, так как порт никогда не выходит из disconnected состояния.



Таблица 11- 1 подводит итог поведения порта концентратора в различных состояниях порта для различных типов сигналов. Поведение Концентратора в течение сигналов возобновления, когда концентратор непосредственно находится в suspend состоянии, составляет специальный случай, и обсуждается в Разделе 11.5.2.1.

Таблица 11-1.  Реакция Порта на Сигналы

Сигнал\Состояние	Powered-off	Disconnected	Disabled	Enabled	Suspended
Сброс на корневом порте (концентратор с переключением мощности)	Остаться в Powered-off	Перейти в Powered off	Перейти в Powered off	Перейти в Powered off	Перейти в Powered off
Сбросьте на корневом порте (концентратор без переключения мощности)	N.A.	Перейти в Disconnected	Перейти в Disconnected	Перейти в Disconnected	Перейти в Disconnected
ClearPortFeature(port_power)(концентратор с переключением мощности)	Остаться в Powered-off	Перейти в Powered off	Перейти в Powered off	Перейти в Powered off	Перейти в Powered off
SetPortFeature(port_power)(концентратор с переключением мощности)	Перейти в Disconnected	N.A.	N.A.	N.A.	N.A.
Запрос SetPortFeature (port_reset)	Остаться в Powered off	Перейти в Enabled	Перейти в Enabled	Остаться в Enabled	Перейти в Enabled
Запрос SetPortFeature (port_enable)	Игнорируется	Игнорируется	Перейти в Enabled	Остаться в Enabled	Игнорируется
Запрос ClearPortFeature (port_enable)	Игнорируется	Игнорируется	Остаться в Disabled	Перейти в Disabled	Игнорируется
Трафик пакетов вниз по иерархии (Концентратор активен)	Не распространять	Не распространять	Не распространять	Передать трафик	Не распространять
Трафик пакета вверх по иерархии (концентратор активен)	Не распространять	Не распространять	Не распространять	Передать трафик	Установить поле состояния, не  распространять
Запрос SetPortFeature (port_suspend)	Игнорируется	Игнорируется	Игнорируется	Перейти в Suspend	Игнорируется
Запрос ClearPortFeature (port_suspend)	Игнорируется	Игнорируется	Игнорируется	Игнорируется	Перейти в Resume
Обнаружено разъединение	Игнорируется	Игнорируется	Перейти в Disconnected	Перейти в Disconnected	Перейти в Disconnected
Событие Соединения	Игнорируется	Перейти в Disabled	N.A.	N.A.	N.A.

Состояния Повторителя Концентратора

Для соединений вверх по иерархии, повторитель концентратора переходит между четырьмя состояниями: ожидание начала пакета (WFSOP - wait for start of packet), ожидание конца пакета (WFEOP - wait for end of packet ), ожидание точки EOF2 (WFEOF2 - wait for EOF2 point), и ожидание начало кадра (WFSOF - wait for start of frame). EOF1 и точки EOF2 описаны в Разделе 11.4.5.1. Четыре состояния описана ниже. Для соединений вниз по иерархии, концентратор переходит между WFSOP, WFEOP, и WFSOF.

Состояния Устройства USB

Устройство USB имеет несколько возможных состояний. Некоторые из этих состояний видимы USB и хостом, а другие внутренние состояния устройства USB. Этот раздел описывает эти состояния.

Создаваемые по умолчанию каналы

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

Специальное Рассмотрение Изохронных Передач

Поддержка изохронного движения данных между хостом и устройством одна из возможностей системы, поддерживаемых USB. Надежность поставки изохронных данных в USB требует четкого внимания к деталям.(Delivering isochronous data reliably over USB requires careful attention to detail.) Ответственность за надежную поставку разделена между несколькими сущностями USB: устройство/функция, шина, хост контроллер, и один или больее агентов программного обеспечения. Так как время - ключевая часть изохронной передачи для проектировщиков USB важно понять, как разделено время внутри USB между этими различными сущностями.

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

В любой системе связи, передатчик и приемник должен быть хорошо синхронизированы, чтобы доставлять правильные данные (In any communication system, the transmitter and receiver must be synchronized enough to deliver data robustly.) В асинхронной системе связи, данные могут быть доставлены правильно, передатчик имеет возможность обнаружить, что приемник не получил элемент данных правильно и просто повторить передачу данных.

В изохронной системе связи, чтобы поставить данные правильно, передатчик и приемник остаются во времени и с синхронизированными данными. (In an isochronous communication system, the transmitter and receiver remain time and data synchronized to deliver data robustly.) USB не поддерживает повторение при изохронной передачи данных так, что будет возможно распределение минимальной пропускной способности изохронных передач, и не будет потеряна синхронизация во времени из-за задержки повторения. Однако, это критично, потому что изохронная пара USB передатчик/приемник остаются синхронизированными, и в нормальных случаях передачи данных и в случаях, когда происходят ошибки на шине.

Список Транзакций

Список транзакций - зависимое от реализации хост контроллера описание текущего ожидающего обработки множества транзакций шины, которые должны быть переданы по шине. Типичный список транзакций состоит из ряда описаний кадра в некотором представление (representation) зависимом от реализации хост контроллера. Только HCD и хост контроллер имеют доступ к специфическому представлению. Каждое описание кадра содержит описание транзакции, в котором определены параметры такие как размер данных в байтах, адрес устройства и номер конечной точки, и область памяти, в которую данные должны быть посланы или получены.(Each frame description contains transaction descriptions in which parameters such as data size in bytes, the device address and endpoint number, and the memory area to which data is to be sent or received are identified.)

Список транзакций и вид интерфейса между HCD и хост контроллером обычно зависит от реализованного режима и явно не определен как часть спецификации USB.(A transaction list and the interface between HCD and its host controller is typically represented in an implementation dependent fashion and is not defined explicitly as part of the USB specification.)

Список Возможностей

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

Простота использования конечным пользователем

Одна и та же модель для соединения и соединителей

Электрические подробности изолированы от конечного пользователя; например, завершения (terminations) шины

Самоидентификация периферийных устройств, автоматическое отображение функции к драйверу, и конфигурации

Возможность динамически присоединять и реконфигурировать периферийные устройства

Широкий диапазон рабочих нагрузок и приложений

Широкие возможности по скорости для различных устройств в пределах от нескольких КБ до нескольких МБ

Поддерживаются как изохронные так и асинхронные типы передачи данных по тем же самым проводам

Различные Соединения: Поддержка параллельных операций для многих устройств

Поддержка до 127 физических устройств

Поддерживается передача множественных данных и потоков сообщения хостом и устройствами

Поддержка составных устройств; то есть, периферийных устройств состоящих из многих функций

Lower protocol overhead resulting in high bus utilization 

Требования по быстродействию при изохронных передачах 

Гарантируемое требование по быстродействию  и малое время оклика приспособлены для телефонии, аудио, и т.д.

Изохронная передача может использовать все возможности по быстродействию шины

Гибкость

Широкий диапазон размеров пакета, предоставляет широкий диапазон опций буферизации устройства

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

Встроенное в протокол управление потоком данных при буферной обработке

Помехоустойчивость

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

Dynamic insertion and removal of devices identified in user perceived real-time

Поддержка обнаружения отказавших устройств

Легко вписываемая в PC индустрию

Простой протокол при выполнении и интегрировании

Непротиворечивость с PnP архитектурой PC

Согласуется с существующими интерфейсами операционных систем

Дешевизна реализации

Дешевый подканал в 1.5 МБ

Оптимизированный для интеграции с периферией и аппаратными средствами хостов

Подходит для разработки дешевых периферийных устройств

Дешевые кабели и соединители

Используются основные (commodity) технологии

Пути обновления

Улучшение архитектуры для поддержания различных хост - контроллеров USB Шины в системе

Стандартные Дескрипторы

Класс концентратора предопределяет некоторые поля в стандартных  дескрипторах USB. Другие поля или зависят от реализации или не применимы в этом классе.

Обратите внимание: Для дескрипторов и полей, показанных ниже, биты в поле организованы в режиме младшими разрядами вперед; то есть расположение бита 0 - самый младший бит и расположение бита 8 - старший значащий бит значения байта.

Дескриптор Устройства

      bDeviceClass                                         =          HubClass

      bDeviceSubClass                                   =          HubSubClass

      wMaxPacketSize0                     =          8 bytes

Дескриптор Интерфейса

      bNumEndpoints                         =          1

      bInterface                                                          =          1

Дескриптор Конфигурации

MaxPower                                               =          Максимальное количество мощности от шины которое

                                                                                      

потребляет концентратор в этой конфигурации.

Дескриптор Конечной Точки (для Конечной Точки Изменения Состояния)

      bEndpointAddress                      =          Зависит от реализации

      wMaxPacketSize                                   =          Зависит от реализации

      bmAttributes                                          =          Направление = In, Тип Передачи = Прерывание (0b00000111 )

      bInterval                                                            =          0xFF (Максимально допустимый интервал)

Драйвер класса концентратора извлекает конфигурацию устройства от системного программного обеспечения хоста, используя запрос устройства GetDescriptor. Первый дескриптор конечной точки, возвращенный на запрос GetDescriptor, по спецификации, дескриптор конечной точки Изменения Состояния. Концентраторы могут определять дополнительные конечные точки вне минимума, требуемого в этом определении класса. Однако, концентраторы, согласованные с этим стандартным классом всегда возвращают конечную точку Изменения Состояния как первый дескриптор конечной точки в стандартном интерфейсе.

Стандартные Запросы

Таблица 11-10.   Ответы Концентратора на Стандартные Запросы Устройства

bRequest		Ответ Концентратора
clear_feature		Стандартный
GET_CONFIGURATION		Стандартный
GET_DESCRIPTOR		Стандартный
GET_INTERFACE		Необязательный.  Концентраторы требуют поддерживать только один интерфейс
GET_STATUS		Стандартный
SET_ADDRESS		Стандартный
SET_CONFIGURATION		Стандартный
SET_DESCRIPTOR		Необязательный
set_feature		Стандартный
SET_INTERFACE		Необязательный. Концентраторы требуют поддерживать только один интерфейс
synch_frame		Необязательный. Концентраторы требуют поддерживать только один интерфейс

Становление Главным Клиентом

USBDI должен позволить клиенту запрашивать становление главным клиентом для данной USB и освобождать эту возможность, когда она больше не требуется. Только главные клиенты могут корректировать SOF для данной USB.

Клиент, запрашивающий статус главного идентифицируя себя с handle интерфейса для устройства, из которого он управляет.

Строка

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

Строковые дескрипторы используют кодирование UNICODE как определено в Стандарте Unicode, Международного Кодирования Символов, Версия 1.0, Тома 1 и 2, The Unicode Consortium, Addison-Wesley Publishing Company, Reading, Штат Массачусетс. Строки в устройстве USB  могут поддерживать множество языков. При запросе строкового дескриптора, запросчик определяет требуемый язык, используя шестнадцатиразрядный языковой ID (LANGID) определенный Microsoft для Windows как описано в Разработка Международного Программного обеспечения для Windows 95 и Windows NT, Nadine Kano, Microsoft Press, Redmond, Вашингтон. Строковый индекс 0 для всех языков возвращает массив двух байтных кодов LANGID поддерживаемых устройством.(String index 0 for all languages returns an array of two-byte LANGID codes supported by the device.)  Устройство USB может опускать все дескрипторы строк.

Дескриптор строки UNICODE - не завершается NULL. Длина строки вычисляется вычитая два из значения первого байта дескриптора.

Смещение		Поле		Размер		Значение		Описание
0		bLength		1		Число		Размер этого дескриптора в байтах
1		bDescriptorType		1		Константа		Тип дескриптора STRING
2		bString		N		Число		Строка в формате UNICODE

Структура Концентратора

Рисунок 11-1 Показывает концентратору и расположение его корневого и downstream портов.  Концентратор состоит из секции повторителя и секции контроллера концентратора. Повторитель ответственен за управление связью на базисе пакета, в то время как контроллер концентратора предоставляет состояние и управление и разрешает хосту доступ к концентратору.(The repeater is responsible for managing connectivity on a per packet basis, while the hub controller provides status and control and permits host access to the hub.)

Рисунок 11-1.  Структура Концентратора

Связь с Устройством

Модель связи USB характеризует данные и трафик управления между хостом, и данным устройством через взаимосвязь USB. Хост и устройство разделен на отдельные уровни, показанные на Рисунке 9-2.

Рисунок 9-2.  Модель Межуровневой Связи

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

Этот раздел описывает модель связи с точки зрения устройства и его уровней.  Рисунок 9-3 иллюстрирует, основанный на полном просмотре, представленном в Главе 8, виде связи устройства с хостом.

Рисунок 9-3.  Набор Связей в Устройстве

Интерфейс шины USB управляет взаимодействиями на электрическом и протокольном уровнях (обратитесь к Главам 7 и 8). Уровень устройства USB представляет устройство USB на хост, как однородную абстракцию. Это тот уровень, который прежде всего описан здесь. Функциональный уровень использует возможности, предоставляемые уровнем устройства USB, объединенные в данном интерфейсе, поддерживает требования хост-основанного приложения. (to support the requirements of a host-based application.)

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

Управление

Изохронный

Прерывание

Bulk

Эти типы передачи описаны более подробно в Главе 5.  Однако, каждый из типов передачи, требует, чтобы связанная конечная точка вела себя в некотором режиме.( Each of the transfer types, however, requires the associated endpoint to behave in a certain fashion.) Данная конечная точка может поддерживать ряд типов передачи. Однако, только один канал связывается с конечной точкой, конечная точка использует только один тип передачи. В этом разделе, при обсуждении поведения конечной точки для данного типа передачи, принимается, что конечная точка была связана с каналом, обеспечивающим соответствующий тип передачи. Основные механизмы связи, используемые конечными точками это:

Режим Канала

Синхронизация Начала Кадра (SOF)

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

Переключение Данных

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

Трафик между клиентом и функцией может требовать некоторой скорости передачи. Клиент, USB и функция будут использовать, в лучшем случае немного различные скорости часов. Чтобы гарантировать, что, все требуемые данные могут быть поставлены с минимальным требованием буферизации, различные часы, должны быть синхронизированы. Обратитесь к Главе 5 для ознакомления с параметрами синхронизации. Дополнительно, чтобы поддерживать возможность своевременной поставки, подразумеваемую синхронизацией часов, размер пакетов данных, которые передают между хостом и устройством будет нормализован так, чтобы изменения в размере через какое-то время были минимальны.(Additionally, in order to support the just-in-time delivery capability implied by clock synchronization, the size of the data packets transmitted between the host and the device will be normalized such that variations in size over time are minimized.) Для поддержания потока данных, в котором потеря данных является возможной, пока потеря может быть точно сообщена, могут использоваться типовые заголовки хоста и устройства, которые сообщают ожидаемые объемы передачи. Обратитесь к Главе 5 для определения типовых заголовков.

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

Связность Концентратора(Hub Connectivity)

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

Связность Сигнализации Пакета(Packet Signaling Connectivity)

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

Рисунок 11-2.  Связность Концентратора

Если downstream порт концентратора разблокирован (то есть, в состоянии, когда он может распространять сигналы через концентратор) и концентратор обнаруживает SOP на этом порте,  устанавливается связь в направлении вверх по иерархии к корневому порту этого концентратора, но не к другим downstream портам. С помощью этого средства, когда устройство или концентратор передает пакет вверх по иерархии, пакет будет виден только концентраторам  находящимся в линии между устройством передачи и хостом. Когда обнаружен SOP на upstream порте, все другие downstream порты блокируются. Это гарантирует, что связь концентратора не будет изменяться, пока не будет обнаружен следующий EOP или пока не выйдет время концентратора  в конце кадра.(This guarantees that hub connectivity will not be modified until the next EOP is detected or until the hub times out at the end of the frame.)

В направлении вниз по иерархии, концентраторы функционируют в широковещательном режиме. Когда концентратор обнаруживает SOP на корневом порте, он устанавливает связь со всеми разблокированными downstream портам. Если порт не разблокирован, он не получает никакой активности трафика пакета от корневого порта и не распространяет сигнальные пакеты вниз по иерархии.(If a port is not enabled, it does not receive any packet traffic activity from the root port and does not propagate packet signaling downstream.)

Связываемость

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

Модель предусматривает ситуации со многими-источниками/многими-стоками.

Рисунок 5-15 иллюстрирует типичную ситуацию (сильно сжатая и незавершенная)(highly condensed and incomplete). Физическое устройство соединено с прикладным программным обеспечением хоста через различные уровни аппаратных средств и программного обеспечения как описано в спецификации USB. В клиентском уровне интерфейса, приложение представлено как “виртуальное” устройство. (At the client interface level, a “virtualized” device is presented to the application.)  С точки зрения приложения, существуют только виртуальные устройства. Оно до драйвера устройства и клиентского программного обеспечения, решает то, какие точно зависимости есть между физическим и виртуальным устройством.(It is up to the device driver and client software to decide what the exact relation is between physical and virtual device.)

Рисунок 5-15. Примера Соединения Источника/Стока

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

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

Следует обратить внимание, что модель не ограничена только устройствами  USB. Дисковод CD-ROM, например, содержащий 44.1 кГц звук может проявляться(appear) или как асинхронный или синхронный или адаптивный источник. Асинхронная операция означает, что CD-ROM заполняет буфер со скоростью, с которой он читает данным с диска, и драйвер освобождает буфер согласно интервалу обслуживания USB. Синхронная операция означает, что драйвер использует интервал обслуживания USB (например, 10 мс) и номинальная скорость выборки данных (44.1 кГц) которая определяет осуществление 441 выборок каждый интервал обслуживания USB. Адаптивная операция была бы встроена в преобразователь скорости выборок, чтобы согласовывать выходную скорость CD-ROM с различными скоростями выборок стока.

При использовании этой эталонной модели, возможно определить что необходимы операции установки соединения между различными источниками и стоками.(Using this reference model, it is possible to define what operations are necessary to establish connections between various sources and sinks.) Кроме того, модель указывает, что одинаковость этих операции должна или может иметь место.( Furthermore, the model indicates at what level these operations must or can take place.) Сначала имеется стадия, где физические устройства отображены(mapped) на виртуальные устройства и наоборот. Она выполнена драйвером и-или клиентским программным обеспечением. В зависимости от возможностей, включенных в это программное обеспечение, физическое устройство может быть преобразовано в виртуальное устройство полностью другого типа синхронизации. Второй стадия - это приложение, которое использует виртуальные устройства. Размещение возможностей согласования скорости на уровне драйвера/клиента стека программного обеспечения освобождает приложение связывающееся с виртуальными устройствами от забот по выполнению согласования скорости для каждого устройства, которое присоединено к ним(??? к такие "к ним "). Если только виртуальные характеристики устройства определены(decided), фактические характеристики устройства интересны не больше чем фактические физические характеристики устройства другого драйвера.



Например, рассмотрим приложение смесителя, которое соединяется на стороне источника с различными источниками, каждый выполняется со своей собственной частотой и часами.  Прежде, чем сможет происходить смешивание, все потоки должны быть преобразованы в общую частоту и привязаны к общим эталонным часам. Это действие может выполняться в физическом отображеном на виртуальный уровене или оно может быть выполнено приложением непосредственно для каждого устройства источника независимо. (This action can be performed in the physical to virtual mapping layer or .) Подобные же действия должны выполниться на стороне стока. Если приложение посылает смешанный поток данных наружу различным устройствам стока, возможно или делать согласование скорости для каждого устройства, непосредственно или положиться на  драйвер/клиенское программное обеспечение, чтобы он сделал это если возможно.

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

Таблица 5-8 Требования к Соединению

	Конечная Точка Истока
Конечная Точка Стока	Асинхронный	Синхронный	Адаптивный
Асинхронный	АÒËÌ??. Исток/Сток RA См. Примечание 1.	АÒËÌ??. SOF/Сток RA См. Примечание 2.	Data + Feedback Feedthrough См. Примечание 3.
Синхронный	Асинхр. Исток/SOF RA См. Примечание 4.	АÒËÌ??. RA См. Примечание 5.	Data Feedthrough + Application Feedback См. Примечание 6.
Адаптивная	Data Feedthrough См. Примечание 7.	Data Feedthrough См. Примечание 8.	Data Feedthrough См. Примечание 9.

Примечания:

1.     Асинхронная RA в приложении. Fsi - определенние источника, используя информацию упреждения, внедренную в поток данных(Fsi is deter­mined by the source, using the feedforward information embedded in the data stream.) Fso - определение стока, основываясь на информации обратной связи от стока. Если номинально Fsi = Fso, процесс вырождается к проходному(feedthrough) соединению, если ошибки/заполнения(slip/stuff) из-за недостатка синхронизации терпимы (If nominally Fsi = Fso, the process degenerates to a feedthrough connection if slips/stuffs due to lack of synchronization are tolerable.) Такие ошибки/заполнения вызовут слышимые искажение воспроизведения в звуковых приложениях.



2.     Асинхронная RA в приложении.  Fsi определение источника но с привязкой к SOF.  Fso

-, определение стока, основываясь на информации обратной связи от стока. Если номинально Fsi = Fso, the process degenerates to a feedthrough connection if slips/stuffs due to lack of synchronization are tolerable.  Such slips/stuffs will cause audible degradation in audio applications.

3.     If Fso

falls within the locking range of the adaptive source, a feedthrough connection can be established.  Fsi = Fso, and both are deter­mined by the asynchronous sink, based on feedback information from the sink.  If Fso

falls outside the locking range of the adaptive source, the adaptive source is switched to synchronous mode and Note 2 applies.

4.     Asynchronous RA in the application. Fsi is deter­mined by the source.  Fso

is determined by the sink and locked to SOF.  If nominally Fsi = Fso, the process degenerates to a feedthrough connection if slips/stuffs due to lack of synchronization are tolerable.  Such slips/stuffs will cause audible degradation in audio applications.

5.     Synchronous RA in the application.  Fsi is deter­mined by the source and locked to SOF.  Fso is determined by the sink and locked to SOF.  If Fsi

= Fso, the process degener­ates to a loss-free feedthrough connection.

6.     The application will provide feedback to synchronize the source to SOF.  Then the adaptive source appears to be a synchronous endpoint and Note 5 applies.

7.     If Fsi

falls within the locking range of the adaptive sink, a feedthrough connection can be established.  

Fsi = Fso and are deter­mined by and locked to the source.

If Fsi falls outside the locking range of the adaptive sink, synchronous RA is done in the host to provide an Fso that is within the locking range of the adaptive sink.

8.     If Fsi

falls within the locking range of the adaptive sink, a feedthrough connection can be established.  

Fso  = Fsi and are deter­mined by the source and locked to SOF.

If Fsi falls outside the locking range of the adaptive sink, synchronous RA is done in the host to provide an Fso that is within the locking range of the adaptive sink.

9.     The application will use feedback control to set Fso of the adaptive source when the connection is set up.  The adaptive source operates as an asynchronous source in the absence of ongoing feedback information and Note 7 applies.

В случаях, где RA необходим, но не доступен, процесс адаптации скорости мог бы подражать пропуску/заполнению выборки (In cases where RA is needed but not available, the rate adaptation process could be mimicked by sample dropping/stuffing.) Тогда соединение могло бы еще осуществлено, возможно с предупреждением о низком качестве; иначе, соединение не может осуществлено(made).

Связываемость Синхронных Данных

Для случая синхронных данных, используется адаптация скорости. Случайные ошибки/заполнения могут быть приемлемы для многих приложений, в которых реализована некоторая форма управления при ошибках. Управление при ошибках включает обнаружение ошибок и отбрасывание, обнаружение ошибок и повторную передачу, или прямое исправление ошибки. Скорость ошибок/заполнений будет зависеть от несоответствия часов источника и стока, и может быть доминирующий источник ошибки канала.(The rate of slips/stuffs will depend on the clock mismatch between the source and sink, and may be the dominant error source of the channel.) Если управления при ошибке достаточно, то соединение может все еще осуществлено.

Таймер Кадра Концентратора

Каждый концентратор имеет таймер кадра, чья синхронизация получен из сгенерированного хостом SOF маркер и прослеживает хост SOF пакет, и в фазе и периоде.(Each hub has a frame timer whose timing is derived from the host-generated SOF token and tracks the host SOF packet in both phase and period.) Таймер кадра сбрасывается, каждый раз когда обнаружен SOF и отвечает за генерацию точки Конца Кадра (EOF). Таймер кадра концентратора должен проследить SOF хоста и быть способным остаться синхронизированным с SOF хоста при потери до двух последовательных SOF маркеров. Все концентраторы должны иметь таймер EOF, который используется для идентификации двух отличных точек во времени: точку (EOF1), в это время концентратор должен завершить собственную связь вверх по иерархии, и точку (EOF2), когда шина должна видеть завершенный вверх по иерархии трафик. Задержка между EOF1 и EOF2 соответствует перекосу времен между хостом и концентратором плюс время требуемое для того, чтобы произошел EOP и это проиллюстрировано на Рисунок 11-9.

Рисунок 11-9.  Отличие EOF на Концентраторе и Хосте

Таймер кадра должен быть синхронизирован со временем кадра хоста в случае самых плохих допусков и смещений между хостом и концентратором. Смещения должны приспособить допуск генератора концентратора и преднамеренно ввести отклонение от 1.000 мс периода кадра, который происходит, когда хост блокируется внешний источник.(The offsets have to accommodate the hub oscillator tolerance and purposely introduced deviations from 1.000 ms frame timing which occur when the host locks to an external source.) Вышеупомянутые параметры требуют минимальной длины кадра (FLmin ) 11,985 и максимальной длины кадра (FLmax) 12,015.

Taxonomy of Application Space Таксономия областей применения

Рисунок 3-1 описывает таксономию для диапазона рабочих нагрузок при передачи данных, который поддерживается USB Шиной. Как видно, шина с трафиком 12 МБ удовлетворяет среднюю, быструю и медленную скорости передачи данных.  Обычно, при средней скорости тип данных изохронный (isochronous) и медленные данные исходят от интерактивных устройств.  Предлагаемая USB Шина - прежде всего настольная (desktop) шина, но может легко применяться в мобильной среде. Архитектура программного обеспечения учитывает будущее расширение USB Шины,  обеспечивая поддержку для различных хост - контроллеров USB Шины.

Рисунок 3-1. Таксономия областей применения

Timing Waveforms

Рисунок 7-29.  Дифференциальная Флуктуация Данных

Рисунок 7-30.  Differential to EOP Transition Skew and EOP Width

Рисунок 7-31.  Допустимая Флуктуация Приемника

Обратитесь к Разделу 7.1.11 для определения TPERIOD

Рисунок 7-32.  Дифференциальная Задержка Концентратора, Дифференциальная Флуктуация, и Искажение SOP

Рисунок 7-33.  Задержка EOP в Концентраторе и Перекос EOP

Глава 8

 

Уровень Протокола

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

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

Таблица 5-7. Характеристики Синхронизации

		Источник		Сток
Асинхронный		Свободное движение Fs(Free running Fs) Обеспечивает неявное упреждение (поток данных)		Свободное движение Fs Обеспечивает явную обратную связь (канал прерывания)
Синхронный		Fs прикреплена к SOF Использует неявную обратную связь (SOF)		Fs прикреплена к SOF Использует неявную обратную связь (SOF)
Адаптивный		Fs прикреплена к стоку Использует явную обратную связь (канал управления)		Fs прикреплена к потоку данных Использует неявное упреждение (поток данных)

Типы Передачи

Данные USB транспортируются по каналу между буфером памяти, связанным с клиентским программным обеспечением на хосте и конечной точкой на устройстве USB. Данные, транспортируемые каналами сообщений имеют структуру определенную USB, но USB позволяет устройству транспортировать специфические структуры данных внутри данных сообщения определенного полезной нагрузкой USB (Data transported by message pipes is carried in a USB defined structure, but USB allows device specific structured data to be transported within the USB defined message data payload.)  USB также определяет что данные, перемещаемые по шине - упакованы в любом канале (поток или сообщение), но в конечном счете форматирование и интерпретация данных, транспортируемых в полезной нагрузке данных транзакции шины - обязанность клиентского программного обеспечения и функции использующей канал. Однако, USB обеспечивает различные типы передачи, которые оптимизированы, чтобы более близко соответствовать требованиям сервиса клиентского программного обеспечения и функции использующей канал. IRP использует один или большее количество транзакций шины, чтобы переместить информацию между клиентским программным обеспечением и функцией.

Каждый тип передачи определяет различные характеристики включения потока связи:

Формат данных, наложенный USB

Направление потока связи

Ограничения на размер пакета

Ограничения на доступ к шине

Требуемая последовательность данных (Required data sequences)

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

USB определяет четыре типа передачи:

Передача Управления - Пакетная, не-периодическая, программное обеспечение хоста инициализирует связь как запрос/ответ, обычно используется для таких операций как команда/состояние (Bursty, non-periodic, host software initiated request/response communication typically used for command/status operations).

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

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

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

Каждый тип передачи описан подробнее в следующих четырех главных разделах. Данные для любого IRP несет поле данных пакета данных как описано в Разделе 8.4.3. Глава 8 также описывает подробности протокола, которые затрагивают использование каждого специфического типа передачи.

Точки Зрения Разработчика

USB обеспечивает сервисы связи между хостом и присоединенными устройствами USB.  Однако, при простом взгляде, конечный пользователь видит присоединения одного или более устройств USB к хосту, как на Рисунке 5-1, что немного больше усложно в реальной реализации, чем это показано на рисунке.( However, the simple view an end user sees of attaching one or more USB devices to a host, as in Figure 5-1, is in fact a little more complicated to implement than as indicated by the figure)  Взгляды на системы с разных сторон требуются, чтобы объяснить специфические требования USB шины для понимания проблем различными разработчиками.( Different views of the system are required to explain specific USB requirements from the perspective of different implementers.) Несколько важных концепций и возможностей должны поддерживаться при обеспечении конечного пользователя требуемой надежной операцией для сегодняшних персональных компьютеров.( Several important concepts and features must be supported to provide the end user with the reliable operation demanded from today’s personal computers)  USB представлена в виде слоев, что облегчает объяснение и позволяет разработчикам отдельных частей изделий USB сосредоточиться на подробностях касающихся их изделий.

Рисунок 5-1. Упрощенный Вид Хоста / Устройства USB

На рисунке 5-2 показан более глубокий краткий обзор определений различных уровней системы USB, который будет описан более подробно далее в спецификации(Figure 5-2 shows a deeper overview of USB identifying the different layers of the system that will be described in more detail in the remainder of the specification.) Особенности распределены по четырем центральным областям реализаций(In particular, there are four focus implementation areas):

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

Клиентское Программное Обеспечение - Программное обеспечение, которое выполняется на соответствующем хосте устройства USB. Это клиентское программное обеспечение обычно предоставляется операционной системой или вместе с устройством USB.

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

USB Хост Контроллер ( Сторона Хоста в Интерфейсе Шины) - аппаратные средства и программное обеспечение, которое позволяет устройствам USB быть присоединенным к хосту.

Имеются часть прав и обязательств между четырьмя компонентами системы USB (There are shared rights and responsibilities between the four USB system components). Далее в этой спецификации описываются подробности, требуемые для поддержания крепких, надежных потоков связи между функцией и ее клиентом.( The remainder of this specification describes the details required to support robust, reliable communication flows between a function and its client.)



Рисунок 5-2. Области Реализации USB

Как показано на Рисунке 5-2, простое соединение хоста с устройством требует взаимодействия между рядом уровней и объектов. Уровень Интерфейса Шины USB обеспечивает физическую/сигнальную/пакетную связь между хостом и устройством. Уровень Устройства USB -это взгляд на программное обеспечение Системы USB которое выполняет внутренние операций шины USB с устройством.(The USB Device Layer is the view the USB System software has for performing generic USB operations with a device.) Функциональный Уровень предоставляет дополнительные возможности хосту через соответственно связанный с ним уровень клиентского программного обеспечения. В пределах  уровня Устройства USB и Функционального уровня, вид связи логический, а чтобы выполнить передачу данных, фактически, используется  Уровень Интерфейса USB Шины, (The USB Device and Function layers each have a view of logical communication within their layer that actually uses the USB Bus Interface Layer to accomplish data transfer.)

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

Чтобы описывать и управлять связью USB, важно рассмотреть следующие концепции :

Топология Шины: В Разделе 5.2 представлены первостепенные(primary) физические и логические компоненты USB и как они взаимодействуют.

Модели Потоков Связи: Разделы 5.3 до 5.8 описывают, как потоки осуществляют связь между хостом и устройствами в USB и определяются четыре типа передач в USB.

Управление Доступом к Шине: Раздел 5.9 описывает, как происходит управление внутри хоста доступом к шины при поддержании широкого диапазона потоков связи к устройствам USB.

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

Топология Шины

USB Шина соединяет устройства USB с хостом USB. На физическом уровне топология USB представляется в виде многоуровневой звезды. В центре каждой звезды находится концентратор(hub).  Каждый сегмент провода - двухточечное соединение между хостом и концентратором или функцией, или концентратором соединенным с другим концентратором или функцией. 

Рисунок 4-1 иллюстрирует топологию USB.

Рисунок 4-1. Топология Шины

Имеются четыре основных части в топологии USB:

Хост и Устройства: Первичные компоненты системы USB.

Физическая Топология: Как соединены элементы USB .

Логическая Топология: роли и обязательства различных элементов USB и как в USB появляется вид хоста и устройства.

Клиентское программное обеспечение взаимодействия функций: Как клиентское программное обеспечение и связанные с ним интерфейсы функции на устройстве USB видят друг друга.( Client software to function relationships:  How client software and its related function interfaces on a USB device view each other)

Транзакции Прерывания

Транзакции прерывания состоят исключительно из IN транзакций, как показано на

Рисунок 8-13. После получения маркера IN, функция может возвратить данные, NAK или STALL. Если конечная точка не имеет никакой новой информации прерывания, для возврата, то есть нет отложенных прерывания, функция возвращает квитирование NAK в течение фазы данных. Остановленная конечная точка прерывания заставляет функцию возвращать квитирование STALL, если она постоянно остановлена и требует вмешательства программного обеспечения хоста. Если прерывание отложено, функция возвращает информацию прерывания, как пакет данных. Хост, в ответ на получение пакета данных выдает или квитирование ACK, если данные были получены без ошибок или не возвращает квитирование, если пакет данных был получен разрушенным.

Рисунок 8-13.  Формат Транзакции Прерывания

Когда конечная точка использует механизм передачи прерывания для получения фактических данных прерывания, то необходимо придерживаться протокола переключения данных.(When an endpoint is using the interrupt transfer mechanism for actual interrupt data, the data toggle protocol must be followed.) Он позволяет функции определить, какие данные были получены хостом и условие события могут быть очищены.(This allows the function to know that the data has been received by the host and the event condition may be cleared.) Такая “гарантируемая” доставка состояний позволяет функции только посылать информацию прерывания, пока она не была получена хостом скорее чем необходимость послать данные прерывания, каждый раз при опросе функции и пока программное обеспечение хоста выявляет условие прерывания.(This “guaranteed" delivery of events allows the function to only send the interrupt information until it has been received by the host rather than having to send the interrupt data every time the function is polled and until host software clears the interrupt condition.) При использовании в режиме переключения, конечная точка прерывания инициализируется к PID DATA0 и ведет себя также как bulk IN транзакция , показанная на Рисунок 8-10.

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

Требования Хост Контроллера

Во всех реализациях, хост контроллеры выполняют те же самые базисные режимы работы USB и присоединенных устройств. Эти базисные режимы работы описаны ниже.

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

Обработка Состояния		Как компонент хоста, хост контроллер сообщает о состояниях и управляет ими.
Последовательно Параллельный /Параллельно Последовательный Преобразователь (Serializer/Deserializer)		Для данных, переданных из хоста, хост контроллер преобразовывает протокол и информацию о данных от местного формата к потоку бит, передаваемого по USB. Для данных,  получаемых хостом, выполняется обратная операция.
Порождение Кадра		Хост контроллер выдает SOF маркеры с периодом 1 мс.
Обработка Данных		Хост контроллер обрабатывает запросы на передачу данных от и к хосту.
Протокол Перемещения		Хост контроллер поддерживает протокол, определенный USB.
Обработка Ошибки в Передачи		Все хост контроллеры ведут себя одинаково при обнаружении и реакции на определенные категории ошибок.

Следующие подразделы представляют более детализированное обсуждение заданных требований хост контроллера.

Требования к Буферу Ввода-Вывода Концентратора

Все порты концентратора должны быть способны обнаружить и генерировать сигналы J, K, и SE0 состояний шины. Это требуется, чтобы порты концентратора были способны независимо управлять и контролировать свои выходы D+ и D-. Каждый порт концентратора должен иметь несимметричные приемники на D+ и D- линиях такие же как у дифференциальнго приемника.(Each hub port must have single ended receivers on the D+ and D- lines as well as a differential receiver.) Подробности относительно уровней напряжения и требований управления появляются в Главе 7. Рисунок 11-8 показывает схемотехнику Ввода-Вывода для типичного порта концентратора.

Рисунок 11-8.  Драйвер и Приемник Порта Концентратора

Таблица 11-2 определяет входные и выходные сигналы разделов концентратора.

Таблица 11-2.  I/O Сигналы Разделов Концентратора

Имя Сигнала		Направление		Описание
D+, D-		I/O		Внешние линии данных USB
RxD		O		Полученные дифференциальные данные
RxD+		O		Received single-ended value on D+ line
RxD-		O		Received single-ended value on D- line
TxD+		I		Переданное значение данных
TxD-		I		Переданное значение данных
OE		I		Разрешение/запрет выхода для буферов вывода

D+ и D- линии I/O, которые соединяются с физической средой USB. Когда они переведены в состояние Hi-Z, они тянутся близко к земле или Vcc шины резисторами на концентраторе и устройстве.(When placed in the Hi-Z state, they are pulled to near the ground or Vcc rails by resistors on the hub and device.) RxD - дифференциальные полученные данные. RxD+ и RxD- полученные несимметричные данные.( RxD is the differential received data.  RxD+ and RxD- are the received single ended data.) TxD+ и TxD- используются, чтобы послать дифференциальные данные и несимметричный сброс и сигналы EOP. OE отключает драйверы вывода.

Требования к Конечной Точке (Endpoint Requirements)

Все USB устройства должны иметь конечную точку с номером 0, которая используется, чтобы инициализировать, и внутренне (generically) управлять логическим устройством (например, конфигурировать логическое устройство). Конечная точка 0 обеспечивает доступ к информации о конфигурации устройства и предоставляет внутреннее состояние USB и доступ к управлению.( Endpoint 0 provides access to the device’s configuration information and allows generic USB status and control access.) Конечная точка 0 поддерживает передачи управления как определено в Разделе 5.5. Конечная точка 0 всегда сконфигурирована, если только устройство присоединено и под питанием.

Требования Механизма Команды USBD

USBD механизмы команды позволяют клиенту внутренний доступ к  устройству USB. Вообще эти команды позволяют клиенту осуществить чтение или запись к одному из потенциально несколькими устройств, данных и управления.(Generally these commands allow the client to make read or write accesses to one of potentially several device data and control spaces.) Клиент предоставляет так же немного как идентификатор устройства и соответствующие данные или указатель на пустой буфер.(The client provides as little as a device identifier and the relevant data or empty buffer pointer.)

Передачи команды USBD не требуют, чтобы устройство USB было сконфигурировано. Многие из средств конфигурации устройства, предоставляемых USBD - это передачи команды.(Many of the device configuration facilities provided by the USBD are command transfers.)

Следующее специфические требования к предоставляемым механизмам команды.(Following are the specific requirements on the command mechanisms provided.)

Требования не нулевой конечной точке

Функции могут иметь дополнительные конечные точки которые требуется для их реализации.  Низко скоростные функции ограничены двумя необязательными конечными точками кроме требуемой Конечной Точки 0. Полно скоростные устройства могут иметь дополнительные конечные точки,  ограниченные только определением протокола; то есть, максимум 16 входных конечных точек и 16 конечных точек вывода.

Конечная точка не может использоваться, пока она не сконфигурирована. Конечные точки, помимо Конечной точки 0, конфигурируются как часть нормального процесса конфигурации устройства (обратитесь к Главе 9).

Требования перекоса

Хост и концентраторы, пока все синхронизируются к SOF хоста, подчиненны некоторым перекосам, которые диктуют отрезок времени между точками EOF, поведение хоста возле EOF, и следующий SOF. Рисунок 11-11 иллюстрирует критические временные точки конца кадра.

Рисунок 11-11.  Временные точки EOF

Требования по Распределению Питания Концентратора

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

Концентраторы могут быть или локально запитаны или питаться от шины, или комбинировать и то и другое. Например, концентратор может получать мощность для SIE и корневого порт присоединенных к питанию резисторов от шины при получении мощности для downstream портов от локального источника. Концентратор может только обеспечивать мощность в направлении вниз по иерархии, и никогда не должен управлять мощностью вверх по иерархии. Полное обсуждение распределения питания концентратора находится в Разделе 7.2.

Питающиеся от шины концентраторы должны иметь переключение мощности порта для downstream портов и требуется выключить мощность на всех downstream портах, когда концентратор выходит из включения питания(power-up), или когда он получает сброс по корневому порту. Порты могут также быть запитаны и выключены под управлением программного обеспечения хоста. Реализация может предоставлять переключение мощности на основании работоспособности порта или иметь один переключатель для всех портов. Запросы сброса порта, не воздействуют на состояние переключения мощности порта. Порт концентратора должен быть запитан, чтобы выполнить обнаружение соединения от направления вниз по иерархии.

Удаление Устройств

USBDI должен предоставить средство драйверу концентратора, для сообщения USBD, что определенное устройство было удалено.

Удаление Устройства

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

Удаление Устройства USB

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

Если удаленное устройство USB - концентратор, процесс удаления должен выполниться для всех устройств USB, которые были предварительно присоединены к концентратору.

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

Удаленное Пробуждение

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

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

Управление Конфигурацией

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

Каждый концентратор инициализирует передачу прерывания, когда изменяется состояние одного из портов концентратора. Вообще, изменение состояния порта будет вызывать соединение или удаление вниз по иерархии устройства USB.(Generally, the port state change will be the connection or removal of a downstream USB device. ) (Обратитесь к Главе 11 для подробной информации.)

Управление Мощностью в Течение Подвешенного/Возобновленного состояниях

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

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

При пробуждении устройств, или самостоятельное (удаленное пробуждение) или видя возобновленную передачу сигналов, они должны ограничить ток наплыва на Vbus.  Выходное максимальное снижение на концентраторе Vbus 330 мВ или приблизительно 10% от номинального колебания сигнала от функции. Устройство должно иметь достаточную емкость шунтирования корпуса(on-board bypass capacitance) или управляемую последовательность включения такой, что ток, потребляемый из концентратора не превышает максимально возможный ток порта в любое время, в то время как устройство пробуждается.

Управление Передачей

Управление Передачей включает несколько сущностей, которые функционируют на различных объектах, чтобы переместить транзакции по шине:

Клиентское Программное обеспечение(Client Software ) - Функция Потребления / Генерации специфических данных на/из конечной точки функции через обращения и повторения вызовов, запрашивающая IRPs с интерфейсом USBD.

Драйвер USB(USBD) - Преобразовывает данные в клиентских IRPs на/из конечной точки устройства через обращения / повторные вызовы с соответствующим HCD. Один клиентский IRP может включать одну или более передач.

Драйвер Хост Контроллера (HCD) - Преобразовывает IRPs на/из транзакций (как требует реализация хост контроллера) и организовывает их для манипулирования хост контроллером. Взаимодействия между драйвером хост контроллера и аппаратными средствами зависят от реализации и областей лежащих вне(outside the scope of)  спецификации USB.

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

Рисунок 5-10 показывает, как организованы сущности в виде информационных потоков между клиентским программным обеспечением и USB. Объекты первичного интереса каждой сущности показаны в интерфейсах между сущностями.( The objects of primary interest to each entity are shown at the interfaces between entities.)

Рисунок 5-10. USB Преобразование Информации От Клиентского Программного Обеспечения до Шины

Управление питанием

Хост USB имеет систему управления питанием, которая не зависит от USB шины. Программное обеспечение системы USB взаимодействует с системой управления питанием хоста, чтобы обработать события связанные с мощностью в системе типа, Подвешивание(SUSPEND) или Возобновление(RESUME). Дополнительно, устройства USB могут нести определенную USB шиной информацию управления питанием, которая позволяет им управлять мощностью с помощью программного обеспечения системы или внутренних(generic) драйверов устройств. 

Разводка питания и возможности управления питанием USB позволяют  разрабатывать чувствительные к мощности системы типа батареи для ноутбуков(notebook). 

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

USB система будет обеспечивать управление питанием способом определенным системой.  Никакие другие требования USB кроме описанных в Главе 9, не выдвигаются системой USB.

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

Все устройства USB  должны однако поддерживать Выключенное(Powered Down) состояние (обратитесь к Главе 9). Базисное управление питанием, предоставляемое на устройство осуществляется через управление портом концентратора, к которому присоединено устройство.

Управление Ресурсами

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

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

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

Число передаваемых байт данных (MaxPacketSize).

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

Глубина топологии. Если допускается меньшая точность, может быть принята максимальная глубина топологии.(If less precision is allowed, the maximum topology depth may be assumed.)

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

---

---