USB

Разрешение проблем при подключении устройств

Подробности

Родительская категория: USB

Категория: Применение шины USB

Все спецификации USB разрабатывались (и разрабатываются) в расчете на полную поддержку Plug and Play и «горячего» подключения-отключения устройств. При этом в идеальном варианте с пользователя снимаются все заботы по конфигурированию подключаемых устройств и установке его программного обеспечения. Однако на практике процесс подключения нового устройства происходит не всегда в таком «безоблачном» варианте. Проблемы, с которыми сталкиваются пользователи готовых устройств, как правило, сводятся к поиску подходящих драйверов и прикладного ПО. Конечно же, не надо забывать и о таких простых неполадках, как случайное отключение (опциями CMOS Setup) контроллера USB, находящегося на системной плате, а также ошибок подключения дополнительных разъемов USB.

В ОС Windows каждое подключенное устройство USB отображается в Диспетчере устройств (Device Manager). Для наглядности удобно в меню Вид выбрать опцию Устройства по подключению, тогда устройства будут отображаться в виде деревьев, «растущих» из шины PCI. Каждое дерево начинается со своего хост-контроллера, к которому подключен корневой концентратор (Root Hub). Заметим, что для каждого дерева (то есть для каждого хост-контроллера) адреса устройств USB назначаются независимо. К сожалению (но для удобства пользователя), диспетчер устройств Windows отображает только подключенные устройства и не отображает свободных портов хабов. Это усложняет понимание организации портов и контроллеров. Более информативна утилита USB View (от Microsoft), которая подробнее отображает дерево устройств (хост-контроллеры, корневые хабы, промежуточные хабы и конечные устройства). Для каждого элемента отображаются дескрипторы устройств, их конечных точек, а также состояние подключения:

• номер выбранной конфигурации (Current Config Value);
• скорость работы (Device Bus Speed);
• адрес устройства (Device Address);
• число открытых каналов (Open Pipes, не считая основного канала сообщений);
• cостояние подключения (ConnectionStatus).

Для хабов в дереве отображаются ветки, соответствующие всем имеющимся его портам. Это позволяет определить внутреннюю структуру хост-части системы. Так, например, можно увидеть в компьютере с шестью портами USB и провозглашенной поддержкой USB 2.0 «Расширенный хост-контроллер USB 2.0» (EHC) c шестипортовым корневым хабом и три «Универсальных хост-контроллера USB», у каждого из которых имеется по двухпортовому корневому хабу. В этом случае HSустройство можно подключать к любому порту и оно маршрутизирующей логикой будет связано с контроллером EHC. Для устройств FS и LS каждая пара портов подключается к своему контроллеру-компаньону (UHC). В такой системе можно говорить о суммарной пропускной способности шины USB, равной 480 + 3×12 = 516 Мбит/с. Правда, из этого следует вычесть накладные расходы и не забывать о возможных ограничениях со стороны шины PCI, к которой подключены хост-контроллеры, и со стороны контроллера системной памяти, которой контроллеры пользуются очень активно. Если бы мы в шестипортовой системе увидели расширенный контроллер с четырехпортовым корневым хабом, это означало бы, что поддержка USB 2.0 имеется только на четырех портах из шести.

Еще более развернутую информацию об устройствах USB дают утилиты, поставляемые для разработчиков производителями микросхем USB. Примером может быть утилита USB Monitor от Cypress Semiconductors, позволяющая прочитать все дескрипторы, имеющиеся у устройства USB.

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

• «Запитано» (Powered State);
• «Дежурное» состояние (Default State);
• «Адресовано» (Addressed State);
• «Сконфигурировано» (Configured State).

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

Если устройство при подключении «зависает» в состоянии «запитано», это может быть вызвано рядом причин:

• хост не получает сигнала о подключении устройства. Следует проверить наличие высокого логического уровня на линии D+ (для FS/HS-устройства) или D(для LS-устройства), который должно обеспечить устройство. Этот сигнал может не дойти до хоста при неплотном соединении разъема USB (в нем сигнальные цепи замыкаются позже питающих);
• хост не реагирует на сигнал подключения. Нормально хост реагирует посылкой сигнала шинного сброса — занулением линии D+ или D- на 10–20 мс, этот импульс легко можно увидеть с помощью осциллографа. «Заснувший» хост может и не реагировать на подключение (не посылать сигнал сброса). Доводилось наблюдать, как хост с ОС UNIX перестает реагировать на подключение LS-устройства (даже стандартной мыши) после многократных (с интервалом в несколько секунд) подключений/отключений его к одному и тому же порту корневого хаба. После этого подключение того же устройства к другому порту воспринимается нормально. Более того, последующее подключение этого устройства к порту, на котором реакция на подключение прекращалась, снова воспринимается нормально;
• устройство не реагирует на сигнал шинного сброса. Нормально устройство должно по сигналу шинного сброса перейти в «дежурное» состояние. Если устройство «зависает» в «дежурном» состоянии, это означает его неспособность сообщить дескрипторы и исполнить запрос назначения уникального адреса. Здесь определить неисправность несколько сложнее, поскольку требуется просмотреть пакеты запросов, принимаемые и передаваемые устройством. Причины некорректного обмена пакетами могут быть как в электронике, так и в микропрограммном обеспечении (firmware). В электронной части, например, может быть неправильная частота генератора, синхронизирующего SIE контроллера устройства USB, или неисправности в сигнальных цепях. В микропрограммном обеспечении следует проверить дескрипторы, сообщаемые устройством.
  Зависание в состоянии «адресовано» может означать, что подключенным устройством никто в системе не заинтересовался и не пытается сконфигурировать. Это происходит, например, когда ОС не может связать с обнаруженным устройством подходящий драйвер. Обнаруженное устройство идентифицируется кодами VID (код производителя) и PID (код продукта) в своих дескрипторах. Также это может происходить в случае подключения HS-устройства, критичного к скорости передачи, к FS-порту.
  В поддержке устройств USB, по крайней мере в ОС Windows, наблюдается странность (с точки зрения автора) в учете устройств. Каждое вновь подключенное устройство после установки его ПО поддержки оставляет в реестре Windows запись, в которой некоторый идентификатор устройства связывается с именами модулей ПО, его поддерживающих. Странность заключается в том, что вместе с такими бесспорными идентификаторами устройства, как VID и PID, в реестре фиксируется и номер порта. Если то же устройство переключить в другой порт, то ОС это воспримет как подключение нового(!) устройства и снова начнет установку ПО поддержки, создавая и новую запись в реестре. Отключение устройства не вызывает удаления записи из реестра, так что реестр будет «обрастать» лишними записями. Само по себе это не так уж важно (вопрос о компактности записей, похоже, давно уже решен в пользу лени), но ПО некоторых устройств отказывается загружаться (или работать), когда в реестре прописан его двойник с другим адресом. В этой ситуации приходится либо возвращать устройство в порт первоначального подключения (что не всегда удобно), либо вручную чистить реестр (что не к лицу рядовому пользователю). Вероятная причина этой странности — упрощение идентификации нескольких однотипных устройств, одновременно подключенных к компьютеру. Использование номера порта, который является сравнительно случайным (пользователь подключает устройство в первый попавшийся разъем), для идентификации устройства следовало бы заменить на уникальный идентификатор конкретного экземпляра устройства. Для этого спецификацией USB в дескрипторах устройства определены все необходимые элементы, включая строковый дескриптор с серийным номером. «Глубина залегания» этой странности — типовые драйверы устройств (подвластные их разработчикам) или системный драйвер USBD (за него отвечает разработчик ОС), на момент написания книги автором не выяснена.

• < Назад