Шины.PCI,.USB.и.FireWire

хабы USB (USB Hubs), обеспечивающие дополнительные точки подключения устройств;

кабели USB, соединяющие устройства с хабами.

Программная часть USB включает:

клиентское ПО (CSw, Client Software) — драйверы устройств USB, обеспечива$ ющие доступ к устройствам со стороны прикладного ПО. Эти драйверы взаи$ модействуют с устройствами только через программный интерфейс с общим драйвером USB (USBD). Непосредственного обращения к каким$либо регист$ рам аппаратных средств драйверы устройств USB не выполняют;

драйвер USB (USBD, USB Driver), «заведующий» всеми USB$устройствами системы, их нумерацией, конфигурированием, предоставлением служб, распре$ делением пропускной способности шины, мощности питания и т. п.;

драйвер хост контроллера (HCD, Host Controller Driver), преобразующий за$ просы ввода/вывода в структуры данных, размещенные в коммуникационной области оперативной памяти, и обращающийся к регистрам хост$контроллера. Хост$контроллер выполняет физические транзакции, руководствуясь этими структурами данных.

Драйверы USBD и HCD составляют хост$часть ПО USB; спецификация USB очер$ чивает круг их задач, но не описывает интерфейс между ними.

Физическое устройство USB должно иметь интерфейс USB, обеспечивающий пол$ ную поддержку протокола USB, выполнение стандартных операций (конфигури$ рование и сброс) и предоставление информации, описывающей устройство. Фи$ зические устройства USB могут быть комбинированными (compound devices): включать в себя несколько устройств$функций, подключенных к внутреннему хабу, а также предоставлять своим внутренним хабом дополнительные внешние точки подключения.

Работой всех устройств шины USB управляет хост контроллер (host controller), являющийся программно$аппаратной подсистемой хост компьютера. Хост$кон$ троллер является интеллектуальным устройством шины PCI или составной час$ тью «южного» хаба (моста) системной платы, интенсивно взаимодействующим с оперативной памятью.

Физическая топология шины USB — многоярусная звезда (рис. 9.1, а). Ее верши$ ной является хост$контроллер, объединенный с корневым хабом (root hub). Хаб является устройством$разветвителем, он может служить и источником питания для подключенных к нему устройств. К каждому порту хаба может непосредствен$ но подключаться периферийное устройство или промежуточный хаб; шина допус$ кает до пяти уровней (ярусов) каскадирования хабов (не считая корневого). По$ скольку комбинированные устройства содержат внутри себя хаб, их подключение к хабу пятого яруса уже недопустимо. Каждый промежуточный хаб имеет несколько нисходящих (downstream) портов для подключения периферийных устройств (или нижележащих хабов) и один восходящий (upstream) порт для подключения к кор$ невому хабу или нисходящему порту вышестоящего хаба.

Рис. 9.1. Различные взгляды на отношения в USB: а — физическая топология; б — логическая топология

Логическая топология USB — звезда. Хабы (включая корневой) создают иллюзию непосредственного подключения каждого логического устройства к хост$контрол$ леру (рис. 9.1, б). В этой звезде устанавливаются сугубо подчиненные отношения по системе опроса$ответа: хост$контроллер по своей инициативе передает данные к выбранному устройству или принимает их. Устройство по своей инициативе передавать данные не может; непосредственные передачи данных между устрой$ ствами невозможны. Устройство по своей инициативе может лишь сигнализиро$ вать о «пробуждении» (wakeup), для чего используется специальная сигнализа$ ция, но не передача данных.

Физический интерфейс USB прост и изящен. Конструкция кабелей и коннекторов USB не дает возможности ошибиться при подключении устройств (рис. 9.2, а и б). Для распознавания разъема USB на корпусе устройства ставится стандартное сим$ волическое обозначение (рис. 9.2, в). Гнезда типа «A» устанавливаются только на нисходящих портах хабов, вилки типа «A» — на шнурах периферийных устройств или восходящих портов хабов. Гнезда и вилки типа «B» используются только для шнуров, отсоединяемых от периферийных устройств и восходящих портов хабов (от «мелких» устройств — мышей, клавиатур и т. п. кабели, как правило, не отсо$ единяются). Для малогабаритных устройств имеются разъемы mini$B, а для под$ держки OTG (On$the$Go, см. главу 15) имеются и вилки mini$A, и розетки mini$ AB. Хабы и устройства обеспечивают возможность «горячего» подключения и отключения с сигнализацией об этих событиях хосту.

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

Рис. 9.2. Коннекторы USB: а — вилка типа «A»; б —вилка типа «B»; в — символическое обозначение

Логическое устройство USB представляет собой набор независимых конечных то чек (Endpoint, EP), с которыми хост$контроллер (и клиентское ПО) обменивается информацией. Каждому логическому устройству USB (как функции, так и хабу) конфигурационная часть ПО хоста назначает свой адрес (1–127), уникальный на данной шине USB. Каждая конечная точка логического устройства идентифици$ руется своим номером (0–15) и направлением передачи (IN — передача к хосту, OUT — от хоста). Точки IN4 и OUT4, к примеру, представляют собой разные конеч$ ные точки, с которыми могут общаться даже модули клиентского ПО. Набор конечных точек зависит от устройства, но всякое устройство USB обязательно имеет двунаправленную конечную точку 0 (EP0), через которую осуществляется его общее управление. Для прикладных целей используются конечные точки с но$ мерами 1–15 (1–2 для низкоскоростных устройств). Адрес устройства, номер и на$ правление конечной точки однозначно идентифицируют приемник или источник информации при обмене хост$контроллера с устройствами USB. Каждая конеч$ ная точка имеет набор характеристик, описывающих поддерживаемый тип пере$ дачи данных (изохронные данные, массивы, прерывания, управляющие переда$ чи), размер пакета, требования к частоте обслуживания.

Устройство может выполнять несколько различных функциональных задач: на$ пример, привод CD$ROM может обеспечивать проигрывание аудиодисков и рабо$ тать как устройство хранения данных. Для решения каждой задачи в устройстве определяется интерфейс — набор конечных точек, предназначенных для выпол$ нения данной задачи, и правила их использования. Таким образом, каждое уст$ ройство должно обеспечивать один или несколько интерфейсов. Наличие несколь$ ких интерфейсов позволяет нескольким драйверам, каждый из которых обращается только к своему интерфейсу (представляющему часть устройства USB), работать с одним и тем же устройством USB. Каждый интерфейс может иметь один или несколько альтернативных вариантов (альтернативных установок — alternate settings), из которых в данный момент активным может быть только один. Вариан$ ты различаются наборами (возможно, и характеристиками) используемых конеч$ ных точек.

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

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

Модель передачи данных

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

Рис. 9.3. Отношения клиентского ПО (CSw) с интерфейсами устройств USB

Запросы, пакеты и транзакции

Для передачи или приема данных клиентское ПО посылает к каналу пакет запро са ввода/вывода — IRP (Input/Output Request Packet) и ждет уведомления о за$ вершении его отработки. Формат IRP определяется реализацией драйвера USBD в конкретной ОС. В IRP имеются только сведения о запросе (местоположение бу$ фера передаваемых данных в оперативной памяти и длина передачи); от свойств конкретного текущего подключения (скорость, допустимый размер пакета) драй$ вер устройства абстрагируется. Отработкой запроса в виде транзакций на шине USB занимается драйвер USBD; при необходимости он разбивает на части длин$ ные запросы (пакеты), пригодные для передачи за одну транзакцию. Транзакция

на шине USB — это последовательность обмена пакетами между хостом и ПУ, в ходе которой может быть передан или принят один пакет данных (возможны транзак$ ции, в которых данные не передаются). Отработка запроса считается завершен$ ной, когда успешно выполняются все связанные с ним транзакции. «Временные трудности», встречающиеся при их выполнении (неготовность к обмену данны$ ми), до сведения клиентского драйвера не доводятся — ему остается только ждать завершения обменов (или выхода по тайм$ауту). Однако устройство может сигна$ лизировать о серьезных ошибках (ответом STALL), что приводит к аварийному завершению запроса, о чем уведомляется клиентский драйвер. В этом случае от$ брасываются и все последующие запросы к данному каналу. Возобновление рабо$ ты с данным каналом возможно лишь после явного уведомления об обработке ошибочной ситуации, которое драйвер устройства делает с помощью специально$ го запроса (тоже вызова USBD).

Длинные запросы разбиваются на транзакции так, чтобы использовать максималь$ ный размер пакета. Последний пакет с остатком может оказаться короче макси$ мального размера. Хост$контроллер имеет средства обнаружения приема от уст$ ройства «неполновесного» пакета, размер которого меньше ожидаемого. В запросе IRP указывается, следует ли особым образом реагировать на это событие. Особая реакция может быть двоякой:

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

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

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

Каналы

Коммуникационные каналы USB разделяются на два типа:

потоковый канал (streaming pipe) доставляет данные от одного конца канала к другому, он всегда однонаправленный. Один и тот же номер конечной точки может использоваться для двух разных потоковых каналов — ввода и вывода. Передачи данных в разных потоковых каналах друг с другом не синхронизиро ваны. Это означает, что запросы клиентских драйверов для разных каналов, по$ ставленные в определенном порядке друг относительно друга, могут выполнять$ ся другом порядке. Запросы для одного канала будут исполняться строго в порядке их поступления; если во время исполнения какого$либо запроса происходит серьезная ошибка (об этом устройство сообщает ответом STALL), поток оста$ навливается. Поток может реализовывать передачи массивов, изохронные и пре$ рывания. Потоки несут данные произвольного формата, определенного разра$

ботчиком устройства (но не спецификацией USB). В потоках типично исполь$ зование транзакций, в которых длина поля данных соответствует максималь$ ному размеру, допустимому для его конечной точки. Если требуется разделение потока на логические блоки данных, то это можно сделать, применяя в качестве признака конца блока укороченные пакеты. Если оказывается, что блок укла$ дывается в целое число пакетов максимального размера, в качестве разделите$ ля можно использовать пакеты с нулевой длиной поля данных;

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

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

Каналы различаются и по назначению:

основной канал сообщений (Default pipe, он же Control pipe 0), владельцем кото$ рого является USBD, используется для доступа к конфигурационной инфор$ мации всех устройств. Этот канал устанавливается с нулевой конечной точкой, EP0 (endpoint zero), которая у всех устройств всегда поддерживает только уп$ равляющие передачи;

клиентские каналы (Client pipes), владельцами которых являются драйверы устройств. По этим каналам могут передаваться как потоки, так и сообщения; они поддерживают любые типы передач USB (изохронные, прерывания, мас$ сивы и управление).

Интерфейс устройства, с которым работает клиентский драйвер, представляет собой связку клиентских каналов (pipe’s bundle). Для этих каналов драйверы уст$ ройств являются единственными источниками и потребителями передаваемых данных.

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

ются три признака в формате регистра состояния LPT$порта: ошибка ввода/выво да, принтер выбран, отсутствие бумаги).

Кадры и микрокадры

