Поле Данных
Поле данных может быть длиной от 0 до 1023 байт и должно содержать целое число байт. На Рисунке 8-4 показан формат поля данных для нескольких байт. Биты данных внутри каждого байта располагаются так что LSB - первый.
Рисунок 8-4. Формат Поля Данных
Размер пакета данных изменяется в соответствии с типом передачи как описано в Главе 5.
Поле Идентификатора Пакета
Идентификатор пакета (PID) следует непосредственно за SYNC полем каждого пакета USB. PID состоит из четырех битного поля типа пакета, за которым следует четырех битное поле проверки, как показано на Рисунок 8-1. PID определяет тип пакета и формат пакета и типа обнаружения ошибок, применяемые к пакету. Четырех битовое поле проверки в PID обеспечивает надежное декодирование PID таким образом, что остаток пакета интерпретируется правильно. Поле проверки PID генерируется, выполняя дополнение к полю типа пакета.
Рисунок 8-1. Формат PID
Хост и все функции должны выполнить полное декодирование всех полученных полей PID. Любой PID, полученный с ошибочным полем проверки или который декодируется к неопределенному значению, считается поврежденным и игнорируется также, как и остаток пакета, игнорируется приемником пакета. Если функция получает другой допустимый PID для типа транзакции или направления, которое она не поддерживает, то функция не должна отвечать. Например, конечная точка рассчитанная только на IN должна игнорировать маркер OUT. Типы PID, кодирование и описание приведены в Таблица 8-1.
Таблица 8-1. Типы PID
| Тип PID | Имя PID | PID[3:0] | Описание
| ||||
| Маркер | OUT
IN SOF SETUP | b0001
b1001 b0101 b1101 | Адрес + номер конечной точки на хосте - > транзакция функции Адрес + номер конечной точки на функции - > транзакция хоста Маркер начало кадра и номер кадра Адрес + номер конечной точки на хосте - > транзакция функции для установки в конечную точку управления | ||||
| Данные | DATA0
DATA1 | b0011
b1011 | Четный пакет данных PID
Нечетный пакет данных PID | ||||
| Квитирование | ACK
NAK STALL | b0010
b1010 b1110 | Приемник принимает пакет данных свободный от ошибок
Rx устройство не может принимать данные, или Tx устройство не может посылать данные Конечная точка остановлена | ||||
| Специальный | PRE | b1100 | Выданная хостом преамбула. Разблокировывает трафик вниз по иерархии шины к низко скоростным устройствам.(Host-issued preamble. Enables downstream bus traffic to low speed devices.) |
PIDS разделены на четыре кодовые группы : маркер, данные, квитирование, и специальные, определяемые двумя первыми передаваемыми битами PID (PID < 1:0 >). Это объясняет распределение кодов PID.
Поле Конечной Точки
Дополнительное четырех битовое поле конечной точки (ENDP), показанное на Рисунке 8-3, обеспечивает более гибкую адресацию функций, в которых требуется более одного подканала. Номера конечных точек зависят от функции. Поле конечной точки определено только для PIDов маркеров IN, SETUP, OUT. Все функции должны поддерживать одну управляющую нулевую конечную точку. Низко скоростные устройства поддерживают максимум два адреса конечной точки для каждой функции: нулевой и одной дополнительной конечной точки. Полно скоростные функции могут поддерживать максимум до 16 конечных точек.
Рисунок 8-3. Поле Конечной точки
Поле Номера Кадра
Поле номера кадра представляет собой 11-битное поле, которое инкрементируется хостом в каждом кадре(The frame number field is an 11-bit field that is incremented by the host on a per frame basis.) Поле номера кадра отсчитывается заново с нуля после достижения максимального значения x7FF, и посылается только для SOF маркеров в начале каждого кадра.
Поле SYNC
Все пакеты начинаются с поля синхронизации (SYNC), которое является кодированной последовательностью, которая генерирует максимальную плотность границ передач. Поле SYNC появляется в шине как IDLE, за которым следует двоичная строка “KJKJKJKK”, в NRZI кодировке. Оно используется входной схемой для выравнивания входных данных с локальными часами и определено, как последовательность из восьми бит. SYNC используется только как механизм синхронизации и не показано на приведенных ниже диаграммах пакета (обратитесь к Разделу 7.1.7). Последние два бита в поле SYNC - это маркер, который используется, для идентификации первого бит PID. Все последующие биты в пакете должны отсчитываться от этой точки.
Поля адреса
Конечные точки функции адресуются с помощью двух полей: поле адреса функции и поле конечной точки. Функция должна полностью декодировать, как поле конечной точки так и поле адреса. Совпадение адресов или имен конечных точек не разрешается, и в случае несоответствия полей, маркер должен быть проигнорирован. Обращение к неинициализированным конечным точкам, также вызовет игнорирование маркера.
Получение Дескриптора
Этот запрос возвращает определенный дескриптор, если дескриптор существует.
| bmRequestType | bRequest | wValue | wIndex | wLength | Данные | ||||||||
| 10000000B | GET_DESCRIPTOR | Тип Дескриптора и Индекс Дескриптора | Нуль или Языковой ID (обратитесь к Разделу 9.6.5) | Длина Дескриптора | Дескриптор | ||||||||
Поле wValue определяет, что тип дескриптора находится в старшем байте и индекс дескриптора в младшем байте (обратитесь к Таблице 9-4). Поле wIndex
определяет Языковой ID для дескрипторов строк или сброшен в нуль для других дескрипторов. Поле wLength определяет число возвращаемых байтов. Если дескриптор больше чем поле wLength, возвращаются только начальные байты дескриптора. Если дескриптор короче чем wLength поле, устройство указывает конец передачи управления, посылая короткий пакет, когда дальнейшие данные запрошены. Короткий пакет определен как пакет который короче чем максимальный размер полезной нагрузки или пакет данных NULL (обратитесь к Главе 5 ).
Стандартный запрос к устройству поддерживает три типа дескрипторов: Device, Configuration, и String. Запрос о конфигурации дескриптора возвращает в одном запросе дескриптор конфигурации, все дескрипторы интерфейса, и дескрипторы конечной точки для всех интерфейсов. Первый дескриптор интерфейса немедленно следует за дескриптором конфигурации. Дескрипторы конечной точки для первого интерфейса следуют за первым дескриптором интерфейса. Если имеются дополнительные интерфейсы, их дескриптор интерфейса, и дескрипторы конечной точки следуют за дескрипторами конечной точки первого интерфейса.
Во всех устройствах должен быть предусмотрен дескриптор устройства и по крайней мере один дескриптор конфигурации. Если устройство не поддерживает запрошенный дескриптор, оно отвечает, останавливая канал, используемый для запроса. Ненулевое значение первого байта дескриптора указывает, что буфер содержит допустимый дескриптор.
Получение Дескриптора Концентратора
Этот запрос возвращает дескриптор концентратора.
| bmRequestType | bRequest | wValue | wIndex | wLength | Data | ||||||
| 10100000B | get_descriptor | Тип и Индекс Дескриптора | Нуль | Длина Дескриптора | Дескриптор |
Запрос GetDescriptor к дескриптору класса концентратора, придерживается той же самой модели эксплуатации что и стандартный запрос GetDescriptor (обратитесь к Главе 9). Стандартный дескриптор концентратора обозначается нулевым типом дескриптора. Требуется чтобы во всех концентраторах был реализован один дескриптор концентратора, с нулевым индексом дескриптора.
Получение Дескрипторов
USBDI должен предоставить механизмы, для восстановления: стандартного устройства, конфигурации и строковых дескрипторов, также как любые определенные классом или продавцом дескрипторы.
Получение Интерфейса
Этот запрос возвращает выбранную альтернативную установку для определенного интерфейса.
| BmRequestType | bRequest | wValue | wIndex | wLength | Данные | ||||||
| 10000001B | GET_INTERFACE | Нуль | Интерфейс | Один | Альтернативная Установка |
Некоторые устройства USB имеют конфигурации интерфейсов, которые имеют взаимо исключающие установки. Этот запрос позволяет хосту определять выбранную в настоящее время альтернативную установку.
Получение Конфигурации
Этот запрос возвращает текущую конфигурацию устройства.
| bmRequestType | bRequest | wValue | wIndex | wLength | Данные | ||||||
| 10000000B | GET_CONFIGURATION | Нуль | Нуль | Один | Значение Конфигурации |
Если возвращенное значение нуль, устройство не сконфигурировано.
Получение Состояния Концентратора
Этот запрос возвращает текущее состояние концентратора и состояния, которые изменялись начиная с предыдущего подтверждения.
| bmRequestType | bRequest | wValue | wIndex | wLength | Данные | ||||||
| 10100000B | get_ status | Нуль | Нуль | Четыре | Индикаторы Состояния Концентратора и Изменений |
Первое слово данных содержит wHubStatus (обратитесь к Таблица 11-14). Второе слово данных содержит wHubChange (обратитесь к Таблица 11-15).
Возвращаемые поля организованы так, чтобы позволить системному программному обеспечению определять, какое из состояний изменилось. Расположение бит в wHubStatus и wHubChange полях взаимно-однозначном соответствуют друг другу, где это возможно.
Локальная мощность и изменения сверхтока подтверждаются, используя запрос ClearHubFeature.
Таблица 11-14. Поле Состояния Концентратора, wHubStatus
| БИТ | ОПИСАНИЕ | ||
| 0 | Состояние Локального Питания: В этом состоянии питание подается локально.
Это поле применяется только в концентраторах с независимым питанием , чей Модуль Управления Интерфейсом USB (SIE) является питающимся от шины или в концентраторах, которые поддерживают конфигурации или независимого питания или питания от шины. Это поле возвращается как результат изменения источника питания концентратора. Это поле сообщает, является ли локальная мощность удовлетворительной. Это поле позволяет системному программному обеспечению определять причину для удаления мощности от устройств, присоединенных к этому концентратору или реагировать на изменение состояния локального питания. Если концентратор не поддерживает эту возможность, это поле ЗАРЕЗЕРВИРОВАНО и следующие ниже за определением биты ЗАРЕЗЕРВИРОВАНЫ. Это поле сообщает состояние питания SIE и остатка от концентратора.(This field reports the power status for the SIE and the remainder of the hub.) 0 = Локальное питание в норме 1 = Локальное питание потеряно (неактивно) | ||
| 1 | Индикатор Сверхтока: Это поле только применяется в концентраторах, которые сообщают условия сверхтока в глобальном базисе концентратора (global hub basis)(сообщается в Дескрипторе Концентратора ).
Если концентратор не сообщает о сверхтоке в глобальном базисе концентратора, это поле ЗАРЕЗЕРВИРОВАНО и следующие ниже за определением биты ЗАРЕЗЕРВИРОВАННЫ.(If the hub does not report over-current on a global hub basis, )
Это поле указывает, что сумма токов всех портов превысила определенный максимум, и мощность от всех портов была отключена. Для более детального ознакомления с Защитой от сверхтоков, обратитесь к Разделу 7.2.1.2.1. Это поле указывает возникновение условия сверхтока по сумме токов потребляемых всеми портами. 0 = Все операции с мощностью в норме 1 = Условие сверхтока существует на широком базисе концентратора(hub-wide basis) | ||
| 2-15 | Зарезервированы
Эти биты при чтении возвращают 0. |
Таблица 11-15. Поле Изменения Концентратора, wHubChange
|
ÁÈÒ |
ÎÏÈÑÀÍÈÅ |
|
0 |
Изменение Состояния Локального Питания: (c_hub_local_power) Он соответствует Бит 0 Локального Состояния Питания, описанного выше. Это поле только применяет в локально питающихся (то есть, с независимым питанием) концентраторах, чьи Модуль Управления Интерфейсом USB (SIE) является питающейся от шины, или в концентраторах, которые поддерживают конфигурации или с независимым питанием или питающиеся от шины. Это поле возвращается как результат изменения источника питания концентратора. Если концентратор не поддерживает эту возможность, то это поле ЗАРЕЗЕРВИРОВАНО и следующие ниже за определением биты ЗАРЕЗЕРВИРОВАНЫ. Это поле сообщает, произошло ли изменение в состоянием локального питания. 0 = Не произошло никакого изменения в Состоянии Локального Питания 1 =Состояние Локального Питания изменилось |
|
1 |
Изменение Индикатора Сверхтока: (c_hub_over_current) Оно соответствует Биту 1 Индикатора Сверхтока, описанному выше. Это поле применяется только в концентраторах, которые сообщают об условии сверхтока в глобальном базисе концентратора(global hub basis) (сообщается в Дескрипторе Концентратора). Если концентратор не сообщает о сверхтоке к глобальном базисе концентратора, это поле ЗАРЕЗЕРВИРОВАНО и следующие ниже за определением биты ЗАРЕЗЕРВИРОВАНЫ. Это поле сообщает, произошло ли изменение в Индикаторе Сверхтока. Это поле установлено только, если произошло условие сверхтока (то есть, подтверждение этого изменения системным программным обеспечением не вызовет сообщение о другом изменении). 0 = Не произошло никакого изменение в Индикаторе Сверхтока 1 = Индикатор Сверхтока изменился (то есть, произошло условие сверхтока). |
|
2-15 |
Зарезервированы Эти биты при чтении возвращают 0. |
Получение Состояния Порта
Этот запрос возвращает текущее состояние порта и состояния, которые изменились начиная с предыдущего подтверждения.
| BmRequestType | bRequest | wValue | wIndex | wLength | Данные | ||||||
| 10100011B | get_status | Нуль | Порт | Четыре | Индикаторы Состояния Порта и Изменений |
Номер порта должен быть допустимым номером порта для этого концентратора, большим чем нуль.
Первое слово данных содержит wPortStatus (обратитесь к Таблица 11-16). Второе слово данных содержит wPortChange (обратитесь к Таблица 11-17).
Возвращенные поля организованы таким образом что позволяют системному программному обеспечению определить, какие состояния изменилась. Расположение бит в wPortStatus и wPortChange полях взаимно-однозначном соответствуют где это приемлемо.
Таблица 11-16. Поле Состояния Порта, wPortStatus
| БИТ | ОПИСАНИЕ | ||
| 0 | Текущее Состояние Соединение: (port_connection) Это поле отражает, соединено или нет в настоящее время устройство с этим портом. Это значение отражает текущее состояние порта, и не может соответствовать непосредственно событию, которое вызвало установку в единицу Изменение Состояния Вставки (Бит 0 описанный ниже).
0 = Никакое устройство не присоединено к этому порту 1 = Устройство присутствует на этом порте ПРИМЕЧАНИЕ: Это поле всегда =1 для портов, которые имеют не-сменные присоединенные устройства. | ||
| 1 | Порт Enabled/Disabled: (port_enable) Порты могут быть разблокированы только программным обеспечением хоста. Порты могут быть заблокированы или условием неисправности (событие разъединения или другое условие неисправности, включая индикацию сверхтока) или программным обеспечением хоста.
0 = Порт заблокирован 1 = Порт неблокированный | ||
| 2 | Suspend: (port_suspend) Это поле указывает, подвешено или нет устройство на этом порте. Установка этого поля заставляет устройство подвешиваться, не распространением трафика шины вниз по иерархии. Сброс этого поля заставляет устройство возобновлять работу. Трафик шины не может быть возобновлен в середине транзакции шины. Если устройство само передает сигнал возобновления, это поле будет очищено концентратором.
0 = Не подвешено 1 = Подвешено | ||
| 3 | Индикатор Сверхтока: (port_over_current) Это поле применяется только в концентраторах, которые сообщают об условии сверхтока на базиса работающих портов (сообщается в Дескрипторе Концентратора).
Если концентратор не сообщает о сверхтоке на базиса работающих портов концентратора, это поле зарезервировано и следующие за определением ниже биты ЗАРЕЗЕРВИРОВАНЫ.
Это поле указывает, что устройство, присоединенное к этому порту затребовало ток, значение которого превышает определенный максимум, и мощность от этого порта была отключена. Отключение мощности порта также отражено в поле Мощности Порта описанного выше. Для больших подробностей, обратитесь к Разделу 7.2.1.2.1. Это поле указывает, что создается условие сверхтока на присоединенном к этому порту устройстве. 0 = Все операции мощности для этого порта в норме. 1 =На этом порте существует условие сверхтока. Мощность была отключена от этого порта. | ||
| 4 | Сброс: (port_reset) Это поле установлено, когда хост хочет сбросить присоединенное устройство. Оно остается установленным, пока сигнал сброса будет снят концентратором, и не будет установлено поле изменения состояния сброса.
0 = Сигнал сброса, не утвержден 1 = Сигнал сброса утвержден | ||
| 5-7 | Зарезервированы
Эти биты при чтении возвращают 0. | ||
| 8 | Мощность Порта: (port_power) Это поле отражает состояние мощности порта. Так как концентраторы могут выполнять различные методы переключения мощности порта, значение этого поля изменяется в зависимости от используемого типа переключения мощности. Дескриптор устройства сообщает тип переключения мощности, реализованный в концентраторе. Концентраторы не выдают мощности на свои порты, пока они не находятся в конфигурированном состоянии.
0 = На этот порт питание не подано 1 = На этот порт питание подано Примечание: Концентраторы, которые не поддерживают переключение мощности, всегда, возвращают в этом поле единицу. | ||
| 9 | Присоединено Низко скоростное Устройство: (port_low_speed) Это поле важно только, если устройство присоединено.
0 = Полно скоростное устройство, присоединено к этому порту 1 = Низко скоростное устройство, присоединено к этому порту | ||
| 10-15 | Зарезервированы
Эти биты при чтении возвращают 0. |
Таблица 11-17. Поле Изменения Порта, wPortChange
|
БИТ |
ОПИСАНИЕ |
|
0 |
Изменение Состояния Соединения: (c_port_connection) Указывает, что произошло изменение в Текущем Состоянии Соединения порта. Устройство концентратора устанавливает это поле при любых изменениях состояния соединения порта устройства, даже если системное программное обеспечение не очистило изменение состояния соединения.[1] 0 = Не произошло никакого изменения в Текущем Состоянии Соединения 1 = Текущее Состояние Соединения изменилось Примечание: Для портов, которые имеют, не-сменные присоединенные устройства, это поле устанавливается только после условия СБРОСА указывающего системному программному обеспечению, что устройство присутствует на этом порте. |
|
1 |
Изменение Порта Enable/Disable: (c_port_enable) Это поле активизируется только, когда было обнаружено изменение неблокированое/заблокированое состояние порта как аппаратное изменение. Это поле не устанавливается, если системное программное обеспечение вызвало изменение порта неблокированное/заблокированное . 0 = Не произошло никакого изменения в состоянии Порта Неблокированное/Заблокированное 1 = Произошло изменения в состоянии Порта Неблокированное/Заблокированное |
|
2 |
Изменение Suspend: (c_port_suspend) Это поле указывает изменение в видимом хостом состоянии мощности присоединенного устройства. Оно указывает, что устройство вышло из подвешенного состояния. Вход в подвешенное состояние не будет устанавливать это поле. Поле Изменение Suspend устанавливается только, когда весь процесс возобновления завершен. То есть концентратор прекратил сигнал возобновления на этом порте, и 3 мс подождать(have passed), чтобы позволить устройству засинхронизироваться с SOF. 0 = Нет изменений 1 = Возобновление завершено |
|
3 |
Изменение Индикатора Сверхтока: (c_port_over_current) Это поле применяется только в концентраторах, которые сообщают об условии сверхтока на базисе работающих портов " (сообщается в Дескрипторе Концентратора). Если концентратор не сообщает о сверхтоке на базисе работающих портов концентратора, то это поле зарезервировано и следующие ниже за определением биты ЗАРЕЗЕРВИРОВАНЫ. Это поле сообщает, произошло ли изменение Индикатора Сверхтока порта. 0 = Не произошло никаких изменений Индикатора Сверхтока 1 = Индикатор Сверхтока изменился |
|
4 |
Изменение Сброса: (c_port_reset) Это поле установлено, когда завершается обработка сброса на этом порте. Как сброс обработка завершения сброса, также устанавливает неблокированное состояние порта и сбрасывает поле изменения suspend.( As a reset of completing reset processing, the enabled status of the port is also set and the suspend change field reset.) 0 = Нет изменения 1 = Сброс Завершен |
|
5-15 |
Зарезервированы Эти биты при чтении возвращают 0. |
Получение Состояния Шины
Это необязательный диагностический запрос к порту который читает значение состояния шины, в последнем EOF2.
| BmRequestType | bRequest | wValue | wIndex | wLength | Данные | ||||||
| 10100011B | get_ state | Нуль | Порт | Один | Состояние Порта Шины |
Номер порта должен быть допустимым номером порта для этого концентратора, больший чем нуль.
Концентраторы могут реализовывать необязательное диагностическое средство, которое облегчит отладку системы. Концентраторы реализовывают это средство через этот необязательный запрос. Эта диагностическая возможность обеспечивается представлением состояния шины USB, которое выбирается в последней отметке выборки EOF2.
Концентраторы, которые выполняют эту диагностическую возможность, должны сохранить состояние шины в каждом состоянии EOF2, при подготовке к потенциальному запросу в следующем кадре USB.
Данные возвращаются по битно следующим способом. Значение сигнала D- возвращается в поле в бите 0. Значение сигнала D+ возвращается в поле в бите 1.(The value of the D- signal is returned in the field in bit 0. The value of the D+ signal is returned in the field in bit 1.) Биты 2-7 зарезервированы для будущего использования и сброшены в нуль.
Концентраторы, которые не поддерживают этот запрос, отвечают stall.
Получение Текущих Установок Конфигурации
USBDI должен предоставить средство возврата дескриптора текущей конфигурации, для любого определенного устройства.(The USBDI must provide a facility to return, for any specified device, the current configuration descriptor.) Если устройство не конфигурировано, дескриптор конфигурации не возвращается. Это действие эквивалентно возврату дескриптора конфигурации для текущей конфигурации, при запросе специфического дескриптора конфигурации. Однако, не требуется, чтобы клиент знал идентификатор текущей конфигурации. При этом будет возвращена вся информация о конфигурации, включая:
Вся информация о дескрипторе конфигурации, которая хранится в устройстве, включая все альтернативные установки для всех интерфейсов
Индикаторы(Indicators), альтернативных установок для активных интерфейсов
Обрабатываемый канал для конечных точек при активных альтернативных установках для интерфейсов
Фактический MaxPacketSizes для конечных точек при активных альтернативных установках для интерфейсов
Дополнительно, для любого определенного канала, USBDI должен предоставить средство возврата MaxPacketSize, который в настоящее время используется каналом.
Получить Состояние
Этот запрос возвращает состояние для определенного получателя(This request returns status for the specified recipient.)
| bmRequestType | bRequest | wValue | wIndex | wLength | Данные | ||||||
| 10000000B 10000001B 10000010B | GET_STATUS | Нуль | Нуль Интерфейс Конечная точка | Два | Состояние Устройства, Интерфейса или Конечной точки |
Биты Получателя поля bRequestType определяют требуемого получателя. Возвращаемые данные - это текущее состояние определенного получателем.( The data returned is the current status of the specified recipient.)
Запрос GetStatus к устройству возвращает следующую информацию в порядке младшими разрядами назад: (A GetStatus request to a device returns the following information in little-endian order)
| D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 | ||||||||
| Зарезервировано (Сброшены в нуль) | Удаленное Пробуждение | Независимое Питание | |||||||||||||
| D15 | D14 | D13 | D12 | D11 | D10 | D9 | D8 | ||||||||
| Зарезервировано (Сброшены в нуль) |
Поле Независимое Питание указывает, является ли устройство в настоящее время питающимся от шины или с независимым питанием. Если D0 сброшен в нуль, устройство питается от шины. Если D0 установлен в единицу, устройство независимо питающееся. Поле Независимое Питание не может быть изменено Запросами ClearFeature или SetFeature.
Поле Удаленное Пробуждение указывает, возможно ли в настоящее время запросить удаленное пробуждение устройства. Заданный по умолчанию режим для устройств, которые поддерживают удаленное пробуждение - это заблокированный. Если D1 сброшен в нуль, способность устройства сообщить об удаленном пробуждении заблокирована. Если D1 установлен в единицу, способность устройства сообщить о удаленном пробуждении разблокирована. Поле Удаленное Пробуждение может изменяться SetFeature, и ClearFeature запрашивает использование выбор возможностей device_remote_wakeup. Это поле сброшено в нуль, когда устройство сброшено.
Запрос GetStatus к интерфейсу возвращает следующую информацию в порядке младшими разрядами вперед:
|
D7 |
D6 |
D5 |
D4 |
D3 |
D2 |
D1 |
D0 |
|
Зарезервировано (Сброшены в нуль) |
|||||||
|
D15 |
D14 |
D13 |
D12 |
D11 |
D10 |
D9 |
D8 |
|
Зарезервировано (Сброшены в нуль) |
|
D7 |
D6 |
D5 |
D4 |
D3 |
D2 |
D1 |
D0 |
||||
|
Направление |
Зарезервировано (Сброшены в нуль) |
Номер Конечной точки |
|||||||||
Запрос GetStatus к конечной точке возвращает следующую информацию:
|
D7 |
D6 |
D5 |
D4 |
D3 |
D2 |
D1 |
D0 |
|
Зарезервировано (Сброшены в нуль) |
Останов |
||||||
|
D15 |
D14 |
D13 |
D12 |
D11 |
D10 |
D9 |
D8 |
|
Зарезервировано (Сброшены в нуль) |
Помехоустойчивость
Имеются несколько атрибутов USB, которые способствуют помехоустойчивости:
Целостность сигнала, использующая дифференциальные драйверы(differential drivers), приемники, и экранирование
Защита с помощью ЦКЧ(CRC) полей управления и данных
Обнаружение присоединения и отсоединения и конфигурации ресурсов уровня системы
Самовосстановление в протоколе, использующее блокировки времени для потерянных или разбитых(broken) пакетов
Управление потоком передаваемых данных, для гарантирования управления изохронной и аппаратной буферизацией данных
Каналы данных и управления создаются для обеспечения независимости от вредного взаимодействия между функциями
Порядок Следования Бит
Биты посылаются в шину: LSB - первый, за ним следующий за LSB, и т.д. до заканчивающего MSB. В следующих диаграммах пакеты отображаются как отдельные биты и как поля (в порядке чтения слева направо) - так как они бы передавались по шине.( In the following diagrams, packets are displayed such that both individual bits and fields are represented (in a left to right reading order) as they would move across the bus.)
Порождение Кадра
Это ответственность хост контроллера, который выделяет промежутки времени USB в размере 1 мс называемые “кадрами”. Кадры создаются хост контроллером с помощи выдачи маркера Начала Кадра (SOF) в интервалах 1.00 мс как показано на Рисунке 10-3. Маркер SOF - первая передача в периоде кадра. После выдачи маркера SOF, хост контроллер может передавать другие транзакции в остатке от периода кадра. Когда хост контроллер находится в обычном рабочем состоянии, маркеры SOF должны непрерывно генерироваться со скоростью периода в 1 мс, независимо от других действий шины или их отсутствия. Если хост контроллер вводит состояние, когда нет мощности на шине, тогда не нужно генерировать SOFs. Также, если хост контроллер не генерирует SOFs, тогда можно входить в состояние с уменьшенной мощностью.
Рисунок 10-3. Создание Кадра
Маркер SOF имеет самый высокий приоритет доступа к шине. Схемотехника babble в концентраторах электрически изолирует любые активные передатчики в течение Конца Кадра (EOF) интервал, обеспечивая неактивность шины для передачи SOF.
Хост контроллер должен позволить корректировать длину кадра USB на ±1 время передачи бита (обратитесь к Разделу 10.5.3.2.2). Хост контроллер поддерживает текущий номер кадра, который может быть прочитан системой USB. Текущий номер кадра используется, чтобы уникально отличить один кадр от другого.
Увеличение происходит в конце каждого периода кадра.
Допустимый через последующий кадр.(Valid through the subsequent frame.)
Хост передает в последних 11-битах текущий номер кадра в каждой передаче маркера SOF. Когда запрошен из хост контроллера, текущий номер кадра - номер кадра, уже существующий во время запроса, был выполнен.(When requested from the host controller, the current frame number is the frame number in existence at the time the request was fulfilled.) Текущий номер кадра возвращенный хостом (хост контроллером или HCD) - составляет по крайней мере 32 бита, хотя хост контроллер непосредственно не требует поддержание больше чем 11 битов.(The current frame number as returned by the host (host controller or HCD) is at least 32 bits, although the host controller itself is not required to maintain more than 11 bits.)
Хост контроллер должен прекратить передачу в течение EOF интервала. Когда начинается интервал EOF, любые транзакции, планируемые специально для кадра, который только что передан, удаляются. Если выполняющий транзакцию хост контроллер сталкивается с интервалом EOF, хост контроллер завершает транзакцию.
Последовательно Параллельный /Параллельно Последовательный Преобразователь (Serializer/Deserializer)
Фактическая передача данных на физическом уровне USB происходит как последовательный поток бит. Последовательный Перемещающий Интерфейс (SIE), выполненный как часть хоста или устройства USB, осуществляет преобразование в последовательную форму и обратно при передаче по USB. На хосте, SIE - это часть хост контроллера.
Последовательности Данных
Передачи Управления требуют, чтобы транзакция установка шины была послана с хоста на устройство, для описания типа доступа управления, который устройство должно выполнить. Транзакция установка сопровождается нулем или более транзакцией управляющих данных, которые несут специфическую информацию для запрошенного доступа. В заключение, транзакция состояния завершает передачу управления , и позволяет конечной точке возвращать состояние передачи управления клиентскому программному обеспечению. После того, как завершается транзакция состояния передачи управления , хост может переходить к следующей передаче управления конечной точки. Как описано в Разделе 5.5.4, эта следующая передача управления будет перемещаться в шине в зависимости от реализации хост контроллера время в последствии определенное(As described in Section 5,4,4, this next control transfer will be moved over the bus at some host controller implementation defined time in the future).
Конечная точка может быть занята для номера кадра определенного устройством при передвижении транзакций данных и состояния передачи управления (The endpoint can be busy for a device specific numbers of frames during the data and status transactions of the control transfer). В течение этого времени, когда конечная точка указывает, что она занята (обратитесь к Главе 8 и Главе 9 для подробностей), хост повторит транзакцию в более позднее время.(During these times when the endpoint indicates it is busy (refer to Chapter 8 and Chapter 9 for details), the host will retry the transaction at a later time.)
Если транзакция установка получена конечной точкой прежде, чем завершена предварительно инициализированная передача управления, устройство должно прервать текущую передачу/операцию и обработать новую транзакцию установки управления. Обычно транзакция установки не должна быть послана перед завершением предыдущей передачи управления.Однако, если передача прервана, например, из-за ошибок на шине, хост может посылать следующую транзакцию установки преждевременно в зависимости от переспектив конечной точки.
Изохронные передачи не поддерживают повторную передачу данных при ошибках на шине. Приемник может определять, что произошла ошибка передачи.(???) Низкий уровень протокола USB не позволяет возвратить квитирование передатчику изохронного канала. Обычно квитирование возвращается, чтобы сообщить передатчику, был ли пакет успешно получен или нет. Для изохронных передач, своевременность более важна чем правильность / перепередача, и с данным низким процентом ошибок, ожидаемых на шине, протокол, оптимизированный для приема передач, обычно устраивает. (For isochronous transfers, timeliness is more important than correctness/retransmission, and given the low error rates expected on the bus, the protocol is optimized assuming transfers normally succeed.) Изохронные приемники могут определять, были ли потери данные в течении кадра. Также, приемник может определять, сколько данных было потеряно. Раздел 5.10 описывает эти механизмы USB более подробно.
Конечная точка для изохронных передач никогда не бывает остановленной так как нет никакое квитирования, чтобы сообщить условие ОСТАНОВА(STALL). Хост и клиентское программное обеспечение никогда не может сталкиваться с таким случаем. Об ошибках сообщается как о состоянии, связанном с IRP для изохронной передачи, но изохронный канал не останавливается в случае ошибки. Если ошибка обнаружена, хост продолжает обрабатывать данные, связанные со следующим кадром передачи. Возможно ограниченное обнаружение ошибок, так как протокол для изохронных транзакций не позволяет передавать транзакции квитирования. (Limited error detection is possible since the protocol for isochronous transactions does not allow per transaction handshakes.)
Bulk транзакции используют данные переключения биты, в которых биты переключаются только после успешного завершения транзакции, для сохранения синхронизации между передатчиком и приемником, когда транзакции повторены из-за ошибок. (Bulk transactions use data toggle bits that are toggled only upon successful transaction completion to preserve synchronization between transmitter and receiver when transactions are retried due to errors.) Bulk транзакции инициализируются с DATA0, когда конечная точка сконфигурирована для соответствующей передачей управления (Bulk transactions are initialized to DATA0 when the endpoint is configured by an appropriate control transfer.) Хост также начнет первую bulk транзакцию с DATA0. Если bulk канал остановлен, переключатель данных на хосте сбрасывается к DATA0, когда остановка подтверждена(???) клиентом программного обеспечения через функцию USBD. Конечная точка имеющая условие останова, очищается с помощью соответствующей передачи управления.(The endpoint has its stall condition cleared via an appropriate control transfer.) Это действие также сбрасывает переключатель данных конечной точки к DATA0.
Bulk транзакции повторяются из-за ошибок, обнаруженных на шине, что воздействует на данную транзакцию. (Bulk transactions are retried due to errors detected on the bus that affect a given transaction.)
Транзакции Прерывания могут использовать или чередующиеся данные переключения бит такие, что биты переключаются только после успешного завершения передачи или непрерывно переключающиеся данные переключения бит.(Interrupt transactions may use either alternating data toggle bits such that the bits are toggled only upon successful transfer completion or a continuously toggling of data toggle bits.) Хост в любом случае должен допускать, что устройство повинуется всем правилам квитирования/повторения как определено в Главе 8. Устройство может выбирать, чтобы всегда переключить PIDs DATA0/DATA1 так, чтобы он мог игнорировать квитирование из хоста.(A device may choose to always toggle DATA0/DATA1 PIDs so that it can ignore handshakes from the host.) Однако, в этом случае, клиентское программное обеспечение может пропускать некоторые пакеты данных, когда происходит ошибка, потому что хост контроллер интерпретирует следующий пакет как повторение пропущенного пакета.
Если условие останова обнаружено на канале прерывания из-за ошибок передачи или сигнала квитирования ОСТАНОВ(STALL), возвращаемого из конечной точки, все задержанные IRPs удаляются. Удаление условия ОСТАНОВ(STALL) достигается вмешательством программного обеспечения по отдельному каналу управления. Это восстановление должно также сбросить данные переключения бита к DATA0 для конечной точки.(This recovery must also reset the data toggle bit to DATA0 for the endpoint.) Клиент программного обеспечения должен также вызвать Функцию USBD, чтобы сбросить данные переключения хоста к DATA0, подтвердить, и очищать условие останова на хосте.(The software client must also call a USBD Function to reset the host’s data toggle to DATA0, acknowledge, and clear the stall condition on the host.)
Транзакции Прерывания повторяются из-за ошибок, обнаруженных на шине, что воздействует на данную передачу (Interrupt transactions are retried due to errors detected on the bus that affect a given transfer.)
Посылка Команд Класса(Sending Class Commands)
Этот USBDI механизм используется клиентом, обычно определенного класса или адаптивным драйвером, посылая одну или более определенные классом команды на устройство.(This USBDI mechanism is used by a client, typically a class specific or adaptive driver, to send one or more class specific commands to a device. )
Посылка Команд Продавца
Этот USBDI механизм используется клиентом, посылая одну или более определенных продавцом команд на устройство.
Поток Данных
Хост контроллер ответственен за пересылку потоков данных между хостом и устройствами USB. Эти передачи данных обрабатываются как непрерывный поток байтов. USB поддерживает четыре базисных типа передач данных:
Передачи Управления
Изохронные передачи
Передачи Прерывания
Bulk Передачи
Для дополнительной информации относительно типов передачи, обратитесь к Главе 5.
Каждое устройство представляет один или более интерфейсов, которые клиент может использовать, чтобы связаться с ним. Каждый интерфейс составлен из нуля или большего количества каналов, которые индивидуально передают данные между клиентом и определенной конечной точкой на устройстве. USBD устанавливает интерфейсы и каналы при явном запросе программного обеспечения хоста. Когда сделан запрос конфигурации, хост контроллер обеспечивает обслуживание основанное на параметрах, предоставленных программным обеспечением хоста.
Канал имеет несколько характеристик основанными на требованиях к доставке перемещаемых данных. Примеры этих характеристик: скорость с которой данные должны быть перемещены, предоставляются ли данные в устойчивой скорости или спонтанно, как долго данные могут быть задержаны перед доставкой, и потеряны ли перемещаемых данных катастрофически.
Конечная точка устройства USB описывает характеристики, требуемые для специфического канала. Конечные точки описаны как часть информации характеризующей устройство USB. Для дополнительных подробностей, обратитесь к Главе 9.
Поток Связи в USB
USB обеспечивает сервисы связи между программным обеспечением на хосте и функциями USB. Функции могут иметь различные требования к потоку связи при взаимодействии разных клиентов с функцией(Functions can have different communication flow requirements for different client to function interactions). USB обеспечивает наиполнейшее использование шины, позволяя функции USB разделение различных потоков связи.(USB provides better overall bus utilization by allowing the separation of the different communication flows to a USB function). Каждый поток связи использует некоторый доступ к шине выполняя связь между клиентом и функцией. Каждый поток связи завершается в конечной точке на устройстве (Each communication flow is terminated at an endpoint on a device.) Конечные точки Устройства используются, чтобы определить вид каждого потока связи.
Диаграмма на Рисунке 5-8 показывает более детализировано Рисунок 5-2. Полное описание фактических потоков связи на Рисунке 5-2 поддерживает логическое устройство и функции уровня потока связи( The complete definition of the actual communication flows of Figure 5-8 supports the logical device and function layer communication flows). Эти фактические потоки связи пересекают несколько границ интерфейсов. Главы 6, 7, и 8 описывают механические, электрические параметры и определения интерфейса протокола “кабеля” USB. Глава 9 описывает интерфейс программирования устройства USB, который позволяет управлять устройством USB с помощью кабеля на стороне хоста.(Chapters 6, 7, and 8 describe the mechanical, electrical, and protocol interface definitions of the USB “wire.” Chapter 9 describes the USB device programming interface that allows a USB device to be manipulated from the host side of the wire.) Глава 10 описывает два интерфейса программного обеспечения на стороне хоста:
Драйвер Хост Контроллера (HCD) - интерфейс программного обеспечения между USB хост контроллером и программным обеспечением системы USB. Этот интерфейс позволяет реализовывать ряд хост контроллеров без требования того, чтобы все программное обеспечение хоста зависело от реализации любой особенности. Один Драйвер USB может поддерживать различные хост контроллеры без требуемых специфических знаний относительно реализации хост контроллера. Разработчик хост контроллера реализует HCD, который поддерживает хост контроллер.
Драйвер USB(USBD) - интерфейс между програмным обеспечением системы USB и клиентским программным обеспечением. Этот интерфейс обеспечивает клиентов удобными функциями для управления устройствами USB.
Рисунок 5-8. Детализированный Вид Хоста/устройства USB
Логическое устройство USB появляется в системе USB как скопление конечных точек. Конечные точки сгруппированы в наборы конечных точек, которые реализуют Интерфейс. Интерфейсы - это виды функции(Interfaces are views to the function). Системное программное обеспечение управляет устройством, используя Заданный по Умолчанию Канал (связанный с Конечной Точкой 0). Клиентское программное обеспечение управляет Интерфейсом, используя пучек каналов(связанный с Набором Конечных Точек). Клиентское программное обеспечение требует чтобы данные перемещались в USB между буфером на хосте и конечной точкой на устройстве USB. Хост контроллер (или устройство USB в зависимости от направления передачи) упаковывает данные при перемещении их по USB. Хост контроллер также осуществляет координацию, когда доступ к шине используется для перемещения пакета данных по USB.
Рисунок 5-9 иллюстрирует, как потоки связи - движутся по каналам между конечными точками и буферами памяти на стороне хоста. Следующие разделы описывают конечные точки, каналы, и потоки связи более подробно.
Рисунок 5-9. Поток Связи USB
Программное обеспечение на хосте связывается с логическим устройством через набор потоков связи. Набор потоков связи выбран проектировщиком(ами) программного обеспечения/аппаратных средств устройства так, чтобы требованиям к связи устройства эффективно соответствовали характеристикам передач, обеспечиваемых USB .( The set of communication flows are selected by the device software/hardware designer(s) to efficiently match the communication requirements of the device to the transfer characteristics provided by USB.)
Потоки в каналах
Потоки в каналах поставляют данные как часть пакета данных транзакций шины не приводя содержание данных к структуре требуемой USB (Stream pipes deliver data in the data packet portion of bus transactions with no USB required structure on the data content). Данные поступившие в один конец потока в канале, выходят с другой стороны в том же самом порядке(FIFO). Потоки в каналах - всегда направлены в одну сторону в своем потоке связи( Stream pipes are always unidirectional in their communication flow).
Данные, движущиеся через поток в канале ожидают взаимодействия, что в USB задумано как один клиент (Data flowing through a stream pipe is expected to interact from what USB believes is a single client.) Программное Обеспечение Системы USB не требуется при обеспечении синхронизации между множеством клиентов, которые могут использовать один и тот же поток в канале. Данные, предаваемые потоком в канале перемещаются через канал в последовательном порядке: "первым пришел", "первым вышел".
Поток в канале к устройству связан с одним номером конечной точки устройства в соответствующем направлении (то есть, соответствуя Входному(IN) или выходному(OUT) маркеру, как определено уровнем протокола). Номер конечной точки устройства для противоположного направления может использоваться для некоторого другого потока в канале к устройству.
Потоки в канале поддерживают следующие типы передачи bulk, изохронный, и прерывания, объясняемые ниже.
Потоковые Типы Данных
USB поддерживает обмен функциональными данными и сигналами управления между хостом USB и устройством USB или как набор однонаправленных или двунаправленных режимов. USB передачи данных происходят между программным обеспечением хоста и особой конечной точкой на устройстве USB. Данное USB устройство может поддерживать передачу многих данных к конечным точкам. Хост USB обрабатывает связь с любой конечной точкой устройства USB независимо от любой другой конечной точки. Такие соединения между программным обеспечением хоста и конечной точкой устройства USB называются каналами. Например, данное устройство USB могло бы иметь конечную точку, которая будет поддерживать канал для транспортировки данных в устройство USB и другую конечную точку, которая поддерживала бы канал для транспортировки данных из устройства USB.
Архитектура USB включает в себя четыре базисных типа передач данных:
Передачи управляющих сигналов, которые используются, чтобы конфигурировать устройства во время присоединения и могут использоваться другим устройством для специфических целей
Передачи данных типа Bulk, генерируются или используются при относительно больших объемах информации допускающих различные ограничения в передачи.
Передачи типа Прерывания такие как символы или координаты с откликом заметным человеком или характеристиками сигнала обратной связи (Interrupt data transfers such as characters or coordinates with human perceptible echo or feedback response characteristics)
Изохронные или потоковые(streaming) передачи данных в реальном времени, которые занимают заранее оговоренную пропускную способность USB Шины с заранее оговоренным временем отклика
Любой данный канал поддерживает точно один из типов передач, описанных выше. Потоковая модель USB описана более подробно в Главе 5.
Поведение Концентратора USB при Сбросе
Концентратор USB должен быть способен вызвать сброс для каждого порта через запрос хоста и принимать сигнал сброса на своем корневом порте.(A USB hub must be able to generate a per port reset via a host request and accept reset signaling on their root port.) Следующие разделы описывают поведение сброса концентратора и взаимодействия с возобновлением, присоединением, обнаружением, и с включением питания.
Поведение Концентратора в Состояниях
Поведение концентратора в состояниях показано на Рисунок 11-6. После появления сброса или включения питания, концентратор находится в WFSOP состоянии. Концентратор ждет начала пакета (SOP), который будет обнаружен на корневом порте или любом из неблокированных downstream портов. Если обнаружен SOP, концентратор устанавливает возникновение связи из порта, на котором произошел SOP и переходит в WFEOP состоянием. Он остается в этом состоянии, пока не столкнется с концом пакета (EOP) или пока не наступит конец кадра (EOF). При нормальных обстоятельствах, и когда не близок конец кадра, повторитель концентратора будет переходить туда и обратно между WFSOP и WFEOP.
Концентратор в idle (WFSOP) состояние отвечает в точке конца кадра (EOF1) переходит к состоянию WFSOF. Если концентратор находится в состоянии WFSOP в EOF1, он переходит к состоянию WFSOF. Переходы из WFSOP и WFEOP к WFSOF - не ошибки, а просто указывают, что концентратор приближается к концу кадра и не может устанавливать связь до начала следующего кадра.
WFEOF2 - специальное состояние, в которое осуществляется переход только, когда обнаружен babble или потеря действия шины (LOA) возле конца кадра и установлена связь вверх по иерархии. Если повторитель концентратора все еще в состоянии WFEOP (то есть, он не получил EOP) сталкиваясь с точкой EOF1, он переходит к состоянию WFEOF2. Он останется там до отметки EOF2 или происходящего вверх по иерархии EOP, в это время он переходит к WFSOF и ждет следующий вниз по иерархии SOP (DSOP), который будет обычно SOP, связанный с пакетом SOF, и указывающий начало следующего кадра. Когда происходит DSOP, концентратор возвращается к состоянию WFEOP , и ждет конца пакета. Если происходит конец кадра, и концентратор все еще поддерживает связь вниз по иерархии, концентратор не делает переход из состояния WFEOP; вместо этого он ждет следующий вниз по иерархии EOP (обычно EOP маркера SOF), который вызовет переход концентратора к состоянию WFSOP.
Если концентратор все еще в состоянии WFEOF2, когда происходит EOF2 , порт, который установил связь вверх по иерархии, должен быть заблокирован, независимо от состояния шины. Если, когда происходит EOF2, концентратор находится в состоянии WFSOF, и ведет связь вверх по иерархии, и шина находится в состоянии idle, то состояние предварительно соединенного порта остается неизмененным. Если концентратор находится в состоянии WFSOF при EOF2 и ведет связь вверх по иерархии, но шина не в состоянии idle, порт должен быть заблокирован.
Концентратор будет переходить к состоянию WFSOF после появления сигнала возобновления. Делая, так гарантируется, что трафик не может распространяться вверх по иерархии (и возможно, блокируются шина) пока таймер кадра концентратора не обнаружит по крайней мере один SOF. Подробности взаимодействия между таймером кадра и конечным автоматом повторителя концентратора описаны в Разделе 11.5.1.1.
Рисунок 11-6. Состояния Повторителя Концентратора
Повторитель концентратора поддерживает состояние для каждого пакета, который обнаружен и повторен концентратором. Конечный автомат повторителя не должен отслеживать более одного пакета и не должен, например прослеживать множество пакетов в транзакции. Рисунок 11-7 Показывает, как изменяются состояния концентратора в ходе нормальной передачи пакета.
Рисунок 11-7. Состояния Концентратора при Передачи Пакета
Поведение Концентратора Возле EOF
Поведение Концентратора возле конеца кадра схематично изображено на Рисунок 11-10. Имеется два временных маркера конца кадра, EOF1 и EOF2, соответствующих первой и второй точке EOF. Все концентраторы, получающие трафик вверх по иерархии, после обнаружения EOF1, передают EOP вверх по иерархии в течение двух полно скоростных времен передачи бита, переводя шину в idle состояние в течение одного времени передачи бита, и затем оставляет шину.(and then float the bus.) Начиная с EOF1, концентраторам не разрешается восстанавливать связь вверх по иерархии до завершения следующего(next) вниз по иерархии пакета, который обычно бывает следующим маркером SOF.
Рисунок 11-10. Поведения Концентратора Возле Конца Кадра
Поведение концентратора в конце кадра представлено ниже:
1. Поведение концентратора при восстановлении применяется только для трафика вверх по иерархии. Если концентратор сталкивается с концом кадра, и установлена связь вниз по иерархии, он поддерживает связь и ждет следующего downstream EOP, в это время он разрушит связь и возвратится в состояние WFSOP.
2. В точке EOF1, все концентраторы будут передавать EOP вверх по иерархии, переходить в idle состояние, и затем оставлять шину, если связь уже не установлена в направлении вниз по иерархии. EOP не должен быть короче или длиннее, чем любой уже отправленный в направлении вверх по иерархии EOP.
3. Концентраторы не позволят установить связь в направлении вверх по иерархии после EOF1.
4. Концентраторы, которые были в состоянии WFEOP в EOF1, должны наблюдать за EOPs на downstream порте, на котором была установлена связь. Они должны контролировать шину от EOF1 до EOF2.
5. Если обнаружен downstream EOP концентратором в состоянии WFEOF2 в окне от EOF1 до EOF2, концентратор будет, переходить к состоянию WFSOF и должен видеть idle на порте.
6. В EOF2, будут рассмотрены состояниях всех портов, и порт будет заблокирован если он не в подходящем состоянии (обратитесь к Таблица 11-4). В EOF2, концентраторы находящиеся все еще в WFEOF2 переходят в состояние WFSOF. Связь все еще не разрешена вниз по иерархии, пока не будет получен пакет от хоста.
Таблица 11-4. Поведение Концентратора в EOF2
|
Не Idle Состояние |
Idle Состояние |
|
|
WFSOF |
Заблокировать порт |
Не блокировать порт |
|
WFEOF2 |
Заблокировать порт |
Заблокировать порт |
Повышение и Падение Сигнала Данных во Времени (Data Signal Rise and Fall Time)
Повышение и понижение времени на выходе, измеряется между 10% и 90% сигнала (см. Рисунок 7-16). (The output rise time and fall time are measured between 10% and 90% of the signal.) Edge transition time for the rising and falling edges of full speed data signals is 4 ns (minimum) and 20 ns (maximum) measured with a capacitive load (CL) of 50 pF. The rise and fall times must be well matched. The rise and fall time of low speed signals is 75 ns (minimum) into a load of 50 pF and 300 ns (maximum) into a capacitive load of 350 pF. In both cases, the rising and falling edges should be smoothly transitioning (monotonic) when driving their respective cables to avoid excessive EMI. (В полно скоростных передачах сигналов, драйвер и кабельные импедансы не согласована, поэтому ожидется что будут отражения сигнала от конца кабеля приемника.)
Рисунок 7-16. Data Signal Rise and Fall Time
Предбуферирование Данных (Data Prebuffering)
USB требует, чтобы устройства предбуфера перед обработкой/передачей данных позволило хосту более гибко управлять перемещением каждой транзакции канала в шине от кадра к кадру (USB requires that devices prebuffer data before processing/transmission to allow the host more flexibility in managing when each pipe’s transaction is moved over the bus from frame to frame.)
Для передач от функции к хосту, конечная точка должна накоплять выборки в течение кадра X, пока она не получит маркерный пакет Начало Кадра (SOF) для кадра X + 1. Эти “защелки” данных из кадра X в пакет буфера, и теперь готов послать пакет, содержащий эти выборки в течение кадра X+1.(It “latches” the data from frame X into its packet buffer and is now ready to send the packet containing those samples during frame X+1.) Когда она пошлет эти данные в течение кадра определенного исключительно хост контроллером и могут изменяться от кадра к кадру.(When it will send that data during the frame is determined solely by the host controller and can vary from frame to frame.)
При передачах от хоста к функции, конечная точка примет пакет от хоста когда-нибудь в течении кадра Y. Когда она получает SOF для кадра Y+1, она может начинать обрабатывать данные, полученные в кадре Y.
Этот подход позволяет конечной точке использовать маркер SOF как устойчивые часы с очень небольшой флуктуацией/дрейфом, когда хост контроллер перемещает пакет по шине при также разрешении хост контроллера, чтобы измениться внутри кадра точно, когда пакет фактически перемещается по шине. (This approach allows an endpoint to use the SOF token as a stable clock with very little jitter/drift when the host controller moves the packet over the bus while also allowing the host controller to vary within a frame precisely when the packet is actually moved over the bus.) Это предбуферирование предоставляет некоторую дополнительную задержку между тем, когда выборка является доступной в конечной точке и когда она перемещается по шине, сравнивая с окружением, где доступ шины - точно то же самое смещение времени из SOF от кадра к кадру.(This prebuffering introduces some additional delay between when a sample is available at an endpoint and when it moves over the bus compared to an environment where the bus access is at exactly the same time offset from SOF from frame to frame.)
Рисунок 5-16 показывает последовательность времен, где передача от функции к хосту (Входной процесс), данные D0 накапливаются в течение кадра Fi во время Ti
и передаются на хост в течении кадра FI+1. Точно так же для передачи от хоста к функции (Выходной процесс), данные D0 получены конечной точкой в течение кадра Fi+1 и обработан в течение кадра Fi+2.
Рисунок 5-16. Предбуферирование Данных
Предпосылки
Мотив для создания Универсальной Последовательной Шины заключается в трех связанных между собой темах:
Подсоединение PC к телефону
Понятно, что объединение компьютеров и коммуникация будут основанием для создания следующего поколения приложений. Движение машинно-ориентированных и ориентируемых на пользователя типов данных из одного места или среды к другому, зависит от возможности повсеместности и дешевизны связи. К сожалению, компьютерные и коммуникационные отрасли промышленности развивались независимо. Универсальная Последовательная Шина обеспечивает повсеместную связь, которая может использоваться во всем широком диапазоне подсоединения PC к телефону.
Простота в использовании
Недостаток гибкости в реконфигурировании PC была одной из основных проблем дальнейшего развития систем. Комбинация дружественных графических интерфейсов и аппаратных средств и механизмов программного обеспечения, связанных с шиной нового поколения архитектуры подобной PCI, PnP ISA, и PCMCIA сделала компьютеры менее конфронтационными и проще реконфигурируемыми. Однако, с точки зрения конечного пользователя, интерфейсы Ввода - Вывода PC типа последовательных / параллельных портов, интерфейсы клавиатуры/мыши/джостика, и т.д., не имеют атрибутов PnP.
Расширение Порта
Добавление внешних периферийных устройств продолжает быть ограничением возможности порта. Недостаток двунаправленных, дешевых, низко и средне скоростных периферийных шин, сдержал создание быстро увеличивающихся периферийных устройств типа телефон/факс/модем адаптеров, автоответчиков, сканеров, PDA's, клавиатур, мышей, и т.д. Существующие соединители, оптимизированы для одного или двух конечных продуктов. Поскольку новые функции или возможности добавляются в PC, новый интерфейс был определен так, чтобы решить потребность расширения порта.
Универсальная Последовательная Шина - ответ на подсоединение в архитектуре PC. Это быстрый, двунаправленный, изохронный, дешевый, динамически присоединяемый последовательный интерфейс, который будет совместим с требованиями платформы PC сегодня и завтра.
Прерывание выполнения IRPs
USBDI должен позволить прерывать IRPs специфических каналов.
Пример Изохронного Приложения Не USB
Используемый пример приемлим как пример общего случая. Возможны другие более простые или более сложные случаи, и могут использоваться соответствующие определенные возможности USB или не соответствующие.(Other simpler or more complex cases are possible and the relevant USB features identified can be used or not as appropriate.)
Пример состоит из 8 кГц моно микрофона подсоединенного к драйверу смесителя, который посылает входной поток данных на 44 кГц стерео колонки. Смеситель ожидает, что данные будут получаться и передаваться с некоторой типовой скоростью и закодированными. Подходящий по скорости драйвер преобразовывает на входе и выходе типовую скорость и кодировку из естественной для устройства скорости и кодировки к скорости и кодировки ожидаемой смесителем. Рисунок 5-13 иллюстрирует этот пример.
Задающий генератор (может обеспечиваться программным обеспечением, управляемым от часов реального времени) в PC, используется для пробуждения смесителя, чтобы опросить входной источник о входных данных и предоставить выходные данные в сток вывода.(A master clock (can be provided by software driven from the real time clock) in the PC is used to awaken the mixer to ask the input source for input data and to provide output data to the output sink.) В этом примере, принято что он пробуждается каждые 20 мс(In this example, assume it awakens every 20 ms.) Микрофон и колонки, имеют свои собственные типовые часы которые несинхронизированы относительно друг друга или с задающими часами смесителя (master mixer clock). Микрофон производит данные с естественной скоростью (выборка(samples) 1 байта, 8'000 раз в секунду) и колонки потребляют данные со своей естественной скоростью (выборка 4 байт, 44'100 раз в секунду). Трое часов в системе могут дрейфовать и иметь флуктуацию относительно друг друга. Каждый согласователь скорости может также выполняться при различной естественной скорости или как драйвер смесителя, входной источник/драйвер, или как выходной сток / драйвер.(Each rate matcher may also be running at a different natural rate than either the mixer driver, the input source/driver, or output sink/driver.)
Согласователи скорости также контролируют, длительность срока скорости передачи данных своего устройства, сравнивают с часами главного смесителя и интерполируют дополнительную выборку или объединяет две выборки, чтобы скорректировать скорость передачи данных своего устройства со скоростью передачи данных смесителя (The rate matchers also monitor the long term data rate of their device compared to the master mixer clock and interpolate an additional sample or merge two samples to adjust the data rate of their device to the data rate of the mixer.) Эта корректировка может требоваться каждую пару секунд, но обычно происходит нечасто. Согласователи скорости обеспечивают некоторую дополнительную буферизацию, чтобы осуществить соответствие скорости.(The rate matchers provide some additional buffering to carry through a rate match.)
Следует заметить, что никакое другое приложение не поддерживает возможность применения корректирующей выборки и будет нуждаться в некоторых других средствах согласования задающего генератора с дрейфующими часами устройства, или иначе потребовались бы некоторые средства синхронизирования часов, для гарантии того, что не сможет произойти никакой дрейф.
Смеситель всегда ожидает, при получении, точно период обслуживания данных (20 мс - период обслуживания ) из устройства ввода данных и при отправки точно период обслуживания данных для устройства вывода. (The mixer always expects to receive exactly a service period of data (20 ms service period) from its input device and produce exactly a service period of data for its output device.) Смеситель может задерживаться на меньше чем период обслуживания, если нет доступных данных или места в устройстве ввода-вывода. (The mixer can be delayed up to less than a service period if data or space is not available from its input/output device.) Принято, что смесителем такие задержки не накапливаются.(The mixer assumes that such delays don’t accumulate.)
Устройства ввода и вывода и их драйверы ожидают возможности поместить/получить данные в ответ на аппаратное прерывание из контроллера ПДП(DMA), когда их преобразователь обработал один период обслуживания данных. Они ожидают получения/помещения точно один период обслуживания данных. Устройство ввода производит 160 байтов (10 выборок) каждый период обслуживания 20 мс. Устройство вывода потребляет 3528 байтов (882 выборок) каждый период обслуживания 20 мс. Контроллер ПДП может перемещать одну выборку между устройством и буфером хоста со скоростью намного больше чем скорость выборки любого устройства.
Входные и выходные драйверы устройства обеспечивают два периода обслуживания буферизации системы.( The input and output device drivers provide two service periods of system buffering) Один буфер всегда обрабатывается контроллером ПДП. Гарантируется что другой буфер будет готов прежде, чем будет исчерпан текущий буфер . Когда текущий буфер освобожден, аппаратное прерывание пробуждает драйвер устройства, и он(драйвер) вызывает согласователь скорости, чтобы дать ему(??кому) буфер.(When the current buffer is emptied, the hardware interrupt awakens the device driver and it calls the rate matcher to give it the buffer.) Драйвер устройства запрашивает новый IRP с буфером прежде, чем будет исчерпан текущий буфер.(The device driver requests a new IRP with the buffer before the current buffer is exhausted.)
Устройства могут обеспечивать две выборки буферизированных данных, чтобы гарантировать, что они всегда имеют обработанную выборку для следующего периода выборки, в то время как система реагирует на предыдущую/следующую выборку.(The devices can provide two samples of data buffering to ensure that they always have a sample to process for the next sample period while the system is reacting to the previous/next sample.)
Периоды обслуживания драйверов выбраны, чтобы пережить прерывание переменного времени отклика, которое может присутствовать в среде операционной системы.(The service periods of the drivers are chosen to survive interrupt latency variabilities that may be present in the operating system environment. ) Различное окружение операционной системы требует различных периодов обслуживания для надежного выполнения операции.(Different operating system environments will require different service periods for reliable operation.) Периоды обслуживания также выбраны для помещения минимальной загрузки прерываний в системе так как может иметься другое программное обеспечение в системе, которое требует время для обработки.(The service periods are also selected to place a minimum interrupt load on the system since there may be other software in the system that requires processing time.)
Присоединение Устройства USB
Все устройства USB присоединяются к USB через порт находящийся на специализированных устройствах USB, известных как концентраторы. Концентраторы показывают состояние порта т.е. присоединено или удалено устройство USB. Хост делает запрос к концентратору, чтобы определить причину уведомления. Концентратор отвечает, определяя используемый порт, к которому присоединено устройство USB. Хост дает возможности порту и адресует устройство USB с каналом управления, используя Заданный по умолчанию Адрес(Default Address) USB. Все устройства USB адресованы, используя USB Заданный по умолчанию Адрес когда было первое соединение или после сброса.
Хост определяет, является ли недавно присоединенное устройство USB концентратор или функция и назначает уникальный адрес USB устройству USB. Хост устанавливает канал управления для устройства USB, используя назначенный адрес USB и конечную точку с номером ноль.
Если присоединенное устройство USB - концентратор, и устройства USB присоединены к портам, то вышеупомянутая процедура сопровождается для каждого из присоединенных устройств USB.
Если присоединенное устройство USB - функция, то уведомления присоединения будут посланы программным обеспечением USB в заинтересованное программное обеспечение хоста.
Присоединенное Состояние
Устройство USB может быть присоединено или отсоединено от USB. Состояние устройства USB, когда оно отсоединено от USB, не определено в этой спецификации. Эта спецификация только выдвигает требования к операциям и атрибутам, если устройство присоединено.
Присоединенные к Питанию и к Земле Резисторы
Концентраторы и устройства, с которыми они соединяются, используют комбинацию присоединенных к питанию и земле резисторов, чтобы управлять D+ и D- в отсутствии их активного управления.(absence of their being actively driven.) Эти резисторы устанавливают уровни напряжения, используемые для сообщения о соединении и разъединении, а также поддерживают линии данных в их idle значениях когда нет активности. Каждый downstream порт концентратора требует присоединенный к земле (Rpd) на каждой линии данных; корневой порт концентратора требует присоединенного к питанию (Rpu) на линии D+. Значения для Rpu и Rpd представлены в Главе 7.
Протокол Перемещения
Хост контроллер управляет интерфейсом уровня протокола USB. Он вставляет информацию соответствующую протоколу для исходящих передач. Он также разделяет и интерпретирует входящую информацию соответствующую протоколу.
Протокол Шины
Все передачи транзакций шины включают(involve) до трех пакетов. Каждая транзакция начинается, когда хост контроллер, по расписанию, посылает USB пакет, описывающий тип и направление транзакции, адрес устройства USB, и номер конечной точки. Этот пакет упоминается как Маркерный Пакет(Token Paket). Устройство USB, к которому адресовано сообщение самостоятельно идентифицируется, декодируя соответствующие поля адреса. В данной транзакции, данные переданы или с хоста на устройство или с устройства на хост. Направление передачи данных определено в маркерном пакете. Источник транзакции затем посылает Пакет Данных(Data Paket) или сообщает, что больше нет никаких данных для передачи. Адресат в общем случае посылает Пакет Квитирования(Handshake Paket), который показывает, была ли передача успешной.
Модель передачи данных USB шины между источником или адресатом на хосте и конечной точке на устройстве упоминается как канал(pipe). Имеются два типа каналов: поток(stream) и сообщение(message). Поток данных не имеют никакой структуры определенной USB, в то время как сообщения данных имеют. Additionally, pipes have associations of data bandwidth, transfer service type, and endpoint characteristics like directionality and buffer sizes. Каналы появляются при конфигурировании устройства USB. Один канал сообщения, Канал Управления(Control Pipe) 0, всегда существует, если только устройство включено, чтобы обеспечить доступ к конфигурации устройства, его состоянию, и управляющей информацией.
Расписание посылок транзакций позволяет управлять потоком данных для некоторых режимов потоков в канале(stream pipes). На аппаратном уровне, это предотвращает такие ситуации буфера как обнуление или переполнение, используя NACK квитирование, чтобы уменьшить скорость передачи данных. The token for a NACK’ed transaction is reissued when bus time is available. Механизм управления потоком данных разрешает создание гибких расписаний , которые согласовывают параллельное обслуживание гетерогенной смеси режимов потоков в канале. Таким образом, множество режимов потока в канале могут обслуживаться в различные интервалах и содержать пакеты различных размеров.
Распределение питания
Этот раздел описывает спецификацию разводки питания USB.
Распределение пропускной способности USB шины
Пропускная способность USB распределена между каналами. USB распределяет пропускную способность для некоторых каналов, когда установлен канал. Для Устройства USB нужно обеспечить некоторую буферизацию данных. Подразумевается, что устройства USB, требующие большую пропускную способность могут обеспечить установку больших по размеру буферов. Цель архитектуры USB состоит в том, чтобы гарантировать, что буферизация вызванная аппаратной задержкой ограничена внутри нескольких миллисекунд.
Вся пропускная способность USB шины может быть распределена среди множества различных потоков данных. Это позволяет широкому диапазону устройств присоединиться к USB. Например, возможно приспособить телефонные устройства имеющие пропускной способность в пределах от 1B+D с полностью до T1. Далее, могут одновременно обеспечиваться скорости передачи бит в различных устройствах, с широким динамическим диапазоном.
USB блокирует распределение пропускной способности; то есть, при распределении дополнительного канала произойдет нарушение существующей пропускной способности или распределения временен отклика, поэтому дальнейшее распределение каналов отклоняется или блокируется. Когда канал закрыт, распределенная пропускная способность освобождена и может быть перераспределена на другой канал.
Спецификация USB определяет правила того, каким образом каждому типу передач позволено иметь доступ к шине.
Расширения Архитектуры
Архитектура USB допускает расширение в интерфейсе между Драйвером Хост Контроллера и драйвером USB. Возможность реализации систем с множеством хост контроллеров, и связанных Драйверов Хост Контроллера.
Глава 5
Модель Потока USB
Разрушенное Квитирование ACK
Передатчик последний и единственный, кто знает наверняка, была ли транзакция успешной, что обеспечивается получением квитирования ACK. Потерянное или разрушенное квитирование ACK может вызвать временную потерю синхронизации между передатчиком и приемником как показано на Рисунок 8-18. Здесь передатчик выдает пакет достоверных данных, который успешно принят приемником; в то время как квитирование ACK разрушено.
Рисунок 8-18. Разрушенное Квитирование ACK с Повторением
В конце транзакции <i>, имеется временно теряется согласованность между передатчиком и приемником, из-за несоответствия их бит последовательности. Приемник получил "хорошие" данные, но передатчик не знает, были ли данные успешно посланы. В следующей транзакции, передатчик снова пошлет предыдущие данные, используя предыдущий PID DATA0. Бит последовательности приемника и PID данных не совпадут, и приемник узнает, что он уже принял эти данные. Следовательно, он отбрасывает входящий пакет данных и не переключает бит последовательности. Приемник затем выдает ACK, чтобы передатчик считал повторенную транзакцию успешно принятой. Получение ACK заставляет передатчик переключать бит последовательности. В начале транзакции <i+1>, биты последовательности переключены и снова синхронизированы.
Передатчик данных должен гарантировать, что все повторно переданные пакеты данных, имеют ту же длину что и первоначальная транзакция. Если передатчик данных неспособен на это, из-за таких проблем как условие переполнения буфера, он должен прерывать транзакцию, генерируя нарушение вставки бит. Это вызывает обнаруживаемую ошибку в приемнике и гарантирует, что частичный пакет не будет интерпретироваться как хороший пакет. Передатчик не должен пытаться вызывать ошибку в приемнике, посылая заранее известный плохой CRC. Комбинация плохого пакета с “плохим” CRC может интерпретироваться приемником как хороший пакет.
Разводка питания
Каждый сегмент USB обеспечивает ограниченное количество мощности на кабеле. Хост обеспечивает мощностью устройства USB, которые непосредственно подсоединены. Кроме того, любое устройство USB может иметь собственное питание. Устройства USB, которые полагаются полностью на питание от кабеля, называются питающимися от шины(bus-powered) устройствами. Напротив, те которые имеют альтернативный источник питания, называются устройствами с независимым питанием(self-powered). Концентратор также обеспечивает мощностью подсоединенные USB устройства. Архитектура разрешает применять питающиеся от шины концентраторы в некоторых ограниченных топологиях, которые будут рассмотрены позже в Главе 11. Устройства с собственным источником питания должны выполнить предписанные механизмы безопасности отсоединения мощности. На рисунке 4-4,изображены клавиатура, перо, и мышь которые могут все быть питающимися от шины устройствами.
Регулирование Мощностью Порта Концентратора
Концентраторы позволяют управлять мощностью порта системе хоста. Как описано предварительно, концентраторы поддерживают мощность для каждого порта или режим группы, запитывающую downstream порты. Переключение мощности порта выполняется с помощью команд концентратора, которые определены ниже. Концентраторы с переключением мощности для каждого порта могут также допускают использование переключение мощности в режиме группы, определяя некоторое значение в поле запроса в запросе регулирования мощности порта (обратитесь к определению запроса SetPortFeature (PORT_POWER) в Разделе 11.12.2.9).
Концентраторы могут при желании маскировать регулирование мощности в режима группы для некоторых портов. Это позволяет концентратору независимо управлять переключением мощности для некоторых портов, независимо от общих характеристик переключения порта. Например, рассмотрим концентратор с переключением мощности порта в режиме группы, который имеет постоянно присоединенное устройство к порту (“ к внедренному порт ”). Если в поле Маски Регулирования Мощностью Порта для внедренного порта указано, что переключение мощности режима группы замаскировано, любые команды концентратора, которые управляют портами в режиме группы, не будет воздействовать на внедренный порт.
Режим Канала
Канал поддерживает режимы передачи потока или сообщения. В режиме потока, поток данных, рассматривается как однонаправленный последовательный поток выборок. В режиме сообщения, данные доставляются как связанный набор байтов. В режиме сообщений каналы, рассматриваются как способные, быть двунаправленными.
В режиме потока канал всегда однонаправлен. Когда в режиме потока, конечная точка ожидает получать маркер ей будут посланы или данные запрашиваемые конечной точке или подготовленные для нее данные. Количество посланных данных всегда будет меньше или равно чем текущий MaxPacketSize для конечной точки.
Передачи сообщений начинаются командой с хоста на устройство. Устройство может отвечать командой с данными, хост может передавать команду с данными для устройства, или команда может требовать, чтобы данные не передавались, в этом случае будет послан пакет данных NULL.(The device may respond to the command with data, the host may follow the command with data for the device, or the command may require no data to be transmitted in which case a NULL data packet will be sent.) В режиме сообщения, конечная точка должна следить за тем, в какой, определенной режимом последовательности, фазе она находится. Конечная точка ожидает первую транзакцию последовательности сообщений, которая устанавливает последующую связь. После того, как установка получена, конечная точка обычно ожидает маркер, запрашивающий конечную точку послать данные (маркер IN) или приводящий ее в готовность для получения данных (OUT маркер). Конечная точка будет знать направление последующих транзакций, из команды установки, которая начала последовательность транзакций. Некоторые команды установки не требуют последующих транзакций от или к конечной точке. Транзакции Установки всегда восемь байтов или меньше. Последующие транзакции будут всегда иметь размер, меньший или равный текущему MaxPacketSize конечной точки.
Руководства Среды Операционной Системы
Как отмечено предварительно, фактические интерфейсы между программным обеспечением USB и программным обеспечением хоста зависят от платформы хоста и операционной системы. Требуется совместная спецификация для каждой комбинации платформы и операционной системы поддерживающей USB. Эти спецификации описывают специфические интерфейсы, используемые, чтобы интегрировать USB в хост. Каждый поставщик операционной системы для программного обеспечения USB определяет совместимое изменение Универсальной USB Спецификации.
Глава 11
Спецификация Концентратора
Сбор Статистики Состояний и Действий
Как основной поставщик информации для всех передач управления и данных между хостом и устройствами USB, система USB и хост контроллер находятся в хорошем месте, чтобы отслеживать информацию о действиях и состояниях. Такая информация предоставляется на запрос к программному обеспечению хоста, позволяя этому программному обеспечению управлять информацией действия и состояния.(Such information is provided upon request to host software allowing that software to manage status and activity information.)
Сброс Портов
Концентратор может осуществлять сброс каждого порта через запрос SetPortFeature (PORT_RESET). Этот запрос определяет номер downstream порта. В ответ на запрос SetPortFeature (PORT_RESET), концентратор вводит SE0 на downstream порт по крайней мере 10 мс, возвращает шину к состоянию idle (J), и помещает порт в неблокированное(enabled) состояние. SetPortFeature (RESET) - атомная операция(is an atomic operation;); задержка в 10 мс между началом и концом сброса управляется концентратором. Концентратор должен быть способен возвратить на хост состояние запроса сброса; то есть, завершен ли сброс так, что хост не должен сохранять слежение за прошедшим временем в течение операции сброса. Запрос сброса порта может быть выдан на порт в любом его состоянии; однако, не будет сгенерирован никакой сигнал вниз по иерархии, если сброс выдан к порту в состоянии powered off или disconnected.
Обнаружение присоединения устройства требует, чтобы порт в вопросе был с включенным переключением мощности (если есть переключение мощности).(Device attach detection requires that the port in question be power-switched on (if power switching is an option). Когда устройство присоединено, концентратор может обнаружить присоединение через переход шины от SE0 к DIFF1 или DIFF0. Требуется, чтобы заблокированные порты не управлялись концентратором, в то время как выполняется обнаружение присоединения. Это не должно быть проблема, поскольку порт будет заблокирован, и выходные драйверы отпущены ,при обнаружении, предыдущим событием отсоединения.(This should not be a problem, as the port will have been disabled and its output drivers floated by detection of the previous detach event.) Хост может определить быстродействие устройства, исследуя поднята ли D+ или D-.
Прежде, чем порт, с которым устройство было соединено, может быть разблокирован мы должны быть уверены, что устройство было сброшено. Так как не возможно положиться на потерю Vbus, вызванную событием разъединения, сбрасывающего устройство, порт должен быть сброшен прежде, чем будет разблокирован. Это выполняется через atomic запрос SetPortFeature (PORT_RESET), который выдает сигнал сброса SE0 и затем разблокирует порт. Устройства USB, включая концентраторы, должны быть способны ответить на хост, обращаясь не позже чем через 10 мс, после того, как сброс де-утвержден (de-asserted).
Сервисные Возможности
USBD предоставляет сервисы в следующих категориях:
Конфигурация с помощью механизмов команды
Сервисы передачи через механизмы и команды и канала
Уведомление События
Сообщение состояния и восстановление при ошибках
Сервисы Конфигурации
Сервисы Конфигурации функционируют на базис устройства. USBD выполняет конфигурацию устройства в направлении задаваемым конфигурирующим программным обеспечением.(The USBD performs device configuration at the direction of the configuring software.) Драйвер концентратора имеет специальную роль в управлении устройства и обеспечивает по крайней мере следующие возможности:
Распознавание присоединения/отсоединения устройства, управляемое по каналу прерывания, принадлежащего драйверу концентратора
Сброс устройства, выполненный драйвером концентратора, сбрасывая по upstream порту концентратора устройство(Device reset, accomplished by the hub driver by resetting the hub port upstream of the device)
Направляет USBD, для выполнения назначения адреса устройства
USBDI дополнительно обеспечивает следующие средства конфигурации, которые могут использоваться драйвером концентратора или другим конфигурирующим программным обеспечением, имеющимся на хосте:
Идентификация устройства и доступ к информации о конфигурации (через доступ к дескрипторам на устройстве)
Конфигурация устройства через механизмы команды
Когда драйвер концентратора сообщает USBD о присоединении устройства, USBD устанавливает создаваемый по умолчанию канал для нового устройства.
Шаблон Sync
Битовый шаблон NRZI, показан на Рисунок 7-15 используется как шаблон синхронизации и как префикс к каждому пакету. Этот шаблон эквивалентен шаблона данных из семи 0 следующих за 1 (0x80=10000000B).
Рисунок 7-15. Шаблон Sync
Ширина EOP
Ширина SE0 в EOP около 2 * TPERIOD. Ширина EOP измеряется с той же самой емкостной загрузкой, используемой для максимального повышения и понижение времени и измеряется на том же самом уровне как и сигналы точки пересечения дифференциальных линий данных (см. Рисунок 7-18).
Рисунок 7-18. Временная Ширины EOP (EOP Width Timing)
Для полно скоростных передач, ширина EOP от передатчика должна быть между 160 нс и 175 нс. Для низко скоростных передач, ширина EOP от передатчика должна быть между 1.25 mс и 1.50 mс. Эти диапазоны включают временной разброс из-за дифференциальной буферной задержки и несоответствия повышения/понижения времен, шума и других произвольных эффектов.
Полно скоростной приемник должен принять SE0 шириной 82 нс сопровождаемый J переходом как допустимый(valid) EOP. SE0 более узкий чем 40 нс или любой SE0, не сопровождаемый J переходом должен быть отклонен как EOP. Приемник может отклонять или принимать EOP между 40 нс и 82 нс как продиктовано в зависимости от реализации осуществления выборки и синхронизации.( The receiver may reject or accept an EOP between 40 ns and 82 ns as dictated by implementation depending on sampling and synchronization.) Низко скоростной приемник должен принять SE0 шириной 670 нс сопровождаемый J переходом как допустимый EOP. SE0 более узкий чем 330 нс или SE0, не сопровождаемый J переходом должен быть отклонен как EOP. EOP между 330 нс и 670 нс может быть отклонен или принят как описано выше. Хост является исключением из этого правила и всегда использует полно скоростные временные правила EOP при получении и при любой скорости передачи данных. (Это необходимо для поддержания восстановлении при ошибках в конце-пакета. Обратитесь к Разделу11.4.5.) Любой SE0, который более широкий чем 2.5 mс автоматически сбрасывается или разъединяется (в зависимости от направления).
Синхронизация
Хост выдает специальный маркер SOF на шину в регулярно установленные интервалы. Допуск ошибки интервала между SOFs(обратитесь к Главе 7) составляет 1 мс. Конечные точки могут использовать этот маркер, чтобы синхронизировать свои связанные часы с часами USB. Это дает возможность конечным точкам, согласовать свою скорость приема или выдачи данных со скоростью хоста.
Не всем конечным точкам требуется синхронизации SOF. Некоторые конечные точки, требующие синхронизацию имеют часы, которые не могут быть синхронизированы с обеспечиваемыми USB 1 мс часами шины. Такие устройства имеют две возможности. Они могут пытаться взять всю синхронизацию USB на себя или такие устройства могут периодически корректировать свою скорость передачи, поскольку они компенсируют различие между часами USB и своими собственными часами.(They can attempt to have the entire USB synchronize to them or such devices may periodically adjust their transfer rate as they compensate for the difference between the USB clock and their own clock.)
USB предусматривает максимум одного клиента как образец USB, для корректировки выдачи SOF хостом.(USB provides for a maximum of one client per USB instance to adjust the host’s SOF generation.) Этот клиент выполняет корректировку, основанную на обратной связи, обеспечиваемой связанным устройством.( This client performs the adjustment based on feedback provided by an associated device.) Скорость выдачи SOF маркера, все еще остается 1 мс. Обратитесь к Главе 10 для полного рассмотрения этого механизма корректировки. Если конечная точка не была сконфигурирована, для корректировки часов USB используется SOF квитирование, или если конечная точка не способна к такой корректировки часов, то конечная точка должна непрерывно корректировать поток данных.
Следовательно, как отмечено выше, имеются три возможных типа взаимодействия синхронизации для конечной точки касаемо SOF. Конечная точка может:
1. Синхронизировать свои часы точно с существующими часами USB.
2. Корректировать часы шины.
3. Синхронизироваться с хостом, регулируя поток данных.
Важно обратить внимание, что конечная точка, требующая синхронизацию, которую не может выполнить тип синхронизации, описанной в (1), но может выполнить тип, описанный в (2), должна также выполнить тип, описанный в (3). Так происходит потому что, нельзя гарантировать что такая конечная точка будет выбрана как конечная точка корректирующая часы шины. Только одно устройство во всей USB будет использоваться, чтобы корректировать SOF.
