Какую функцию выполняет хост в интерфейсе usb

9

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

Станок пристрелочный 51 купить www.huntmania.ru. Заказать мягкую кровлю в интернет-магазине КСК24 по низкой цене.

Хост USB

Общая информация о хосте USB

Хост является главным действующим лицом в организации конфигурирования и выполнения транзакций USB. У каждой шины USB должен быть один (и только один!) хост — компьютер с контроллером USB. Однако понятие компьютер отнюдь не означает лишь привычные варианты настольных, напольных, портативных компьютеров. Компьютер — это сочетание процессора, памяти и периферийных устройств; в таком понимании в большинстве современных устройств присутствуют встроенные компьютеры. Если «интеллекта» этого компьютера и его возможностей диалога с пользователем оказывается достаточно, то он может взять на себя роль хоста USB. Такой вариант хоста рассматривается в последнем параграфе данной главы.

«Классический» хост USB делится на три основных уровня:

• интерфейс шины USB обеспечивает физический интерфейс и протокол шины. Интерфейс шины реализуется хост-контроллером, имеющим встроенный корневой хаб, обеспечивающий точки физического подключения к шине (гнезда USB типа «A»). Хост-контроллер отвечает за генерацию микрокадров. На аппаратном уровне хост-контроллер обменивается информацией с основной памятью компьютера, используя прямое управление шиной (bus-mastering) с целью минимизации нагрузки на центральный процессор;
• система USB, используя хост-контроллер(ы), транслирует клиентское «видение» обмена данными с устройствами — запросы IRP (I/O Request Packet — пакет запроса ввода/вывода) — в транзакции, выполняемые с реальными устройствами шины. Система отвечает и за распределение ресурсов USB — полосы пропускания и мощности источников питания (для устройств, питающихся от шины). Система состоит из трех основных частей:

1. драйвер хост-контроллера — HCD (Host Controller Driver) — модуль, привязанный к конкретной модели контроллера, обеспечивающий абстрагирование драйвера USB и позволяющий в одну систему включать несколько разнотипных контроллеров;
2. драйвер USB — USBD (USB Driver) — обеспечивает основной интерфейс (USBDI) между клиентами и устройствами USB. Интерфейс HCDI (Host Controller Driver Interface) между USBD и HCD спецификацией USB не регламентируется. Он определяется разработчиками ОС и должен поддерживаться разработчиками хост-контроллеров, желающих иметь поддержку своих изделий конкретными ОС. Клиенты не могут пользоваться интерфейсом HCDI; для них предназначен интерфейс USBDI. USBD обеспечивает механизм обмена в виде пакетов IRP, запрашивающих транспортировку данных по заданному каналу. Кроме того, USBD отвечает за некоторое абстрактное представление устройства USB клиенту, которое позволяет выполнять конфигурирование и управление состоянием устройств (включая и стандартное управление через конечную точку «0»). Реализация интерфейса USBDI определяется операционной системой; в спецификации USB излагаются только общие идеи;
3. программное обеспечение хоста реализует функции, необходимые для функционирования системы USB в целом: обнаружение подключения и отключения устройств и выполнение соответствующих действий по этим событиям (загрузки требуемых драйверов), нумерацию устройств, распределение полосы пропускания и потребляемой мощности, управление состоянием энергопотребления и т. п.

• клиенты USB — программные элементы (приложения или системные компоненты), взаимодействующие с устройствами USB. Клиенты могут взаимодействовать с любыми устройствами (наборами их доступных конечных точек, входящих в выбранные интерфейсы), подключенными к системе USB. Однако система USB изолирует клиентов от непосредственного обмена с какими-либо портами (в пространстве ввода/вывода) или ячейками памяти, представляющими интерфейсную часть контроллера USB.

В совокупности уровни хоста предоставляют следующие возможности:

• обнаружение подключения и отсоединения устройств USB;
• манипулирование потоками управления между устройствами и хостом;
• манипулирование потоками данных;
• сбор статистики активности и состояний устройств;
• управление электрическим интерфейсом между хост-контроллером и устройствами USB, включая управление электропитанием.

Программная часть хоста в полном объеме реализуется операционной системой. До загрузки ОС может функционировать лишь усеченная часть ПО USB, поддерживающая только устройства, требующиеся для загрузки. Так, в BIOS современных системных плат имеется поддержка клавиатуры USB, реализующая функции сервиса Int 9h. После загрузки системы USB эта «дозагрузочная» поддержка игнорируется — система начинает работу с контроллером «с чистого листа», то есть со сброса и определения всех подключенных устройств. В спецификации PC’2001 выдвигается ряд требований к BIOS, в частности требование поддержки загрузки ОС с устройств USB.

Хост-контроллер

Хост-контроллер является аппаратным посредником между устройствами USB и хостом. В настоящее время имеется три спецификации хост-контроллеров, каждой из которых соответствует свой комплект драйверов хост-части:

• UHC (Universal Host Controller) — универсальный хост-контроллер для шины USB 1.x, разработанный Intel;
• OHC (Open Host Controller) — «открытый» хост-контроллер для шины USB 1.x, разработанный Compaq, Microsoft и National Semiconductor;
• EHC (Enhanced Host Controller) — расширенный хост-контроллер для поддержки высокой скорости шины USB 2.0.

Все эти варианты контроллеров выполняют одни и те же задачи: организуют физические транзакции с устройствами по шине USB в соответствии с описаниями (дескрипторами) этих транзакций, помещенными в системное ОЗУ драйвером хост-контроллера. При этом транзакции разных типов обрабатываются по-разному. В плане обработки ошибок проще всего устроены изохронные транзакции, где ошибки не требуют повторов. Транзакции передач с гарантированной доставкой в случае ошибок требуют повторов до победного конца или признания неудачи (исчерпания допустимого числа повторов). С точки зрения планирования следует выделить периодические транзакции, которые должны выполняться строго по графику, остальные — как получится, и их ставят в очереди. Из-за особенностей планирования и возможных повторов порядок завершения обработки дескрипторов транзакций (успешных или нет) будет отличаться от порядка их помещения в память1, что прибавляет забот хост-контроллеру и его драйверу. Три варианта хостконтроллеров решают эти задачи по-разному и используют разные стратегии планирования транзакций, что иллюстрирует таблицы ниже.

План распределения времени в кa)адре: a — UHC; б — OHC; в — EHC (в микрокадре)

«Универсальный» хост-контроллер — 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 — состояние выполнения передачи:

• бит 23: Active — «надо исполнять», устанавливается драйвером, сбрасывается контроллером по успешному исполнению или исчерпанию лимита повторов;
• бит 22: Stalled — точка ответила пакетом STALL;
• бит 21: Data Buffer Error — ошибка буфера данных (переполнение или переопустошение FIFO при выполнении транзакции), транзакция остается активной (при переопустрошении контроллер генерирует пакет с ошибочным CRC, при переполнении не отвечает подтверждением);
• бит 20: Babble — при выполнении данной транзакции обнаружена «болтливость» устройства (оно отключается и устанавливается бит Stalled);
• бит 19: NAK — получение соответствующего ответа (в транзакции SETUP получение NAK устанавливает и признак ошибки тайм-аута);
• бит 18: CRC/Time Out Error — обнаружена ошибка передачи (CRC или таймаут);
• бит 17: Bitstuff Error — обнаружена ошибка вставки бит.

Биты [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 имеются и специальные регистры, упрощающие задачу эмуляции.

Русские Блоги

Нулевые знания USB
USB — это метод передачи данных, это также шина данных, и это одна из самых сложных шин. Чтобы
На оборудовании он подключается с помощью вилки. С одной стороны вилка, а с другой розетка. Например, гнездо на ПК — это гнездовой соединитель, а устройство USB использует штекерный соединитель для подключения к ПК. Чтобы
В настоящее время существует три типа аппаратных интерфейсов USB. Тип, используемый на обычных компьютерах, называется Type; исходный интерфейс, использовавшийся в эпоху обычных телефонов Nokia, — Mini USB; и текущий Micro USB, используемый телефонами Android.

Host
USB — это передача данных по всей шине, управляемой хостом. На одной шине USB может быть только один хост. Чтобы
OTG
Режим On The Go, представленный в USB2.0, предлагает новую концепцию, называемую протоколом согласования хоста (протокол согласования хоста), которая позволяет двум устройствам обсуждать, кто идет Когда Host.

Дополнительные сведения о USB см. На официальном веб-сайте USB и в следующей статье:
http://www.crifan.com/files/doc/docbook/usb_basic/release/html/usb_basic.html

Концепция USB HOST / DEVICE / OTG:

Контроллер OTG может использоваться как хост или как устройство.Роль контроллера обычно определяется уровнем USB ID. Полные аппаратные сигналы контроллера USB2.0 OTG следующие:

USB_ID: Входной сигнал, определяемый протоколом USB OTG, используемый для определения роли по умолчанию (хост или устройство) устройства, подключенного к порту USB. USB_ID подтянут по умолчанию и находится в состоянии устройства.Если вы хотите, чтобы контроллер переходил в состояние хоста, вам необходимо подключить порт mini-A или порт micro-A, чтобы замкнуть USB_ID на землю.

Его также можно принудительно переключить с помощью программного обеспечения, через управление
/sys/bus/platform/drivers/usb20_otg/force_usb_mode
реализация, может иметь следующие три значения:

0: определяется аппаратно, а именно USB ID
1: обязательный режим хоста
2: обязательный режим устройства

Разница между режимом HOST и режимом OTG

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

Как работает USB OTG
Наиболее важным расширением дополнительной спецификации OTG к USB 2.0 является более энергоэффективное управление питанием, позволяющее устройству работать как в режиме хоста, так и в режиме периферии. Существует два типа устройств OTG: устройства OTG двойного назначения (устройство Dualrole) и периферийные устройства OTG (устройство Peripheralonly OTG). Устройство OTG двойного назначения полностью соответствует спецификации USB 2.0. В то же время оно также предоставляет ограниченные возможности хоста и сокет MiniAB, поддерживает протокол согласования хоста (HNP) и поддерживает протокол запроса транзакции, как периферийное устройство OTG. (Протокол запроса сеанса, SRP). При работе в качестве хоста устройство OTG двойного назначения может обеспечивать ток 8 мА на шине, в то время как предыдущий стандартный хост должен обеспечивать ток от 100 до 500 мА.

Когда два устройства OTG двойного назначения соединены вместе, они могут поочередно работать как хост и подчиненное устройство.Эта функция совместима с существующей моделью структуры хоста / периферии со спецификацией USB. Хост OTG отвечает за инициализацию задач передачи данных, таких как сброс шины, получение различных дескрипторов USB и настройка устройств. После завершения этих конфигураций два устройства OTG могут передавать информацию в форме ведущего и ведомого соответственно.Процесс обмена ролями ведущий-ведомый между двумя устройствами определяется протоколом передачи узла (HNP).

1.1 Начальные функции хоста (Adevice) и подчиненного (Bdevice)
Начальная функция устройства реализуется путем определения соединителя. OTG определяет карманный разъем под названием MiniAB, который можно напрямую подключать к разъемам MiniA или MiniB. MiniAB имеет контактный штырь, подтянутый к клемме питания, а штекер MiniA имеет ID (R <10 Ом), подключенный к земле. Штекер Mini B имеет открытый контакт ID (R> 100 кОм), подключенный к земле. Когда два устройства OTG соединены вместе, контакт ID на стороне штекера MiniA будет вводить состояние «0», контакт ID на стороне штекера MiniB равен «1», а устройство OTG с идентификатором 0 по умолчанию является хостом (Adevice). , Устройство OTG с ID 1 по умолчанию является подчиненным (устройство B). Рисунок 1 иллюстрирует сказанное выше.

1.2 Протокол запроса сеанса (SRP)

Этот протокол позволяет устройству Adevice (которое может питаться от батареи) экономить энергопотребление, отключая Vbus, когда шина не используется, а также предоставляет возможность Bdevice запускать действия шины. Любое устройство, включая ПК или портативный компьютер, может реагировать на SRP; любое устройство B, включая стандартное периферийное USB-устройство, может запускать SRP; требуется устройство с двойным функционалом как для запуска SRP, так и для ответа на SRP.

1.3 Протокол согласования хоста (HNP)
HNP — это протокол, используемый для преобразования между Adevice и Bdevice master / slave (фактически, изменение направления кабеля). Результат обмена функциями ведущий / ведомый показан в следующем процессе:
(1) Используйте подтягивающий резистор, чтобы отправить сигнал ведомому устройству.
(2) Устройство может установить функцию «HNP Enable» на Bdevice.
(3) Bdevice отключен и поднят.
(4) ADevice подключено к подтягивающему резистору, что указывает на то, что Adevice является подчиненным.
(5) Устройство подает питание на Vbus.
(6) Bdevice обнаруживает подтягивание Adevice.
(7) Сбросить / перечислить / использовать устройство.

1.4 Драйвер
В отличие от хостов ПК, портативные устройства не имеют удобного способа и достаточного места для загрузки новых драйверов. Поэтому спецификация OTG требует, чтобы каждое устройство OTG двойного назначения имело список поддерживаемых периферийных целевых устройств OTG, который включает такую ​​информацию, как тип устройства и производитель.
В отличие от ПК, стек драйверов устройства двойного назначения OTG состоит из стека хоста USB и стека устройств USB, чтобы удовлетворить потребности этих двух методов работы. Драйвер OTG решает, использовать ли стек хоста USB или стек устройств USB, в зависимости от разницы в разъемах или наличия рабочего режима устройства переключения NHP.
Когда устройство двойного назначения OTG работает в режиме хоста, работает стек хоста USB. Драйвер хост-контроллера отвечает за обмен данными между стеком хоста USB и конечной точкой оборудования, драйвер USB перечисляет и сохраняет информацию об устройствах, а драйвер класса хоста целевого периферийного устройства поддерживает устройства в списке целевых устройств. Драйвер класса хоста предоставляется производителем чипа. В то же время OTG предоставляет общий драйвер класса хоста (который может быть изменен для неуниверсальных устройств).
Когда устройство двойного назначения OTG работает в ведомом режиме, стек USB-устройств работает. Драйвер контроллера устройства отвечает за обмен данными между стеком USB-устройства и конечной точкой оборудования. Уровень протокола USB отвечает за обработку спецификации протокола USB. Функция драйвера устройства зависит от функции устройства двойного назначения (например, цифровых камер, запоминающих устройств, принтеров). Подождите).
Драйвер OTG отвечает за обработку преобразования рабочего режима устройства OTG двойного назначения. В то же время он также может возвращать результат (например, поддерживает ли устройство HNP) и обрабатывать ошибки шины. Программа прикладного уровня запускает или завершает транзакцию передачи через драйвер OTG и обменивается данными с аппаратным уровнем через стек хоста USB или стек устройств.

1.5 Модель потока данных
Хост и устройство OTG разделены на три разных уровня: функциональный уровень, уровень USB-устройства и уровень интерфейса USB, как показано на рисунке 2.

Уровень интерфейса USB обеспечивает физическое соединение для хоста OTG и устройства OTG.Программное обеспечение системы USB использует хост-контроллер для управления передачей данных между хостом и устройством USB. По сравнению с хост-контроллером системное программное обеспечение USB занимается передачей данных и взаимодействием между клиентом и устройством с точки зрения клиента. Уровень USB-устройства обеспечивает используемое логическое устройство для программного обеспечения хост-системы USB. Хост реализует свои различные функции через клиентское программное обеспечение, которое соответствует его функциям.
Устройства OTG, как и предыдущие устройства USB, имеют два канала: канал потока данных и канал сообщения. Канал потока данных не имеет определенного результата, а канал сообщения имеет фиксированную структуру. Однако каждый канал имеет определенную полосу пропускания, тип передачи, направление передачи и размер буфера. Устройство с автономным питанием настроено с каналом управления по умолчанию и предоставляет такую ​​информацию, как конфигурация и состояние устройства.

Один вопрос и один ответ:

1. Что такое USB OTG?
USB OTG — это дополнительная спецификация для USB 2.0.
2. Какое расширение USB OTG для USB 2.0 является наиболее важным?
Более энергосберегающее управление питанием и позволяет устройству работать в двух формах: хост и периферийное устройство.
3. В USB2.0 определены три типа: HOST (хост), Device, HUB.
OTG добавляет два новых устройства: устройство с двумя ролями, устройство OTG только для периферийных устройств (периферийное устройство OTG).
4. В USB 2.0 определены три пары разъемов (вилка и розетка): Standard-A (хост), Standard-B (периферийное устройство), Mini-B (меньшее Периферийные устройства)
Новый разъем OTG: Mini-A
Новые сокеты OTG: Mini-A и Mini-AB (с одновременной поддержкой вилок Mini-A или Mini-B)
Цвет пластика внутри вилки и розетки: Mini-A — белый, Mini-B — черный, а Mini-AB — серый.
5. В USB 2.0 определены два кабеля: от стандарта A до стандарта B, от стандарта A до Mini-B.
Два типа кабелей, добавленных OTG: Mini-A — Standard-B, Mini-A — Mini-B.
6. Двухролевое устройство OTG (двухролевое устройство) должно иметь:
1) Ограниченные возможности хоста
2) Может использоваться как полноскоростное периферийное устройство (дополнительный высокоскоростной режим)
3) Может использоваться в качестве полноскоростного хоста (необязательный низкоскоростной или высокоскоростной режим)
3) Список целевых устройств и драйверов OTG.
4) Поддержка SRP, HNP
5) Одна розетка Mini-AB
6) Токовый выход не менее 8 мА на VBUS
7) Как общаться с пользователями
7. Периферийное устройство OTG (периферийное устройство OTG):
1. Это обычное периферийное устройство USB.
2. Поддержка SRP
3. Разъем Mini-B (Mini-AB использовать нельзя)

8. Как реализовать Android USB может обнаруживать дополнительное устройство и отправлять хост-устройство одновременно

Для usb-связи мы должны сначала выяснить, какая сторона HOST, а какая SLAVE
Например, если ваш телефон Android используется в качестве хоста, для получения подчиненного устройства используйте UsbDevice для представления подчиненного устройства.
Если ваш телефон Android является подчиненным, вам нужно получить хост, используйте UsbAccessory для представления хоста

Интерфейс USB. Часть 1. Основы

В настоящий момент один из самых популярных интерфейсов — это безусловно USB. Девайсов, которые его используют, просто огромное количество. Это и мышки, и клавиатуры, и принтеры, и сотовые телефоны, и много чего ещё. В отличии от стремительно исчезающего RS-232, USB встречается во всех современных компьютерах, ноутбуках, телефонах… так что, если мы хотим создавать действительно универсальные девайсы, придётся нам этот интерфейс изучать. Вот прямо сейчас и начнём, а заодно, по ходу изучения, попытаемся сами посоздавать каких-нибудь USB-девайсов.

Итак, USB (universal serial bus) — универсальная последовательная шина. Большинство USB-устройств соответствуют спецификациям 1.1 и 2.0. В спецификации 1.1 определены две скорости передачи информации: LS (low speed) — низкая скорость, 1,5 Мбит/с и FS (full speed) — полная скорость, 12 Мбит/с. В редакции 2.0 к ним добавлена ещё и высокая скорость HS (high speed), 480 Мбит/с. Не так давно вышла ещё спецификация — 3.0, но устройства, поддерживающие этот стандарт, пока не очень распространены, поэтому и бог с ней.

Физические устройства на шине USB бывают трёх типов: хост-контроллер, хаб и конечное устройство.

Хост-контроллер — это главный управляющий шиной USB. Именно он обеспечивает связь устройств, подключенных к шине, с компьютером (с ОС и с клиентским ПО). Любые сеансы обмена данными может начинать только хост-контроллер, остальные устройства молчат в тряпочку, пока хост-контроллер к ним не обратится.

Контроллер взаимодействует с ОС через драйвер хост-контроллера (HCD — host controller driver). Этот драйвер привязан к конкретной модели хост-контроллера. Только он знает какие данные, в какие регистры и в каком порядке пихать в хост-контроллер, а также откуда какие данные брать, чтобы хост-контроллер сделал то, чего от него хотят.

Со стороны ОС шиной USB управляет ещё один драйвер — USBD (universal serial bus driver). Ему совершенно пофиг, как там конкретно реализован хост-контроллер и где у него какие регистры (для этого есть HCD), USBD решает общие (неспецифические для конкретного хост-контроллера) вопросы: взаимодействие с клиентским ПО, нумерация устройств на шине, их конфигурирование, распределение питания и пропускной способности шины и так далее. Это, можно сказать, своеобразный диспетчер, который осуществляет общий контроль над шиной и её взаимодействие с внешним миром (с клиентским ПО).

Хост-контроллер — птица гордая и пугливая, поэтому непосредственно ни с кем из подданных он не разговаривает. Для общения с подданными у него есть специальные помощники — хабы (их ещё иногда называют концентраторами).

Хабы — это устройства, которые позволяют физически подключить устройства USB к шине. Они предоставляют порты для подключения, ретранслируют трафик от хост-контроллера к конечным устройствам и обратно, отслеживают состояние и физически управляют электропитанием портов. У хабов есть один восходящий (upstream) порт, — это тот порт, который подключен по направлению к хост-контроллеру, и несколько нисходящих (downstream) портов, — это порты, к которым подключаются конечные устройства. Хабы можно каскадировать, подключая к нисходящему порту хаба ещё один хаб. Самый главный хаб, интегрированный с хост-контроллером, называется корневым хабом (он же — корневой концентратор или root hub).

Другими словами можно сказать, что у хаба есть две основных задачи: 1) создать хост-контроллеру иллюзию, что он непосредственно разговаривает с подключенным к хабу устройством; 2) наблюдать за своим сегментом шины (за девайсами, подключенными к нисходящим портам), сообщать «наверх» обо всех изменениях и, если надо, — подключать и отключать питание портов.

Конечные устройства — это все те полезные устройства, которые мы подключаем к шине USB (флэшки, принтеры, мышки и т.д.)

Нужно сказать, что физические устройства и логические устройства — это не всегда одно и тоже. Существуют, например, такие конечные устройства (называемые составными — compound devices), которые содержат внутри себя хаб, к которому подключено ещё несколько устройств. Несмотря на то, что в этом случае хаб и все, подключенные к нему устройства, запакованы в один корпус, с точки зрения логики шины это будут совершенно разные устройства.

Для логических конечных устройств обычно используют термин «функции». Таким образом, с точки зрения логики шины, устройства на ней можно разделить на хабы и функции (и неважно, запакованы ли они в один корпус или нет). Каждое логическое устройство на шине имеет уникальный адрес (1-127), присваеваемый ему хостом при подключении.

Исходя из описанного выше, получается, что физическая топология шины USB — дерево (ну, потому что хабы можно каскадировать), а логическая топология — звезда, центром которой является хост-контроллер. Физическая и логическая топологии шины USB показаны на рисунке ниже.

Идём дальше. Что же вообще представляет собой логическое устройство USB (как хабы, так и функции)?

Логическое устройство представляет собой набор так называемых конечных точек (endpoints или просто EP). Физически, конечные точки — это просто разные буферы в логическом устройстве USB, через которые происходит обмен данными с хостом. Логичный вопрос — а зачем нам иметь несколько буферов? Ну, просто потому что удобно для разных задач иметь разные буферы. Устройство же у нас может выполнять параллельно несколько разных задач. (Минимум две — отслеживать команды управления от хоста и делать что-то полезное.) У этих разных задач могут могут быть разные степени важности, требования к надёжности, своевременности и скорости доставки данных и, наконец, источники и потребители пересылаемой информации также могут быть разные (источником и потребителем полезной инфы обычно является клиентский драйвер, в то же время всякая управляющая инфа ему обычно нафиг не нужна).

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

Во-первых, придумали 4 различных типа передач. Для каждой конечной точки должно быть определено, каким из этих типов передач с ней нужно общаться. Типы передач в USB существуют следующие:

1. изохронные передачи (isochronous transfers). Они предназначены для передачи потоковых данных в реальном времени. Такие передачи гарантируют время доставки, но не гарантируют, что все данные будут доставлены. Если во время передачи происходит ошибка, то данные просто теряются. Кроме того, для передач такого типа должно быть предварительно согласовано, какую часть пропускной способности шины эта передача будет занимать. Изохронные передачи имеют наивысший приоритет и имеют право занять до 90% пропускной способности канала. Передачи этого типа используются, например, для видеокамер, или колонок. Никого ведь не устроит, если звук в колонках будет лагать. Лучше уж потерять часть данных, но слушать песню не рывками, а непрерывно.
2. прерывания (interrupts). Этот тип предназначен для спонтанных небольших сообщений, но с гарантированным временем обслуживания и гарантированной доставкой. Примером может служить USB клавиатура. Мы можем нажать на кнопку в любой момент (может 3 часа не нажимали, а может так и заклацали клавой каждую секунду). Пока мы спим за компом — и передавать ничего не надо. Но как только мы всё же щелканули по кнопкам — будьте любезны, сообщите об этом куда следует и желательно побыстрее.
3. передача массивов данных (bulk data transfers). Для этого типа нет никаких гарантий по скорости, единственное в чём можно быть уверенным — что данные дойдут в целости и сохранности (когда-нибудь, гы-гы). Такие передачи имеют самый низкий приоритет, но зато им ничего не надо согласововать, — сколько останется свободной от других типов передач ширины канала — столько они и займут. Не останется вообще — будут ждать, когда канал освободится. Такие передачи можно использовать для обмена данными с устройствами, которым некуда спешить, например, с принтерами. Представьте, что вы отправили на печать USB-принтеру фотку и одновременно слушаете музыку в USB-колонках. Согласитесь ли вы, чтобы фотка напечаталась на 3 секунды раньше, но при этом начал лагать звук в колонках? Вероятнее всего нет, так ведь. Пусть лучше данные принтеру передаются медленнее, но зато музыка играет непрерывно, без всяких дёрганий.
4. управляющие передачи (control transfers). Это передачи типа запрос-ответ. С помощью них передаются комады управления устройствами. Тут важна не только безошибочная передача, но и получение ответа о результатах выполнения команды. Кроме того, поскольку эти передачи являются служебными, то им гарантировано 10% пропускной способности канала.

Вернёмся к нашим конечным точкам. Для того, чтобы отличить одну точку от другой, — конечные точки, должны иметь уникальный номер. Но это не всё. Кроме номера, каждая конечная точка имеет ещё и направление. IN — если точка предназначена для передачи данных хосту, OUT — если точка предназначена для приёма данных от хоста. Точки с одинаковыми номерами, но с разными направлениями передачи данных — это разные с точки зрения логики шины конечные точки.

Единственное исключение — конечная точка EP0. У неё вообще особый статус. Она является служебной и предназначена для общего управления устройством (конфигурирование, настройка и т.д.). Кроме того, эта конечная точка двунаправленная и она должна обязательно присутствовать в любом USB-устройстве.

Исходя из всего вышеописанного, для идентификации какой-то конечной точки на шине, нам нужно знать адрес устройства, к которому относится конечная точка, её номер в устройстве и направление передачи данных через эту точку.

Поскольку устройство не всегда делает абсолютно всё на что оно только способно, да и способов решения одной и той же задачи оно может иметь несколько, то обычно нет необходимости задействовать абсолютно все конечные точки. Поэтому придумали такие понятия, как интерфейс, конфигурация и альтернативные установки. Интерфейс объединяет конечные точки, предназначенные для решения какой-либо одной задачи. Наборы используемых одновременно интерфейсов называются конфигурациями. Альтернативные установки позволяют включать или отключать какие-то входящие в конфигурацию конечные точки, в зависимости от способа решения задач для которых предназначена эта конфигурация.

Самих конфигураций и альтернативных установок у каждой из этих конфигураций для одного логического устройства может существовать несколько, но в каждый момент времени только один из этих наборов может быть активен. Причём хост должен знать, какой именно набор активен и в соответствии с этим обеспечивать связь с входящими в этот набор конечными точками. Остальные конечные точки, не входящие в активный набор, не будут доступны для связи.

Поясню, что значит «обеспечивать связь с конечными точками». Для связи клиентского ПО с каждой активной конечной точкой хост создаёт коммуникационный канал (communication pipe). Клиентское ПО, которое хочет пообщаться с конечной точкой, должно отправить к соответствующему каналу пакет запроса ввода/вывода (IRP — input/output request packet) и ждать уведомления о завершении его обработки. В IRP указывается только адрес буфера, куда надо складывать или откуда брать данные и длина передачи. Всё остальное за вас сделает хост и обслуживающие его драйвера (USBD и HCD)

В зависимости от типа передач, используемых в канале, коммуникационные каналы делятся на два типа: потоковые (streaming pipes) и каналы сообщений (message pipes).

Коммуникационный канал к точке EP0 является служебным и называется основной канал сообщений (default pipe, control pipe 0). Владельцем основных каналов сообщений всех подключенных устройств является драйвер USBD, поскольку, как мы уже говорили, через EP0 осуществляется конфигурирование и настройка устройства.

На этом, пожалуй, с основами закончим и в следующей статье попробуем более детально рассмотреть механизм передачи данных по интерфейсу USB.

Что такое USB-host и USB OTG

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

Тема сегодняшней статьи — USB-host (USB-хост). Это весьма примечательная функция, которой оснащается достаточно большое количество устройств (в основном, правда, довольно дорогих), и рассказать о ней определенно стоит. Также я расскажу и о функции USB OTG — фактически, более современной разновидности USB-хоста.

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

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

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

В каких случаях USB-хост удобен и нужен? Да во многих. Согласитесь, возможность скопировать файлы на плеер, планшет или ридер без подключения его к компьютеру не может не радовать. Вам надо просто подключить к устройству флэшку или какое-либо другое устройство, с которого вам нужно перенести файлы.

Весьма приятна возможность перенести снимки с фотоаппарата на планшет или плеер с жестким диском, и тем самым освободить память фотоаппарата, сделать еще больше снимков. Подключение клавиатуры к планшету — тоже очень приятная возможность. Удобны и принтеры с наличием USB-хоста: к ним можно напрямую подключать фотоаппараты, телефоны, флэшки и печатать снимки или документы прямо с них; компьютер для этого совершенно необязателен.

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

Именно поэтому я советую перед покупкой того или иного устройства проверить, насколько качественно реализована в нем опция USB-host. Попробуйте подключить флэшку, посмотреть, насколько легко и удобно можно скопировать файлы с нее и на нее. Если у вас есть usb-клавиатура, которую вы планируете использовать вместе с покупаемым устройством, не лишним будет проверить корректность ее работы. Если же вы соберетесь купить такую клавиатуру уже после покупки самого устройства, то возьмите с собой в магазин это устройство и проверьте, насколько корректно будут с ним работать представленные в магазины клавиатуры.

Стоит отметить, что сейчас имеются в продаже устройства и с поддержкой так называемого USB OTG. Я бы сказал даже, что USB OTG сейчас встречается в устройствах довольно часто, чаще, чем классический USB-хост. В чем основное отличие USB OTG? В том, что USB OTG не предполагает наличие отдельного классического полноразмерного порта USB. Для подключения периферийных устройств используется порт microUSB или miniUSB, который, вообще говоря, служит главным образом для связи устройства с компьютером. На устройстве с USB OTG этот порт фактически совмещает в себе функции USB-host (подключение периферии) и USB-device (подключение к компьютеру).

Чтобы к miniUSB/microUSB порту с поддержкой OTG подключить флэшку или, скажем, клавиатуру, необходимо приобрести специальный переходник, который стоит порядка 500 рублей (при желании его можно найти по более низкой цене или же вовсе сделать самому — в интернете есть инструкции). Затем нужно вставить этот переходник в порт miniUSB/microUSB, а к соответствующему выходу переходника подключить нужное вам периферийное устройство.

И тут опять же стоит отметить, что не на всех устройствах USB OTG реализовано хорошо. Где-то поддержка USB OTG может быть заявлена, но ввиду отсутствия необходимого программного обеспечения она не работает. Пример — ридеры Onyx Boox. Также стоит отметить, что внешние жесткие диски по протоколу USB OTG подключить вряд ли удастся: они потребляют слишком много энергии; планшет «прокормить» их просто не в состоянии.

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

Под конец стоит ответить на вопрос: почему USB OTG сейчас популярнее, чем обычный USB-host? Ответ, на самом деле, довольно прост: USB OTG позволяет уменьшить толщину и вес устройства. В случае с классическим USB-host’ом в устройство надо встроить полноразмерный USB-порт (соответственно, увеличивается толщина) и обычный mini/micro-USB порт — для подключения к компьютеру (увеличивается и итоговый вес). В случае с USB OTG надо установить только один mini/microUSB-порт, просто многофункциональный — работающий и на вход, и на выход. Более того, USB OTG отличается более низким энергопотреблением, хотя и не позволяет поэтому подключать такие прожорливые устройства, как внешние жесткие диски.

Но USB OTG не лишен и недостатков, главным из которых является необходимость покупки переходника и постоянной его переноски с собой.

Посмотреть, поддерживает ли интересующее вас устройство опцию USB-host или USB OTG, можно на странице описания устройства в разделе «Технические характеристики» («Спецификации»). Описание, разумеется, можно найти на сайте производителя устройства, а также на сайтах многих магазинов.

17 Replies to “Что такое USB-host и USB OTG”

Кстати: может сделать небольшой обзор- справочник по кабелям? Что такое AM-AF, AM-BM и прочие абревиатуры. Для чего они нужны, полезны и т.д
Можно сюда и HDMI добавить. Сейчас в продаже как минимум три разновидности(модификации) этих кабелей. Последняя, самая дорогая позволяет использовать этот кабель для всего- вплоть до передачи интернета. Т.е из него пытаются сделать универсальный стандарт.

Увы, я совершенно не разбираюсь кабелях, во всех этих AM-AF, AM-BM и тому подобных разновидностях.

Самое оригинальное применение AM-AF : если пользуетесь модемом от сотового оператора, то при плохом приеме удлинить соединение с помощью этого кабеля и подвесить модем к потолку или выкинуть в форточку. ��

. Но USB OTG не лишен и недостатков — невозможность подключения USB-хаба (разветвителя).
А как же это видео?
http://samsung-galaxy.mobi/samsung-galaxy-s3-i-dzhoystik-posredstvom-usb-otg/

Спасибо за информацию и ссылку! Сейчас сам удивляюсь, с чего взял, что нельзя подключить юсб-хаб к устройству с OTG:)
Убрал соответствующее предложение.

Hi All!
К моему Samsung Galaxy Tab 7.7 через USB-OTG кабель непосредственно подключаются маломощные (до 500мА потребляемого тока) USB-устройсва, как-то USB Flash, USB Card Readers, etc., а также мощные USB устройства типа EBook, Ext USB HDD с подключенным собственным питанием. Через внешний USB-hab со своим источником питания поключаются внешние USB HDD, не имеющие собственного источника питания — проверено на Jet HDD 0.5TB, который получает питание только через USB. Причем, в отличе от многих китайских недопланшетов, видится несколько поключенных к хабу устойств, а не «одно из…» То же самое могу сказать про Samsung Galaxy S3. Про другие врать не буду, пока лично не проверю! ��
Yours sincerely, Dmitry aka wcat

А в программном отношении USB OTG это просто USB или нет?

Насколько я знаю, нет. Нужны специальные драйвера. Бывает, что устройство оснащено USB OTG аппаратно, но программно возможность «общения» с внешними устройствами не поддерживается.

Зачем вообще эта глупость на планшетах? Обычный порт вполне бы подошёл как на нетбуках. Как и для usb типа В, так и для типа А есть варианты и мини, и микро. Через тип А нельзя подключать устройство к компу, но зачем вообще это надо? Мы же не подключаем нетбуки к компу через USB и не паримся по этому поводу. USB otg больше нужен телефонам, но планшет всё же ближе к нетбуку, чем к телефону.

Добрый день. при подключении планшета через USB OTG к ПК насколько свободно можно оперировать фалами на планшете?

USB-OTG — это всё извращение на самом деле, полезное, если только, для смартфонов на тот случай, когда понадобится к смартфону флешку подключить, но при этом сохранить возможность подключать смартфон к компу. Это, кстати, также является пережитком прошлого, из тех времён, когда не было флешек и приходилось покупать специальные кабеля для подключения телефонов к компьютерам. Ну, может быть остался в этом какой-то смысл, всё-таки не все компьютеры оснащены картридером для microSD-флешек. Вот это тот единственный случай, когда от USB-OTG есть реальная польза.

Использование же USB-OTG на планшетах — это реальный маразм, поскольку планшет подключать к компу смысла нет никакого, ибо есть встроенный wifi, нормального размера дисплей, короче говоря, есть возможность по-человечески работать в сети. А раз нет необходимости подключаться к компу, то, спрашивается, ЗАЧЕМ ВООБЩЕ НА ПЛАНШЕТЕ УСТАНАВЛИВАТЬ USB-ПОРТ ТИПА B? Это и есть главный вопрос, но такое впечатление, что производители воспринимают планшет как устройство более близкое к телефону, нежели чем к ноутбуку, по-другому эту глупость в виде установки USB портов типа B не объяснишь. Вполне себе замечательно можно было бы установить порт microUSB типа A и подключать к планшету не только флешки, но и принтеры, например: драйвера есть и для Windows, и для Android (ибо на Linux’e это дело собрано).

Салют,Колян! Ну вот я тоже пользовался флешками для передачи данных с телефона на планшет(и обратно).
Пока телефон перестал запускаться с флешкой.Теперь собрал один кабель,соединив по цветам два конца(папа-папа) с микроЮСБ,так как в продаже оного нет:-(.Не пойму,почему планшет на видит телефон,не появляется даже значок ЮСБ соединения.Может,что не правильно делаю?

Где можно приобрести нужные драйвера для отг?

Думаю, что в первую очередь стоит проверить сайт производителя гаджета, к которому нужны драйвера. Если там их нет, стоит связаться с их техподдержкой.