Хост организует обмены с устройствами согласно своему плану распределения ресурсов. Для этого хост$контроллер циклически с периодом 1 мс формирует кад ры (frames), в которые укладываются все запланированные транзакции (рис. 9.4). Каждый кадр начинается с посылки пакета$маркера SOF (Start Of Frame), кото$ рый является синхронизирующим сигналом для изохронных устройств, а также для хабов. Кадры нумеруются последовательно, в маркере SOF передаются 11 млад$ ших бит номера кадра. В режиме HS каждый кадр делится на 8 микрокадров, и па$ кеты SOF передаются в начале каждого микрокадра (с периодом 125 мкс). При этом во всех восьми микрокадрах SOF несет один и тот же номер кадра; новое зна$ чение номера кадра передается в нулевом микрокадре. В каждом микрокадре мо$ жет быть выполнено несколько транзакций, их допустимое число зависит от ско$ рости, длины поля данных каждой из них, а также от задержек, вносимых кабелями, хабами и устройствами. Все транзакции кадров должны быть завершены до нача$ ла интервала времени EOF (End of Frame). Период (частота) генерации микрокад$ ров может немного варьироваться с помощью специального регистра хост$контрол$ лера, что позволяет подстраивать частоту для изохронных передач (см. главы 11 и 15).

Рис. 9.4. Кадры шины USB

Кадрирование используется и для обеспечения живучести шины. В конце каждо$ го микрокадра выделяется интервал времени EOF (End Of Frame), на время кото$ рого хабы запрещают передачу по направлению к контроллеру. Если хаб обнару$ жит, что с какого$то порта в это время ведется передача данных (к хосту), этот порт отключается, изолируя «болтливое» устройство, о чем информируется USBD.

Счетчик микрокадров в хост$контроллере используется как источник индекса при обращении к таблице дескрипторов кадров. Обычно драйвер USB составляет таб$ лицу дескрипторов для 1024 последовательных кадров1, к которой он обращается циклически. С помощью этих дескрипторов хост планирует загрузку кадров так, чтобы кроме запланированных изохронных транзакций и прерываний в них все$ гда находилось место для транзакций управления. Свободное время кадров может заполняться передачами массивов. Спецификация USB позволяет занимать под периодические транзакции (изохронные и прерывания) до 90% пропускной спо$ собности шины, то есть времени в каждом микрокадре.

1 Подробнее планирование для UHC, OHC и EHC описано в главе 15.

Протокол шины USB

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

Транзакции и пакеты

Все транзакции (обмены) с устройствами USB состоят из двух$трех пакетов, ти$ повые последовательности пакетов в транзакциях приведены на рис. 10.1. Каждая транзакция планируется и начинается по инициативе хост$контроллера, который посылает пакет маркер транзакции (token packet). Маркер транзакции описыва$ ет тип и направление передачи, адрес выбранного устройства USB и номер конеч$ ной точки. Адресуемое маркером устройство распознает свой адрес и готовится к обмену. Источник данных, определенный маркером, передает пакет данных. На этом этапе транзакции, относящиеся к изохронным передачам, завершаются — здесь нет подтверждения приема пакетов. Для остальных типов передач работает меха$ низм подтверждения, обеспечивающий гарантированную доставку данных. Фор$ маты пакетов приведены на рис. 10.2, типы пакетов — в табл. 10.1. Во всех полях пакетов, кроме поля CRC, данные передаются младшим битом вперед (на времен$ ных диаграммах младший бит изображается слева). Пакет начинается с синхро$

Рис. 10.1. Последовательность пакетов в транзакциях на шине USB: а — вывод; б — ввод данных

последовательности Sync и завершается признаком конца — EOP. Тип пакета опре$ деляется полем PID. Назначение остальных полей раскрывается далее. Длина по$ лей Sync и EOP указана для передач на FS/LS, для высокоскоростных передач поле Sync удлинено до 32 битовых интервалов, а EOP до 8 (в пакетах SOF поле EOP имеет длину 40 бит, см. главу 12).

Рис. 10.2. Форматы пакетов USB: а — маркер; б — пакет данных; в — пакет квитирования

Таблица 10.1. Типы пакетов и их идентификаторы PID

Имя	Код PID	Содержимое и назначение
Пакеты маркеры (Token)
OUT	0001	Маркер транзакции вывода, несет идентификатор конечной точки
		(адрес устройства и номер точки; направление точки определяется
		кодом PID)
IN	1001	Маркер транзакции ввода, несет идентификатор конечной точки
		(адрес устройства и номер точки; направление точки определяется
		кодом PID)
SETUP	1101	Маркер транзакции управления, несет идентификатор конечной точки
		(адрес устройства и номер точки)
SOF	0101	Маркер начала микрокадра, несет 11 битный номер кадра (вместо
		полей Addr и EndP)
PING	0100	Пробный маркер управления потоком (в USB 2.0)
Пакеты данных
DATA0	0011	Пакеты данных; чередование PID позволяет различать четные
DATA1	1011	и нечетные пакеты для контроля правильности подтверждения
DATA2	0111	Дополнительные типы пакетов данных, используемые в транзакциях
MDATA	1111	с широкополосными изохронными точками (в USB 2.0 для HS)
Пакеты квитирования (Handshake)
ACK	0010	Подтверждение безошибочного приема пакета
NAK	1010	Индикация занятости (неготовности конечной точки к обмену данными,
		незавершенности обработки транзакции управления)
STALL	1110	Конечная точка требует вмешательства хоста
NYET	0110	Подтверждение безошибочного приема, но указание на отсутствие
		места для приема следующего пакета максимального размера
		(в USB 2.0)
Специальные пакеты (Special)
PRE	1100	Преамбула (маркер) передачи на низкой скорости (разрешает
		трансляцию данных на низкоскоростной порт хаба)

Имя	Код PID	Содержимое и назначение
ERR	1100	Сигнализация ошибки в расщепленной транзакции (в USB 2.0)
SPLIT	1000	Маркер расщепленной транзакции (в USB 2.0). В зависимости
(SS и CS)		от назначения обозначается как SS (маркер запуска) и CS (маркер
		завершения), назначение определяется битом SC в теле маркера

Контроль и обработка ошибок передачи

Все принимаемые пакеты проверяются на наличие ошибок, что позволяют приня$ тые форматы пакета и некоторые соглашения:

пакет начинается с синхронизирующей последовательности, за которой следу$ ет его идентификатор PID (Packet Identificator). За идентификатором следует его инверсная копия — Check. Несовпадение двух копий считается признаком ошибки;

тело пакета (все поля пакета, исключая PID и признак EOP) защищается CRC$ кодом: 5$битным для пакетов$маркеров, 16$битным — для пакетов данных. Не$ совпадение CRC с ожидаемым значением считается признаком ошибки;

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

на физический уровень (в шину) данные пакета передаются с использованием вставки бит (bit stuffing, после шести единичных бит вставляется нолик), что предотвращает потерю битовой синхронизации при монотонном сигнале. При$ ем более шести единичных бит подряд считается ошибкой (на HS — признаком конца кадра).

Обнаружение любой из перечисленных ошибок в пакете заставляет приемник счи$ тать его недействительным. На пакеты, принятые с ошибкой, ни устройство, ни хост$контроллер никак не отвечают. При изохронной передаче данные недействи$ тельного пакета должны просто игнорироваться (они теряются); для остальных типов передач используются средства обеспечения надежной доставки.

Для обнаружения отсутствия ответа партнера на пакет каждое устройство имеет счетчик тайм аута, который прерывает ожидание ответа по истечении некоторо$ го времени. В USB имеется ограничение на время оборота по шине (roundtrip time): время от конца EOP сформированного пакета до получения начала ответного паке$ та. Для конечного устройства (и хост$контроллера) нормируется максимальная задержка ответа (response time) от конца увиденного EOP до введения им начала пакета. Для хабов нормируется задержка трансляции пакетов, для кабелей — за$ держка распространения сигналов. Счетчик тайм$аута должен учитывать макси$ мальную задержку, возможную для допустимой конфигурации шины: до 5 проме$ жуточных хабов, до 5 метров каждый кабель. Допустимое значение тайм$аута, выражаемое в битовых интервалах (bt), зависит от скорости: