link980 link981 link982 link983 link984 link985 link986 link987 link988 link989 link990 link991 link992 link993 link994 link995 link996 link997 link998 link999 link1000 link1001 link1002 link1003 link1004 link1005 link1006 link1007 link1008 link1009 link1010 link1011 link1012 link1013 link1014 link1015 link1016 link1017 link1018 link1019 link1020 link1021 link1022 link1023 link1024 link1025 link1026 link1027 link1028 link1029 link1030 link1031 link1032 link1033 link1034 link1035 link1036 link1037 link1038 link1039 link1040 link1041 link1042 link1043 link1044 link1045 link1046 link1047 link1048 link1049 link1050 link1051 link1052 link1053 link1054 link1055 link1056 link1057 link1058 link1059 link1060 link1061 link1062 link1063 link1064 link1065 link1066 link1067 link1068 link1069 link1070 link1071 link1072 link1073 link1074 link1075 link1076 link1077 link1078 link1079 link1080 link1081 link1082 link1083 link1084 link1085 link1086 link1087 link1088 link1089 link1090 link1091 link1092 link1093 link1094 link1095 link1096 link1097 link1098 link1099 link1100 link1101 link1102 link1103 link1104 link1105 link1106 link1107 link1108 link1109 link1110 link1111 link1112 link1113 link1114 link1115 link1116 link1117

PersCom — Компьютерная Энциклопедия Компьютерная Энциклопедия

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 (за него отвечает разработчик ОС), на момент написания книги автором не выяснена.