Usb hci что это
Обновлено: 03.07.2024
Архитектура USB неочевидна и для неподготовленных пользователей — нелогична. Режим обмена с пропускной способностью 480 Мбит/сек (High-Speed) обслуживается контроллером EHCI, низкоскоростные режимы Full-Speed и Low-Speed — либо контроллером OHCI (SiS, nVidia), либо UHCI (Intel, VIA). Они и спорят между собой за доступ к подключенному устройству.
В чем причина этого спора?
Вкратце суть ее состоит в том, что контроллер EHCI работает только с высокоскоростными устройствами, а низкоскоростные протоколы обмена по-прежнему обслуживаются контроллерами USB 1.1.
Как это происходит? На этапе подключения внешнего USB-устройства платформа не осведомлена о его скоростных характеристиках. Это означает, что по умолчанию используется порт контроллера USB 2.0, как лучший из возможных. После определения протокола обмена, выполняется коммутация низкоскоростных USB-девайсов на порты контроллеров-компаньонов, а высокоскоростные остаются в ведении EHCI.
Переподключение — технологический трюк в процессе обслуживания периферийного устройства, позволивший сохранить преемственность с USB 1.1. Для этого в контроллере USB 2.0 выделяется блок раутинга (Port Routing), в составе которого есть регистровые поля, декларирующие соответствие портов EHCI портам UHCI/OHCI, ответственные за управление программируемыми коммутаторами.
Преимущество совмещенной модели «EHCI+Companion Controllers» — возможность использования драйверов, написанных для UHCI и OHCI. Недостаток – функциональная избыточность и необходимость коммутации.
О терминологии
Условимся, что универсальную последовательную шину, соответствующую стандарту USB 1.1, поддерживающую Full-Speed и Low-Speed, и все что к ней относится, мы будем называть низкоскоростной. В отличие от высокоскоростной шины USB 2.0, поддерживающей High-Speed.
Устройства, обеспечивающие ветвление шины, далее по тексту называются концентраторами либо хабами. Аббревиатура HCI означает «хост контроллер интерфейс» и не требует дополнительных толкований, как и все ее реализации: OpenHCI (OHCI), UniversalHCI (UHCI), EnhancedHCI (EHCI) и даже xHCI (eXtensible Host Controller Interface).
Как бороться с излишествами, сохранив доброе имя?
Попросту говоря, можно ли отказаться от «старых» контроллеров типа OHCI/UHCI, обеспечив совместимость с USB 1.1 силами одного лишь ENCI? Однозначно — да. Ведь в EHCI еще с момента разработки был заложен механизм Split Transactions, позволяющий поддерживать протоколы взаимодействия с устройствами Low и Full-Speed, физически общаясь на High-Speed.
Почему это не было сделано сразу, в момент появления дванольного контроллера? Ответ прост: такое решение потребовало бы отказаться от доминирующей в то время архитектуры южного моста. Экономическая целесообразность, по всей видимости, наступила только с появлением одночиповой логики.
Как реализован механизм Split Transactions и в чем его суть?
Представьте ситуацию, когда на вышеописанной платформе в качестве периферийного устройства используется обыкновенный USB-концентратор, поддерживающий стандарт 2.0. Совершенно очевидно, что подключение этого устройства будет выполнено к контроллеру EHCI. А что будет, если к указанному хабу подсоединить низкоскоростную клавиатуру или адаптер USB-to-COM? Как изменится схема подключения? Не будет ли задействован механизм переподключения к OHCI/UHCI контроллерам? Кто станет обслуживать запросы от Low или Full-Speed периферии?
Ответом на все эти вопросы и является описание работы Split Transactions. Этот механизм позволяет обойти следующее противоречие: как обслужить High-Speed соединение, если взаимодействие с оконечным устройством происходит по протоколу Full или Low Speed? Решением является еще один USB-трюк, на сей раз связанный с логикой процесса, позволяющего разместить информацию о низкоскоростных транзакциях внутри High-Speed транзакций. В таком разе USB Hub 2.0 выступает посредником, общаясь с EHCI контроллером на High-Speed, как и положено высокоскоростному устройству, а с оконечным устройством — используя Low-Speed или Full-Speed (по ситуации).
Rate Matching Hub — «Калиф на час»
Как следует из сказанного, идея разместить концентратор с поддержкой High-Speed в составе контроллера USB давно витала в воздухе. В таком случае контроллеры-компаньоны не нужны, а структура USB заметно упрощается. Впервые такой хаб появился в составе Южного Моста набора логики Intel P55, который содержит два контроллера EHCI, при этом каждый из них снабжен своим RMH — Rate Matching Hub.
Короткое отступление. Использование интегрированного USB-хаба RMH не следует смешивать с неотъемлемой частью архитектуры универсальной последовательной шины — корневым USB-концентратором (Root Hub). RMH не заменяет Root Hub и не претендует ни на одну из его функций, являясь логическим продолжением хабовой USB-структуры.
Rate Matching Hub программно видится как USB-устройство с Vendor и Product Как и обычный концентратор внешнего подключения, он, в соответствии со спецификацией USB, содержит Hub Repeater, Hub Controller и Transaction Translator. Но в отличие от внешнего хаба, Rate Matching Hub физически находится в составе Южного Моста и по этой причине существует возможность дополнительного управления его функциями через конфигурационные регистры чипсета.
XHCI EHCI UHCI OHCI это интерфейсы USB-контроллера в составе платформы персонального компьютера, который обеспечивает коммуникацию с периферийными устройствами, подключенными к универсальной последовательной шине.
USB-контроллер является устройством, способным взаимодействовать с оперативной памятью в обход центрального процессора в режиме прямого доступа к памяти.
По способу интеграции контроллер для USB-шины может быть задействован в составе системной логики или в виде дискретного чипа как на самой системной плате, так и на плате расширения. По способу подключения USB-контроллер может быть выполнен для PCI-шины, либо для шины PCI Express.
UHCI OHCI для USB 1.1
В рамках спецификации 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-битный режим адресации.
EHCI в USB 2.0
Для USB 2.0 был разработан EHCI (Enhanced Host Controller Interface), который поддерживает только работу на высокой скорости (high speed, 480 Мбит/с).
В EHCI-контроллере с помощью разделенных транзакций (Split Transaction) реализована также поддержка низкоскоростных интерфейсов USB 1.1 для работы с более медленными устройствами.
XHCI для USB 3.0
Для USB 3.0 используется универсальный интерфейс XHCI (eXtensible Host Controller Interface), который поддерживает все скорости обмена данными.[1] Windows 7 при установке с USB не поддерживает USB 3.0 и просит драйвера носителя, проблема решается отключением в BIOS поддержки USB 3.0 или xHCI или подстановкой драйверов USB-контроллера при установке.
Bluetooth является беспроводной технологией для создания персональных сетей на расстоянии не более 10 метров, работающей на частоте 2.4 ГГц, которая не подлежащит лицензированию. Обычно такие сети формируются из портативных устройств, таких, как сотовые телефоны, КПК и лаптопы. В отличие от Wi-Fi, другой популярной беспроводной технологии, Bluetooth предоставляет более высокий уровень сервиса, например, файловые серверы типа FTP, передачу файлов, голоса, эмуляцию последовательного порта и другие.
По умолчанию драйверы устройств Bluetooth поставляются в виде модулей ядра. Перед подключением устройства вам необходимо подгрузить драйвер в ядро.
Если Bluetooth-устройство в момент запуска системы подключено, то загружайте модуль из файла /boot/loader.conf .
ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3, wMaxPacketSize=49, nframes=6, buffer size=294
Host Controller Interface (HCI) предоставляет интерфейс для управления контроллером передатчика и менеджером соединений, а также доступ к данным о состоянии оборудования и его управляющим регистрам. Этот интерфейс предоставляет унифицированный метод доступа к передающим возможностям Bluetooth. Уровень HCI на управляющей машине обменивается данными и командами с микрокодом HCI в оборудовании Bluetooth. Драйвер для Host Controller Transport Layer (то есть физической шины) предоставляет обоим слоям HCI возможность обмениваться данными друг с другом.
Для одного Bluetooth-устройства создаётся один узел Netgraph типа hci . HCI-узел обычно подключается к узлу драйвера устройства Bluetooth (входящий поток) и к узлу L2CAP (исходящий поток). Все операции с HCI должны выполняться на узле HCI, но не на узле драйвера устройства. В качестве имени по умолчанию для узла HCI используется ``devicehci''. Дополнительные подробности можно найти на справочной странице ng_hci (4) .
BD_ADDR является уникальным адресом устройства Bluetooth, вроде MAC-адресов сетевых адаптеров. Этот адрес необходим для дальнейшей работы с устройством. Адресу BD_ADDR можно присвоить удобное для чтения имя. Файл /etc/bluetooth/hosts содержит информацию об известных хостах Bluetooth. В следующем примере показано, как получить имя, назначенное удалённому устройству.
% hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4 BD_ADDR: 00:80:37:29:19:a4 Name: Pav's T39
Если вы выполните опрос на другом Bluetooth-устройстве, но ваш компьютер будет опознан как ``your.host.name (ubt0)''. Имя, назначаемое локальному устройству, может быть в любой момент изменено.
Система Bluetooth предоставляет услуги по соединениям типа точка-точка (при этом задействованы только два устройства Bluetooth) или точка-ко-многим-точкам. В последнем случае соединение используется совместно несколькими устройствам Bluetooth. В следующем примере показывается, как получить список активных для локального устройства соединений.
% hccontrol -n ubt0hci read_connection_list Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State 00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN
Идентификатор соединения ( connection handle ) полезен, когда необходимо прекратить соединение. Заметьте, что обычно нет нужды делать это вручную. Стек будет автоматически разрывать неактивные соединения.
Обратитесь к помощи посредством hccontrol help для получения полного списка доступных HCI-команд. Большинство команд HCI для выполнения не требуют прав администратора системы.
Протокол L2CAP (Logical Link Control and Adaptation Protocol) предоставляет услуги по работе с данными, как ориентированные на соединения, так и без ориентации на них, протоколам более высокого уровня с возможностями мультиплексирования и обеспечением операций по сегментации и обратной сборке. L2CAP позволяет протоколам более высокого уровня и приложениям передавать и получать пакеты данных L2CAP длиной до 64 Кбайт.
L2CAP основан на концепции каналов . Каналом является логическое соединение поверх соединения по радиоканалу. Каждый канал привязан к некоторому протоколу по принципу многие-к-одному. Несколько каналов могут быть привязаны к одному и тому же протоколу, но канал не может быть привязан к нескольким протоколам. Каждый пакет L2CAP, получаемый каналом, перенаправляется к соответствующему протоколу более высокого уровня. Несколько каналов могут совместно использовать одно и то же радиосоединение.
Для одного Bluetooth-устройства создается один узел Netgraph типа l2cap . Узел L2CAP обычно подключается к узлу Bluetooth HCI (нижестоящий) и узлам Bluetooth-сокетов (вышестоящие). По умолчанию для узла L2CAP используется имя ``devicel2cap''. Для получения дополнительной информации обратитесь к справочной странице по ng_l2cap (4) .
% l2control -a 00:02:72:00:d4:1a read_channel_list L2CAP channels: Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State 00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN % l2control -a 00:02:72:00:d4:1a read_connection_list L2CAP connections: Remote BD_ADDR Handle Flags Pending State 00:07:e0:00:0b:ca 41 O 0 OPEN
% btsockstat Active L2CAP sockets PCB Recv-Q Send-Q Local address/PSM Foreign address CID State c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN Active RFCOMM sessions L2PCB PCB Flag MTU Out-Q DLCs State c2afe900 c2b53380 1 127 0 Yes OPEN Active RFCOMM sockets PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN
Протокол RFCOMM эмулирует последовательные порты поверх протокола L2CAP. Он основан на ETSI-стандарте TS 07.10. RFCOMM представляет собой простой транспортный протокол, с дополнительными возможностями по эмуляции 9 цепей последовательных портов RS-232 (EIATIA-232-E). Протокол RFCOMM поддерживает одновременно до 60 соединений (каналов RFCOMM) между двумя устройствами Bluetooth.
В рамках RFCOMM полный коммуникационный маршрут включает два приложения, работающие на разных устройствах (конечные коммуникационные точки) с коммуникационным сегментом между ними. RFCOMM предназначен для сокрытия приложений, использующих последовательные порты устройств, в которых они расположены. Коммуникационный сегмент по сути является Bluetooth-связью от одного устройства к другому (прямое соединение).
RFCOMM имеет дело с соединением между устройствами в случае прямого соединения, или между устройством и модемом в сетевом случае. RFCOMM может поддерживать и другие конфигурации, такие, как модули, работающие через беспроводную технологию Bluetooth с одной стороны и предоставляющие проводное соединение с другой стороны.
Во FreeBSD протокол RFCOMM реализован на уровне сокетов Bluetooth.
По умолчанию связь Bluetooth не аутентифицируется, поэтому любое устройство может общаться с любым другим. Устройство Bluetooth (например, сотовый телефон) может задать обязательность аутентификации для предоставления определённого сервиса (в частности, услугу доступа по коммутируемой линии). Bluetooth-аутентификация обычно выполняется через PIN-коды . PIN-код представляет из себя ASCII-строку длиной до 16 символов. Пользователь обязан ввести один и тот же PIN-код на обоих устройствах. Как только он введёт PIN-код, оба устройства сгенерируют ключ связи . После этого ключ может быть сохранён либо в самом устройстве, либо на постоянном носителе. В следующий раз оба устройства будут использовать ранее сгенерированный ключ соединения. Процедура, описанная выше, носит название подгонки пары (pairing). Заметьте, что если ключ связи потерян любой из сторон, то подбор пары должен быть повторен.
hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4
Протокол обнаружения сервисов SDP даёт возможность клиентским приложениям осуществлять поиск услуг, предоставляемых серверными приложениями, а также характеристик этих услуг. В перечень атрибутов сервиса включается тип класса предлагаемого сервиса и информация о механизме или протоколе, требуемом для использования сервиса.
SDP подразумевает коммуникации между SDP-сервером и SDP-клиентом. Сервер поддерживает список сервисов, в котором описываются параметры сервисов, связанных с сервером. Каждая запись об услуге содержит информацию об одном сервисе. Клиент может запросить информацию об опеределённом сервисе, обслуживаемом SDP-сервером, выдавая SDP-запрос. Если клиент или приложение, связанное с клиентом, решат воспользоваться сервисом, то для его использования необходимо открыть отдельное соединение к устройству, предоставляющему сервис. SDP предоставляет механизм обнаружения услуг и их параметров, но не даёт механизма использования этих сервисов.
Обычно SDP-клиент выполняет поиск услуг на основе некоторых желаемых характеристик услуг. Однако иногда возникает необходимость выяснить полный перечень типов услуг, предоставляемых SDP-сервером, не имея никакой информации об имеющихся сервисах. Такой процесс всех предлагаемых сервисов называется обзором (browsing).
Существующие на данный момент серверы и клиенты SDP реализованы в пакете стороннего разработчика sdp-1.5 , который можно сгрузить здесь . Утилита sdptool является SDP-клиентом, управляемым из командной строки. В следующем примере показано, как выполнять запрос на SDP-обзор.
. и так далее. Заметьте, что каждый сервис имеет перечень атрибутов (например, канал RFCOMM). В зависимости от сервиса вам может потребоваться где-то сохранить эти атрибуты. Некоторые реализации Bluetooth не поддерживают просмотр сервисов и могут возвращать пустой список. В этом случае возможен поиск конкретной услуги. В примере ниже показано, как выполнить поиск службы OBEX Object Push (OPUSH).
Во FreeBSD предоставление сервисов клиентам Bluetooth осуществляется сервером sdpd .
Для регистрации сервиса в локальном SDP-сервере также применяется утилита sdptool . В примере ниже показывается, как зарегистрировать Network Access с услугой PPP (LAN). Заметьте, что некоторые сервисы требуют указания их атрибутов (например, канала RFCOMM).
Модуль работы с коммутируемым доступом к сети (DUN - Dial-Up Networking) в большинстве случаев используется с модемами и сотовыми телефонами. Этот модуль покрывает следующие случаи:
сотовый телефон или модем используется вместе с компьютером в качестве беспроводного модема для подключения к серверу коммутируемого доступа в Интернет, или другой коммутируемой услуге;
сотовый телефон или модем используется компьютером для приёма входящих соединений.
Модуль доступа к сети по протоколу PPP (Network Access with PPP - LAN) может использоваться в следующих ситуациях:
доступ к ЛВС для одного Bluetooth-устройства;
доступ к ЛВС для нескольких Bluetooth-устройств;
связь между двумя ПК (при помощи протокола PPP поверх эмулируемого последовательного канала связи).
OBEX является широкоиспользуемым протоколом для простой передачи файлов между мобильными устройствами. В основном он используется в коммуникациях через инфракрасный порт для передачи файлов между ноутбуками или КПК компании Palm, а также для пересылки визитных карточек или календарных планов между сотовыми телефонами и другими устройствами с персональными информационными менеджерами.
Клиент OBEX используется для посылки или приёма объектов с сервера OBEX. Объектом, к примеру, может быть визитная карточка или указание. Клиент OBEX может получить номер RFCOMM-канала, указав вместо него имя сервиса. Поддерживаются следующие имена сервиса: IrMC, FTRN и OPUSH. Канал RFCOMM можно задать его номером. Ниже даётся пример сеанса OBEX, где с сотового телефона забирается объект с информацией об устройстве, а новый объект (визитная карточка) передаётся в каталог сотового телефона.
% obexapp -a 00:80:37:29:19:a4 -C IrMC obex> get get: remote file> telecom/devinfo.txt get: local file> devinfo-t39.txt Success, response: OK, Success (0x20) obex> put put: local file> new.vcf put: remote file> new.vcf Success, response: OK, Success (0x20) obex> di Success, response: OK, Success (0x20)
Модуль последовательного порта (SP - Serial Port) позволяет Bluetooth-устройству осуществлять эмуляцию последовательного порта RS232 (или подобного). Этот модуль покрывает случаи, касающиеся работы унаследованных приложений с Bluetooth в качестве замены кабельному соединению, при это используется абстракция виртуального последовательного порта.
После подключения псевдотерминал можно использовать как последовательный порт.
Некоторые старые Bluetooth-устройства не поддерживают переключение ролей. По умолчанию, когда FreeBSD подтверждает новое соединение, она пытается выполнить переключение роли и стать ведущим устройством. Устройства, которые это не поддерживают, не смогут подключиться. Заметьте, что переключение ролей выполняется при установлении нового соединения, поэтому невозможно выяснить, поддерживает ли удалённое устройство переключение ролей. На локальной машине имеется возможность отключить переключение ролей при помощи HCI-параметра.
Общее описание
HCI представляет собой командный интерфейс контроллера Baseband и менеджера связи, а так же предоставляет доступ к параметрам конфигурации устройства Bluetooth . Этот интерфейс предоставляет единообразный способ доступа к параметрам Baseband.
Нижние программные уровни стека Bluetooth
Хост – устройство, к которому подключен модуль Bluetooth.
На рисунке изображен обзор нижних программных уровней. Аппаратное ПО (микропрограмма) HCI преобразует команды интерфейса контроллера хоста в команды для физического оборудования Bluetooth (для Baseband и менеджера связей), а так же управляет статусными регистрами, регистрами управления и регистрами событий.
Между драйвером HCI и аппаратным ПО HCI могут существовать несколько слоев. Эти промежуточные слои не контролируют данные, передаваемые транспортным уровнем хост контроллера.
Драйвер HCI осуществляет обмен данными и командами с аппаратным ПО HCI. Для обеспечения передачи этих данных служит драйвер транспортного уровня хост контроллера (драйвер физической шины).
Хост получает асинхронные уведомления о событиях HCI независимо от того, как используется транспортный уровень. Когда хост обнаруживает, что произошло событие, он анализирует пакеты полученных событий для того, чтобы определить, какое событие произошло.
Транспортный уровень контроллера хоста
Стек драйверов хоста имеет транспортный уровень между драйвером контроллера хоста и хостом. Транспортный уровень прозрачен для передачи данных. Драйвер контроллера хоста, являющийся интерфейсом к контроллеру, должен быть независимым от способа передачи данных. К способу передачи данных не должны предъявляться требования знания данных, передаваемых драйвером контроллера самому контроллеру. Это позволяет изменять интерфейс (HCI) или контроллер, не влияя на транспортный уровень.
Обзор команд и событий HCI
Управление потоком HCI
Управление потоком от хоста к контроллеру
Управление потоком в этом направлении используется для предотвращения переполнения буфера данных контроллера с данными ACL, направляющимися на другое устройство (используя хендл соединения), которое не отвечает. Хост управляет буферами данных контроллера.
Управление потоком от контроллера к хосту
В некоторых реализациях может быть необходимым управление потоком в направлении от контроллера к хосту. Данный набор команд может использоваться для включения или отключения управления потоком в данном направлении.
Читайте также: