Контроллеры usb что это
USB-контроллер
USB-контроллер в составе платформы персонального компьютера обеспечивает коммуникацию с периферийными устройствами, подключенными к универсальной последовательной шине. USB-контроллер является интеллектуальным устройством, способным взаимодействовать с оперативной памятью в обход центрального процессора в режиме прямого доступа к памяти.
По способу интеграции контроллер для USB-шины может быть задействован в составе системной логики или в виде дискретного чипа как на самой на системной плате, так и на плате расширения. По способу подключения USB-контроллер может быть выполнен для PCI-шины, либо для шины PCI Express.
В рамках спецификации USB 1.1 существуют две реализации контроллера для USB-шины: UHCI (Universal Host Controller Interface, создан Intel для USB 1.0) и OHCI (Open Host Controller Interface), которые отличаются методом доступа к регистрам. Регистры UHCI находятся в пространстве портов ввода-вывода, а регистры OHCI адресуются в пространстве памяти. Контроллер OHCI более интеллектуален по сравнению с UHCI. Это касается его способности освободить центральный процессор от выполнения рутинных операций по передаче данных по USB-шине. Оба контроллера используют 32-х битную адресацию в пределах младших 4 Гб адресного пространства, ни один из них не поддерживает 64-битный режим адресации.
Для USB 3.0 используется универсальный интерфейс XHCI (eXtensible Host Controller Interface), который поддерживает все скорости обмена данными. [2]
Универсальный USB-контроллер
Каждый современный пользователь компьютера знает, что такое USB-устройства хранения данных и периферия. Проблема в том, что далеко не все отдают себе отчет в том, как все это работает, полагая, что достаточно подключить устройство к соответствующему порту, и дело сделано (система-то подключенное устройство обычно определяет автоматически). За функционирование всех таких девайсов отвечают универсальный USB-контроллер и так называемая последовательная шина. Давайте с ним познакомимся.
Что такое контроллер универсальный последовательной шины USB (Windows 7)?
Само понятие контроллера этого типа, исходя из названия, подразумевает, что он, по идее, должен что-то контролировать. Но вот что?
Если говорить простым языком, USB-контроллер является неким мостом между самим устройством, последовательной шиной USB, к которой оно подключается, и системой, в которой оно будет использоваться. Но это только самое примитивное толкование.
Принципы работы
Сравнить принцип функционирования USB-контроллера в некотором смысле можно с операционной системой, которая обеспечивает взаимодействие между «железом» и программами.
Но только при рассмотрении текущего вопроса речь идет о взаимодействии подключаемой периферии или устройств хранения данных через интерфейс шины USB с оперативной памятью, минуя обращение к центральному процессору. Вследствие этого обеспечивается работоспособность любого типа устройств со средней и низкой скоростью передачи данных. Естественно, чтобы все работало, для контроллера, как и для всех остальных компонентов компьютерной системы, должна быть установлена специальная управляющая программа (драйвер), через которую система распознает устройство и обеспечивает его корректную работу.
Драйвер контроллера USB
В любой операционной системе Windows такие драйверы инсталлируются автоматически, поскольку являются универсальными.
Просмотреть сведения о самом USB-контроллере и установленном для него драйвере можно в «Диспетчере устройств», который вызывается либо из «Панели управления», либо из раздела администрирования компьютера, либо из консоли запуска программ «Выполнить» путем ввода строки devmgmt.msc.
Здесь имеется раздел контроллеров USB, развернув который, можно увидеть список установленных устройств. Сразу стоит обратить внимание на то, что их может быть несколько. При этом каждому отдельно взятому устройству может соответствовать четыре и более элементов: Generic USB Hub, корневой USB-концентратор, хост-контроллер для чипсета и составное устройство USB.
В этом списке нас больше интересуют первый и второй элементы, поскольку именно они могут вызывать ошибки и неполадки в работе, причем даже в том случае, если с установленным драйвером все в порядке.
Возможные проблемы в работе
Одной из главных причин, когда не работают флешки, съемные USB-винчестеры, беспроводные клавиатуры и мыши, можно назвать именно проблему с драйвером. При его отсутствии, некорректной установке или устаревании контроллер USB Windows 7, равно как любая другая операционная система, просто не распознает.
Иногда может наблюдаться ситуация, когда включена экономия энергии, и в такие моменты сам контролер системой отключается как устройство, неоправданно ее потребляющее.
Для таких сбоев решения по устранению неполадок есть, но, если внешние устройства не работают по причине повреждения USB-порта, тут ничего не поделаешь. Порт придется либо чинить, либо менять.
Методика устранения неисправностей
Определить, что виной того, что подключаемые устройства не работают, является именно USB-контроллер, можно непосредственно в «Диспетчере задач». В этом случае он будет помечен желтым маркером.
В свойствах можно посмотреть код ошибки и определить причину сбоя. Например, сбой под номером 28 соответствует тому, что отсутствует или неправильно установлен драйвер, код 43 свидетельствует о поломках физического характера USB-порта и т. д.
В этом случае первым делом нужно попытаться переустановить драйвер, используя базу данных Windows на локальном компьютере. Если это не поможет, драйвер можно удалить, после чего переустановка произойдет автоматически. Наконец, можно удалить и само устройство. Система определит его заново и инсталлирует необходимые для его работы компоненты.
В случае если и это эффекта не возымеет, придется в разделе свойств на вкладке сведений для двух вторых устройств, упомянутых выше, выставить отображение ИД-оборудования и по самым длинным строкам с идентификаторами VEN и DEV найти в интернете соответствующий драйвер, скачать его, а затем указать системе при установке его местоположение на жестком диске или инсталлировать его самому в ручном режиме.
Но что делать, когда в свойствах система пишет, что устройство работает нормально, а вот подключаемые накопители и периферия функционировать отказываются напрочь? По всей видимости, проблема состоит в отключении электропитания для экономии.
Помните, обращалось внимание на два первых компонента? Для них в «Диспетчере устройств» нужно вызвать меню свойств и на вкладке управления электропитанием снять флажок со строки отключения для экономии энергии, расположенной сверху.
Кроме того, следует зайти в раздел установки схем электропитания, вызвать настройку дополнительных параметров и в строке параметров USB установить запрет на временное отключение (для ноутбуков будет две настройки: питание от сети и питание от батареи).
Вместо итога
Вот и все, что касается понятия контролера USB. Здесь специально не делался упор на техническую сторону вопроса его функционирования, поскольку сам процесс достаточно сложен.
А вот что касается возможных проблем в нарушении работы и появления непредвиденных сбоев, вышеописанные ситуации являются самыми распространенными, а предлагаемые решения практически в 99% случаев из ста позволяют устранить ошибки.
Напоследок можно дать небольшой, но дельный совет: при повторной установке или обновлении драйверов контроллера лучше всего использовать автоматизированные программы вроде Driver Booster, SlimDrivers или DriverPack Solution, способные находить на сайтах производителей оборудования и разработчиков программного обеспечения самые свежие драйверы и интегрировать их в систему без участия пользователя как такового.
Популярно о USB. Часть 1
Немоляев А. В, г. Екатеринбург
Введение
У меня возникла необходимость разобраться с USB и, к своему удивлению, я обнаружил, что материалов по USB на русском языке не так уж много. Решил обобщить свой опыт изучения USB и передать всем желающим с ним познакомиться.
Публикация адресована начинающим разработчикам, тем, кто не знаком с USB, но хотел бы узнать больше. Статья носит учебный характер, и не является исчерпывающим справочным пособием. Для более простого вхождения в тему примеры основаны на стандарте USB 1.1. Если не сказано отдельно, то подразумевается режим FS (Full speed). В статье нет широко освещенных в других источниках сведений об общей топологии USB, о кабелях, хабах и разъемах. Здесь больше информации о том, что нужно знать разработчику устройств с микроконтроллерами о протоколе USB для своих разработок. Для устройств USB подключаемых к PC, таких, как мышь, клавиатура, микроконтроллер с поддержкой шины USB, использую термин USB-устройство. Персональный компьютер, к которому подключается USB-устройство, называю хостом. Доступное изложение теории, будет сопровождаться примерами программ на языке С для микроконтроллера AT90USB162 из популярной линейки megaAVR фирмы Atmel. В качестве источника справочной информации по USB рекомендую книгу Гук М. Ю. «Шины PCI, USB и FireWire. Энциклопедия», издательство «Питер».
Обзор темы
Программное обеспечение хоста делится на два отдельных типа: программное обеспечение инициализации канала связи и программное обеспечение поддержки рабочего режима обмена данными. Программное обеспечение инициализации начинает работать при подключении к хосту нового USB-устройства. Происходит обмен служебной информацией между хостом и USB-устройством. В результате обменов служебной информацией, хост определяет: тип устройства, его требования к энергопотреблению, возможность поддержки «спящего режима», тип драйверов для правильной работы USB-устройства, и, даже, возможна ли загрузка необходимых прикладных программ для работы с USB-устройством. Это новые веяния в духе спецификации PNP (plug and play). Устройства могут подключаться и отключаться в горячем режиме. При подключении и отключении происходит автоматическое переконфигурирование программного обеспечения хоста. Процесс настройки хоста на обмен данными, напоминает процесс раскрутки. Первоначально обмениваются простейшими сигналами по шине, затем процесс усложняется и, наконец, выход на рабочий режим.
Программное обеспечение рабочего режима поддерживает обмен данными, когда хост соответственно сконфигурирован, и USB-устройство вышло на рабочий режим обмена. В спецификации USB этот начальный процесс называется энумерацией.
В последнее время имеется тенденция к унификации не только протоколов обмена, но и устройств, взаимодействующих с персональным компьютером. Точнее, унификация требований к каналу связи. Идея такая. Придумывается универсальная шина для всего, что только можно подключить. Конечно, эта шина устроена сложно, она многоуровневая, гибкая и адаптируемая для разных конфигураций устройств. Унифицируются и драйверы операционной системы персонального компьютера, который взаимодействует с подключаемым устройством. Преимущество – отпадает необходимость в написании драйвера для ОС разработчиками USB-устройства. Это должно повышать надежность ОС, так как созданием драйверов могут заняться разработчики ОС, а не разработчики устройств. В общем, все плюсы унификации и стандартизации. Но есть и минусы. Очевидная сложность и связанная с ней избыточность, громоздкость технических решений. Тот же подход, что и в протоколах коммуникаций на большие расстояния. Академический стек протоколов OSI и знаменитый TCP/IP.
В связи с вышесказанным, в спецификации USB вводится понятие класса устройств. Все электронные устройства, подключаемые к персональному компьютеру, по своим функциональным качествам очень схожи. Например, звуковые платы предоставляют сервис приблизительно одного уровня. Поэтому устройства стали делить на унифицированные классы. Класс – это группа устройств, объединенных общими характеристиками и способных управляться общим для них программным драйвером операционной системы. Отдельное устройство может объединять функциональность сразу нескольких устройств, принадлежащих к разным классам. Если функциональность вашего устройства подходит к некоторому классу, и оно поддерживает спецификацию USB для устройств класса, то не нужно писать драйвер для ОС. Вероятнее всего, драйвер уже имеется в ОС. Функциональность устройства, подпадающего под определенный класс, может быть расширена разработчиком устройства добавлением отдельных команд. Точнее говоря, в стандарте USB предусмотрена возможность некоторого расширения функциональности. В стандарте предусмотрено множество возможностей, которые разработчик устройства может использовать для своих целей, добавляя к базовой функциональности функциональность расширенную. В спецификации USB есть две большие области, это собственно USB базового уровня и протоколы устройств классов. Протоколы устройств классов – это некоторая надстройка над протоколами нижнего уровня. Логично сначала разобраться с базовыми принципами, а уж потом со всем остальным.
Виртуальные каналы и конечные точки
Все примеры в статье даются в среде операционной системы Linux. По моему субъективному мнению, для новичка разобраться в реализации USB для Windows труднее, чем для Linux. Приходится много перерабатывать информации, специфичной для Windows, и ни как не относящейся к стандарту USB. В Linux к пониманию существа дела можно добраться более коротким путем. Разобравшись с Linux, можно легко перейти и к Windows.
В режиме передачи данных, когда процесс конфигурирования (энумерации) уже закончился, между USB-устройством и хостом должны быть налажены мосты. Это некий набор виртуальных каналов, по которым идет обмен данными и служебной информацией. Англоязычный термин pipe – труба. Каналы разделяют единственную среду передачи, а потому они являются мультиплексированными и, соответственно, виртуальными. Можно провести аналогию с локальной сетью. Шина Ethernet одна, но соединений TCP может быть несколько. Но в TCP/IP соединения TCP могут возникать и завершаться много раз в процессе работы. В USB типы каналов и их количество фиксируются на стадии процесса энумерации.
В стандарте определяются четыре типа каналов: управляющие, по прерыванию, массивов данных и изохронные. Только управляющий канал является двунаправленным, остальные каналы могут быть только однонаправленными. Для двустороннего обмена требуется организация хотя бы трех каналов. Обязательный управляющий канал и по одному для каждого направления. В USB принято, что канал называется каналом ввода, если данные передаются в хост, и канал вывода, если из хоста. Применяя специальные приемы, можно использовать канал управления для передачи небольших объемов данных. Но это нестандартное использование канала, и применяется редко. Напоминаем, что все информационные обмены на шине, для всех видов каналов происходят под управлением хоста. Первым делом хост посылает запрос, а затем USB-устройство отвечает.
Управляющий канал используется для передачи команд протокола USB; передача данных с использованием канала управления не является стандартным использованием канала. Хотя можно приспособить канал управления для передачи данных прикладной программы. В каждом USB-устройстве должен быть хотя бы один управляющий канал.
Канал передачи по прерыванию используется для небольших объемов данных, но с гарантированными задержками. Хост опрашивает USB-устройство на предмет готовности порции данных, и если USB-устройство готово для обмена, то обмен происходит. Время реакции USB-устройства задается при конфигурировании и лежит в диапазоне от 1 до 255 мс. Так что, это не связано напрямую с прерываниями в общепринятом понимании. Один канал по прерыванию типа ввода, используется мышью USB (Рисунок 1). По каналу передаются клики и координаты указателя. В моей клавиатуре USB используются два канала по прерыванию и один канал управления.
Изохронные каналы – применяются для передачи потока данных, например аудио и видео. Характерной особенностью является отсутствие повторной передачи данных в случае ошибок. Поврежденные пакеты просто отбрасываются без запроса повторной передачи. Такая политика позволяет воспроизводить поток данных в реальном времени без временных задержек. С периодом в 1 миллисекунду хост запрашивает данные, и буфер USB-устройства передается на хост. В веб-камерах используются изохронные каналы.
Канал передачи массивов данных используется в типах устройств, не требующих временной привязки при передаче данных и оперативной реакции на внешние события. Принципиальное отличие от двух предыдущих типов каналов заключается в том, что временной интервал, по истечении которого данные будут доставлены, не гарантирован. В изохронном канале хост опрашивает устройство с периодичностью 1 мс. В канале передачи по прерыванию хост может опрашивать USB-устройство с периодом от 1 до 255 миллисекунд. В канале передачи массивов хост начинает запрашивать данные для приема в свободное от всех остальных передач время. В случае искажения данных при передаче происходит повторная передача искаженных данных. В моей флэшке используются два канала передачи массивов данных: один на передачу и один на прием, не считая канала управления.
У USB-устройства приемником и передатчиком данных служит буфер, который называется конечной точкой. Тип конечной точки определяет тип канала, который связывает ее с хостом. Например, контроллер USB микроконтроллера AT90USB162 фирмы Atmel имеет в общей сложности 4 конечных точки, не считая конечной точки управления (из 4 возможных буферов обмена). Программа микроконтроллера должна, соответственно, сконфигурировать необходимое количество конечных точек для своих нужд. Все конечные точки контроллера USB перенумерованы. Нулевая конечная точка всегда используется для нужд канала управления и не может быть переконфигурирована для других целей. Если не создается драйвер ОС, то на стороне хоста расположение буфера знать необязательно, так как взаимодействие программы на стороне хоста с USB-устройством происходит через системные вызовы операционной системы и скрыто от пользовательской программы.
Хабы, адреса, хост контроллеры
Кратко опишем аппаратуру хоста. На стороне хоста обязательно должен присутствовать хотя бы один контроллер хоста и связанный с этим контроллером корневой хаб. В современных PC имеется несколько контроллеров хоста и, соответственно, несколько корневых хабов. Основателем каждой шины USB является корневой хаб, поэтому, если на PC несколько корневых хабов, то и несколько шин. В Linux имеющиеся шины USB можно посмотреть с помощью команды lsusb. Ниже приведен дамп вывода на моем компьютере:
В колонке слева перенумерованы имеющиеся в компьютере шины USB, а, значит, и контроллеры хабов и корневые хабы. Каждое USB-устройство на шине имеет уникальный адрес в диапазоне от 1 до 127. Нулевой адрес выполняет служебные функции, и не может быть назначен USB-устройству постоянно. Адреса распределяются по USB-устройствам хостом в процессе энумерации и сохраняются на все время работы устройства на шине. Из работы программы lsusb видно, что мышь USB подключена к шине 03, и на этой шине ей назначен адрес 02. Устройство хранения данных подключено к шине 01 с адресом 03. Можно поиграть, поменять последовательность включения и посмотреть, как это отразится на выводе lsusb. В следующей колонке указан идентификационный код устройства ID. Этот код состоит из 2 частей: идентификатора изготовителя (vendor ID) и идентификатора изделия (product ID). Они представляют собой два уникальных числа, используемых для идентификации конкретного устройства. Операционная система по этим кодам может определять, какой драйвер требуется загрузить для работы. Значение кода изготовителя назначается форумом разработчиков USB по заказу фирмы. Код устройства устанавливает сам производитель. Программист микроконтроллеров может задать эти числа произвольно. Другое дело, что такие устройства, поступившие в широкую продажу, могут вызвать возражения фирмы собственника кода. Кроме этих чисел, для идентификации можно использовать номер версии устройства (ID Device).
Архитектура ЭВМ
Компоненты ПК
Интерфейсы
Мини блог
Самое читаемое
Станок пристрелочный 51 купить www.huntmania.ru. Организация праздника на катере. Корпоративные праздники http://www.oldclub.ru.
Хост USB
Общая информация о хосте USB
Хост является главным действующим лицом в организации конфигурирования и выполнения транзакций USB. У каждой шины USB должен быть один (и только один!) хост — компьютер с контроллером USB. Однако понятие компьютер отнюдь не означает лишь привычные варианты настольных, напольных, портативных компьютеров. Компьютер — это сочетание процессора, памяти и периферийных устройств; в таком понимании в большинстве современных устройств присутствуют встроенные компьютеры. Если «интеллекта» этого компьютера и его возможностей диалога с пользователем оказывается достаточно, то он может взять на себя роль хоста USB. Такой вариант хоста рассматривается в последнем параграфе данной главы.
«Классический» хост USB делится на три основных уровня:
В совокупности уровни хоста предоставляют следующие возможности:
Программная часть хоста в полном объеме реализуется операционной системой. До загрузки ОС может функционировать лишь усеченная часть ПО USB, поддерживающая только устройства, требующиеся для загрузки. Так, в BIOS современных системных плат имеется поддержка клавиатуры USB, реализующая функции сервиса Int 9h. После загрузки системы USB эта «дозагрузочная» поддержка игнорируется — система начинает работу с контроллером «с чистого листа», то есть со сброса и определения всех подключенных устройств. В спецификации PC’2001 выдвигается ряд требований к BIOS, в частности требование поддержки загрузки ОС с устройств USB.
Хост-контроллер
Хост-контроллер является аппаратным посредником между устройствами USB и хостом. В настоящее время имеется три спецификации хост-контроллеров, каждой из которых соответствует свой комплект драйверов хост-части:
Все эти варианты контроллеров выполняют одни и те же задачи: организуют физические транзакции с устройствами по шине USB в соответствии с описаниями (дескрипторами) этих транзакций, помещенными в системное ОЗУ драйвером хост-контроллера. При этом транзакции разных типов обрабатываются по-разному. В плане обработки ошибок проще всего устроены изохронные транзакции, где ошибки не требуют повторов. Транзакции передач с гарантированной доставкой в случае ошибок требуют повторов до победного конца или признания неудачи (исчерпания допустимого числа повторов). С точки зрения планирования следует выделить периодические транзакции, которые должны выполняться строго по графику, остальные — как получится, и их ставят в очереди. Из-за особенностей планирования и возможных повторов порядок завершения обработки дескрипторов транзакций (успешных или нет) будет отличаться от порядка их помещения в память1, что прибавляет забот хост-контроллеру и его драйверу. Три варианта хостконтроллеров решают эти задачи по-разному и используют разные стратегии планирования транзакций, что иллюстрирует таблицы ниже.
План распределения времени в кa)адре: a — UHC; б — OHC; в — EHC (в микрокадре)
| SOF | Изохронные транзакции | Транзакции прерываний | Транзакции управления | Транзакции передач массивов | Свободное время |
| SOF | Непереодические транзакции (Т1) | Переодические транзакции | Непереодические транзакци |
| SOF | Непереодические транзакци | Переодические транзакции |
«Универсальный» хост-контроллер — UHC
Хост-контроллер UHC от Intel появился в микросхеме PIIX3 (мост PCI-ISA) чипсетов системных плат для процессоров Pentium и используется во многих последующих изделиях Intel. Это FS/LS хост-контроллер, который большую часть забот по планированию транзакций перекладывает на ПО, — драйвер контроллера UHC (UHCD). Интерфейс контроллера UHC описан в документе Universal Host Controller Interface (UHCI) Design Guide, версия 1.1 вышла в 1996 году.
Драйвер UHC формирует для хост-контроллера дескрипторы, называемые в UHCI «дескрипторами передач» (TD — Transfer Descriptor), на самом деле описывающие каждую шинную транзакцию. Напомним, что в терминах спецификации USB одна передача (transfer) может состоять из нескольких транзакций, а в управляющих передачах используется еще и свой тип транзакции для каждой фазы. Для транзакций передач с гарантированной доставкой дескрипторы TD приходится организовывать в очереди. Очереди нужны для таких передач, поскольку заранее не известно, сколько раз придется пытаться их исполнить. Продвижение очереди возможно только по успешному выполнению транзакции, находящейся в голове очереди, — это правило обеспечивает гарантированный порядок (в пределах своей очереди) доставки пакетов. Каждая очередь имеет свой заголовок (QH). Изохронные передачи исполняются всегда однократно (здесь нет гарантированной доставки), что упрощает их планирование. Драйвер размещает дескрипторы TD и QH в памяти и связывает их между собой в соответствии с планом выполнения транзакций в каждом кадре. Драйверу UHC приходится составлять детальное «расписание» для каждого будущего кадра, для чего используется список Frame List на 1024 кадра. Хост-контроллер обходит списки дескрипторов, начиная с точки, на которую указывает Frame List для текущего кадра, и выполняет соответствующие транзакции. Результат исполнения транзакции помечается в ее дескрипторе, отработанная транзакция помечается как «неактивная», и контроллер, встретив ее при очередном обходе, просто переходит к следующей. Драйвер должен периодически просматривать дескрипторы, извлекая уже отработанные и передавая результаты выполнения клиентскому драйверу. Логика работы контроллера подразумевает, что одному запросу ввода/вывода (IRP) от клиентского драйвера может соответствовать несколько «передач» — элементов очереди. Драйвер UHC разбивает запрос на транзакции и помещает дескрипторы этих транзакций в соответствующую очередь, а очередь включает в ближайшие планы. Драйвер отвечает за балансировку загрузки шины в каждом кадре, в частности, за гарантию предоставления не менее 10% полосы для транзакций управляющих передач. Планированием кадров также обеспечивается требуемая частота обращений к точкам периодических передач.
Контроллер UHC является активным устройством PCI (Bus-Master). Основное взаимодействие драйвера с хост-контроллером происходит с помощью дескрипторов, расположенных в памяти. Контроллер имеет регистры (в пространстве ввода/вывода), с помощью которых можно управлять его поведением: выполнять сброс, глобальную приостановку и пробуждение, подстраивать частоту кадров, управлять запросами прерываний, управлять портами встроенного корневого хаба. Контроллер позволяет работать в отладочном режиме, останавливаясь после выполнения каждой транзакции.
В процессе отработки плана контроллер считывает из памяти дескрипторы и данные, необходимые для начала транзакции. Как только в FIFO-буфер контроллера из памяти поступает информация, достаточная для начала транзакции, контроллер начинает транзакцию на шине USB. В процессе ее исполнения производится передача данных, после завершения контроллер модифицирует дескрипторы в памяти в соответствии с условиями завершения транзакции. В процессе отработки транзакции могут возникать ошибки переполнения или переопустошения FIFO-буфера, связанные с перегрузкой контроллера системной памяти или шины PCI. Эти серьезные ошибки инициируют аппаратные прерывания. В состав хостконтроллера входит и корневой хаб на 2 или более порта.
Прерывания от UHC могут инициироваться различными событиями, такими как выполнение транзакций (избранных), обнаружение приема короткого пакета, прием сигнала возобновления, или в результате ошибки. Прерываний по подключению-отключению устройств контроллер не вырабатывает.
В контроллере UHC имеется специальная поддержка традиционного интерфейса клавиатуры и мыши через контроллер 8042 — перехват обращений к портам 60h и 64h пространства ввода/вывода. При разрешенной эмуляции по обращениям ПО к этим портам UHC вызывает системное прерывание SMI (System Management Interrupt), обрабатывающееся в ПК на процессорах x86 в режиме SMM (System Management Mode), невидимо для обычных программ. Обработчик SMI, перехватывающий эти обращения, формирует последовательности действий, необходимые для их исполнения с помощью клавиатуры и (или) мыши USB. Единственное исключение делается при перехвате команд, управляющих вентилем GateA20, — вместо генерации SMI манипуляции этим вентилем выполняются аппаратно (как это давно делается и в 8042). Эта аппаратная поддержка включается установкой соответствующих параметров CMOS Setup.
Большое неудобство работы с UHC возникает из-за необходимости программного просмотра всех дескрипторов передач на предмет выявления завершенных. Дескрипторы завершенных передач необходимо программно извлекать из цепочек, сохраняя связанность элементов. Планирование транзакций (составление списков дескрипторов и заголовков) — тоже достаточно трудоемкая задача для драйвера. Очевидно, преследовалась цель упрощения аппаратных средств хост-контроллера. Однако это может обернуться зависимостью эффективной производительности шины USB от мощности и загрузки центрального процессора. Такой подход к организации ввода/вывода трудно назвать эффективным.
Структуры данных и регистры контроллера UHC
Драйвер в системной памяти создает список кадров Frame List, состоящий из 1024 элементов. Каждый элемент этого списка содержит 32-битный указатель на связанный список структур данных, по которым контроллер выполняет транзакции в данном кадре. Хост-контроллер имеет регистр базового адреса списка кадров, указывающий на начало списка. Текущий номер отрабатываемого элемента определяется десятью младшими битами счетчика кадров, находящегося в контроллере и инкрементируемого каждую миллисекунду. Период счета кадров можно немного варьировать, изменяя константу, занесенную в регистр модификации длительности кадра (SOF Modify Register), что обеспечивает возможность подстройки частоты кадров для синхронизации изохронных обменов.
Элемент списка кадров может указывать либо на дескриптор изохронной передачи TD (Transfer Descriptor), либо (если в данном кадре изохронный обмен не планируется) на заголовок очереди QH (Queue Head). Если в данном кадре вообще не планируются передачи, то в элементе устанавливается признак-«заглушка» T (Terminate, конец связанного списка, в данном случае — пустого). Еще раз напомним, что здесь слово «передача» (Transfer, согласно спецификации UHCI) употребляется в узком смысле — она соответствует одной транзакции (передаче не более одного пакета данных). Элемент (32-битное слово) имеет формат, приведенный на рисунке ниже. Поле FLLP (Frame List Link Pointer) — указатель на элемент; бит T — признак последнего элемента (при T = 1 указатель FLLP недействителен). Бит Q задает класс связанного элемента, на который указывает FLLP (0 — TD, 1 — QH).
Для каждого кадра из списка устанавливается своя цепочка дескрипторов изохронных передач (возможно и пустая), последний из этой цепочки должен ссылаться на цепочку заголовков очередей. Цепочки заголовков QH могут быть общими для группы кадров или даже для всех кадров списка. Общая идея построения очередей состоит в том, чтобы создавать свою очередь для каждого установленного канала (для всех сконфигурированных точек, кроме изохронных). «Дежурный» метод обслуживания — по горизонтали, тогда после выполнения транзакции с одной точкой контроллер перейдет к другой точке (другой очереди). Связывание TD и QH через указатели позволяет формировать произвольные конфигурации переходов от одной очереди к другой и даже делать петли — в последнем случае возможно, что с одной точкой в кадре успеют пройти несколько транзакций. Однако это нетипичный способ планирования. Если очередей много (установлено много каналов), то они распределяются по кадрам (из 1024-элементного списка) так, чтобы цепочка каждого кадра обязательно прошла по горизонтали до конца. Это можно спланировать, поскольку максимальное время для отработки одного элемента каждой очереди (как и изохронных транзакций) заранее известно (оно определяется типом передачи, максимальным размером пакета и скоростью устройства, что известно системе USB). При необходимости «горизонтальную справедливость» можно нарушить, задав вертикальный порядок обслуживания, — контроллер, успешно обработав из очереди передачу с признаком V = 1, перейдет к следующему дескриптору из этой же очереди, а не к следующей очереди.
Дескрипторы передач и заголовки очередей размещаются драйвером в ОЗУ по адресам, выровненным по границе параграфа, поскольку в качестве указателей используются лишь старшие 28 бит (биты [3:0] используются для служебных признаков).
Дескриптор передачи (TD) состоит из 32 байтов, из которых хост-контроллер использует только первые четыре 32-битных слова DW0–DW3. Слова DW4–DW7 зарезервированы для использования драйвером UHC (для организации «сборки мусора» — повторного использования отработанных областей). Формат дескриптора передачи приведен на рисунке ниже. Серым цветом выделены поля, модифицируемые хост-контроллером.
В слове DW0 поле Link Pointer аналогично полю FLLP, а биты T и Q аналогичны одноименным битам элемента списка кадров. Бит V — метод обслуживания TD (1 — в глубину, 0 — в ширину).
Слово DW1 используется для управления и определения состояния выполнения передачи, модифицируется хост-контроллером. Поле ActLen — действительная длина переданных данных; поле Status — состояние выполнения передачи:
длина переданных данных; поле Status — состояние выполнения передачи:
Биты [24:31] используются для управления передачей. Бит IOC заказывает прерывание по исполнению (прерывание генерируется в конце кадра, даже если транзакция уже неактивна, выборка ее дескриптора вызовет прерывание). Бит ISO — признак изохронной передачи (указание не делать повторных попыток). Бит LS — признак LS-устройства, использовать преамбулу перед передачей. Поле C_ERR — счетчик повторных попыток, декрементируемый по каждой ошибке. Переход в 1 или 0 вызывает перевод дескриптора в неактивное состояние. Если драйвер устанавливает нулевое значение, то число повторов неограниченно. Бит SPD — детектор короткого пакета: если в транзакции IN, стоящей в очереди, успешно принято меньше данных, чем ожидалось, то в конце кадра вырабатывается условие прерывания.
В слове DW2 содержится информация для выполнения транзакции: Packet ID — тип используемого маркера IN (69h), OUT (E1h) или SETUP (2Dh); Device Address— адрес устройства USB; EndPt — номер и направление конечной точки. Бит D (Data Toggle) — состояние переключателя для передаваемого или посылаемого пакета. Поле MaxLength — длина передаваемых данных (максимальная длина принимаемых), 000 — 1 байт, 001 — 2, 3FF — 1024; 7FFh — 0 (пустой пакет). Допустимые значения до 4FFh — 1280 байт, теоретический предел емкости кадра. Значения 500–7FEh недопустимы, вызывают фатальную ошибку контроллера.
В слове DW3 содержится Buffer Pointer — указатель на буфер в ОЗУ, используемый для данных этой передачи.
Заголовок очереди (QH) связывает очереди друг с другом (по горизонтали) и ссылается на первый элемент (TD) данной очереди. Хост-контроллер использует два 32-битных слова (см. следующий рисунок). В поле QHLP (Queue Head Link Pointer) содержится указатель на следующий заголовок очереди (горизонтальная связка). В поле QELP (Queue Element Link Pointer) содержится указатель на элемент очереди (вертикальная связка). Признаки последнего элемента (T) и класс связанного элемента (Q) аналогичны одноименным признакам и классам в вышеприведенных структурах.
Дескриптор заголовка очереди создается драйвером; хост-контроллер модифицирует в памяти указатель QELP: успешно отработав транзакцию, контроллер берет из DW0 ее дескриптора указатель на следующий элемент и помещает его на место QELP в заголовке очереди. Таким образом, успешно отработанный TD удаляется из очереди. Когда удаляется последний TD, в QELP устанавливается признак пустой очереди (T). В случае неисправимой ошибки при отработке какого-то дескриптора в QELP также устанавливается «заглушка» T — поток с гарантированной доставкой не позволяет пропустить какую-либо транзакцию. Поле QELP может ссылаться как на TD (тривиальный вариант планирования), так и на QH — очередь сама может содержать очереди.
Регистровая модель UHC поясняется в таблице ниже, где представлены регистры, отображенные на пространство ввода/вывода. Кроме того, как всякое устройство PCI, контроллер UHC имеет регистры в конфигурационном пространстве, в которых, в частности, задаются коды класса (0Ch — контроллер последовательной шины), подкласса (03 — USB) и программного интерфейса (00) в классификации PCI SIG.
Таблица. Регистры контроллера UHC
USBCMD — регистр команд USB
Биты 15:8 — резерв
Бит 7: MAXP (Max Packet) — допустимый размер пакета (для FS), с которым
возможна транзакция при подходе к концу кадра: 1 = 64 байт, 0 = 32 байта
Бит 6: CF (Configure Flag) — флаг, которым драйвер отмечает окончание процесса
конфигурирования контроллера (программный семафор для ПО)
Бит 5: SWDBG (Software Debug) — управление отладкой: 1=режим отладки (останов
после каждой транзакции), 0 — нормальный
Бит 4: FGR (Force Global Resume) — подача сигнала глобального
пробуждения.Устанавливается программно, сбрасывается аппаратно по окончании
пробуждения
Бит 3: EGSM (Enter Global Suspend Mode) — перевод в режим глобальной
приостановки
Бит 2: GRESET (Global Reset) — общий сброс контроллера и шины USB
Бит 1: HCRESET (Host Controller Reset) — сброс хост-контроллера
Бит 0 RS (Run/Stop) управление работой контроллера: 1=Run — выполнение
транзакций по плану, 0=Stop — останов
USBSTS — регистр состояния USB
Биты [15:6] — резерв
Бит 5: HCHalted — контроллер остановлен, программно или аппаратно (по ошибке
или при отладке)
Бит 4: Host Controller Process Error — фатальная ошибка исполнения (может
возникать и из-за некорректного задания PID в дескрипторе транзакций), вызывает
прерывание
Бит 3: Host System Error — системная ошибка (неполадки в интерфейсе PCI),
вызывает прерывание
Бит 2: Resume Detect — получение сигнала возобновления (при глобальной
приостановке)
Бит 1: USB Error Interrupt — признак прерывания по ошибке выполнения
транзакции (переполнение или переопустошение FIFO буфера шины PCI)
Бит 0: USBINT (USB Interrupt) — прерывание по выполнению транзакции
с установленным битом IOC или приему короткого пакета (при включенном
обнаружении короткого пакета)
USBINTR — регистр разрешения прерываний
Биты [15:4] — резерв
Бит 3: Short Packet Interrupt Enable — разрешение прерываний по приему
короткого пакета
Бит 2: IOC (Interrupt On Complete Enable) — разрешение прерываний по завершении
транзакции
Бит 1: Resume Interrupt Enable — разрешение прерываний по приему сигнала
возобновления
Бит 0: Timeout/CRC Interrupt Enable — разрешение прерываний по ошибке
тайм-аута и CRC-контролю
SOFMOD — регистр управления частотой кадров
Биты [6:0] — управление длительностью кадра: 0 — 11936 бит, 1 — 11937 бит, …
63 — 11999 бит, 64 — 12000 бит (номинал), 65 — 12001 бит, 127 — 12063 бит
PORTSC1 — регистр управления и состояния порта 1
Биты [15:13] — резерв (0)
Бит 12: (R/W) Suspend — приостановка порта
Биты [11:10] — резерв (0)
Бит 9: (R/W) Port Reset — сброс порта
Бит 8: (RO) Low Speed Device Attached — признак подключения LS-устройства
Бит 7 — резерв (1)
Бит 6: (RW) Resume Detect — обнаружение сигнала возобновления. Запись «1»
вызывает генерацию сигнала возобновления на порте, последующая запись
«0» — завершение сигнала возобновления и посылка LS-EOP Биты [5:4]: (RO) —
текущее состояние линий D- и D+
Бит 3: (R/WC) Port Enable/Disable Change — признак автоматического запрета
порта по ошибке, сбрасывается записью «1»
Бит 2: (R/W) Port Enabled/Disabled — разрешение работы порта
Бит 1: (R/WC) Connect Status Change — признак события подключения/
отключения устройства
Бит 0: (RO) Current Connect Status — признак подключенного устройства
«Открытый» хост-контроллер — OHC
Спецификация интерфейса «открытого» хост-контроллера OpenHCI (OHCI) разработана компаниями Compaq, Microsoft и National Semiconductor и описана в документе «Open Host Controller Interface Specification for USB». Версия 1.0a этого документа опубликована в 1999 году. Контроллер OHC, как и UHC, предназначен для поддержки скоростей FS/LS. Однако аппаратные средства OHC берут на себя большую часть забот планирования, разгружая ЦП от рутины постоянной обработки дескрипторов. Контроллер OHC оперирует дескрипторами конечных точек и дескрипторами передач.
Дескрипторы конечных точек ED (Endpoint Descriptor) создаются для всех сконфигурированных конечных точек всех подключенных устройств. Эти дескрипторы размещаются в памяти и связываются между собой; конфигурация связей задает порядок их обслуживания хост-контроллером. Дескриптор конечной точки описывает ее полный адрес и направление, тип, допустимый размер пакета, скорость, состояние точки и дескриптора, указатели на очереди передач, связанных с данной точкой, указатель на дескриптор следующей точки. Для всех точек управления (Control) и всех точек передач массивов (Bulk) создаются отдельные цепочки ED, на начала этих цепочек указывают специальные регистры OHC. Дескрипторы точек периодических передач организуются в «поваленное» двоичное дерево (см. рисунок ниже), в «ветвях» которого размещаются дескрипторы точек прерываний, а в «стволе» — дескрипторы точек прерываний с минимальным интервалом обслуживания и все дескрипторы точек изохронных передач. У дерева имеются 32 конечных ветви, проход по дереву осуществляется от конечных ветвей к стволу. В каждом из 32 смежных кадров вход осуществляется со своей ветви. Для этого в OHC имеется регистр базового адреса HCCA (Host Controller Communication Area, область коммуникаций хост-контроллера), указывающий на ветвь с номером 0, и счетчик кадров, 5 младших бит которого задают номер ветви входа для очередного кадра. Таким образом, через каждую ветвь пятого уровня (конечного) обработчик дескрипторов проходит 1 раз за 32 кадра (T = 32 мс), четвертого — 1 раз за 16 кадров (T = 16 мс), для третьего уровня — T = 8 мс, для второго — T = 4 мс, для первого — T = 2 мс, для нулевого (ствола) — T = 1 мс.
Дескрипторы передач TD (Transfer Descriptor), в отличие от TD UHC, для OHC действительно описывают передачи USB. Каждая передача может разбиваться на несколько транзакций, и это разбиение выполняет хост-контроллер исходя из размера пакета, установленного в дескрипторе конечной точки. Буфер данных для передачи может располагаться в одной или двух физических страницах памяти, возможно, разрозненных. В виртуальном пространстве логических адресов буфер должен быть непрерывной областью. Размер передачи может достигать 8 Кбайт, но если буфер начинается не с начала страницы, то допустимый размер передачи сократится (в худшем случае до 4097 байт). Дескрипторы передач собираются в очереди, которые прикрепляются к дескрипторам конечных точек.
Хост-контроллер OHC имеет таймеры, с помощью которых он осуществляет планирование транзакций в кадре. После SOF контроллер начинает обход цепочки ED для управляющих передач и выполняет столько из них, сколько успеет за время T1. Далее он начинает обход дерева периодических передач, от n-й конечной ветви до ствола, пока не пройдет по всем встретившимся ED. Если у него еще остается время в кадре, он снова берется за непериодические передачи (Bulk и Control). Отработанные (успешно или снятые по превышению порога ошибок) дескрипторы контроллер собирает в специальную очередь обработанных дескрипторов Done Queue, откуда их без труда извлекает драйвер. Контроллер может вырабатывать прерывания по завершению обработки TD, причем с заданной (для каждого TD) задержкой (или не вырабатывать запрос). Контроллер OHC имеет регистр для подстройки частоты кадров. В контроллер входит и корневой хаб на 2 или более порта.
Контроллер OHC, как и UHC, обычно является активным устройством PCI (Bus Master), но по сравнению с UHC наделен большим интеллектом. В контроллере предусмотрена поддержка контроллера клавиатуры и мыши (KBC) с помощью прерываний SMI, но, в отличие от UHC, в OHC имеются и специальные регистры, упрощающие задачу эмуляции.