link420 link421 link422 link423 link424 link425 link426 link427 link428 link429 link430 link431 link432 link433 link434 link435 link436 link437 link438 link439 link440 link441 link442 link443 link444 link445 link446 link447 link448 link449 link450 link451 link452 link453 link454 link455 link456 link457 link458 link459 link460 link461 link462 link463 link464 link465 link466 link467 link468 link469 link470 link471 link472 link473 link474 link475 link476 link477 link478 link479 link480 link481 link482 link483 link484 link485 link486 link487 link488 link489 link490 link491 link492 link493 link494 link495 link496 link497 link498 link499 link500 link501 link502 link503 link504 link505 link506 link507 link508 link509 link510 link511 link512 link513 link514 link515 link516 link517 link518 link519 link520 link521 link522 link523 link524 link525 link526 link527 link528 link529 link530 link531 link532 link533 link534 link535 link536 link537 link538 link539 link540 link541 link542 link543 link544 link545 link546 link547 link548 link549 link550 link551 link552 link553 link554 link555 link556 link557 link558 link559

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

USB

USB

Автоматическое конфигурирование

Все устройства подключаются через порты хабов. Хабы определяют подключение и отключение устройств к своим портам (см. главу 14) и сообщают состояние портов по запросу от контроллера. Хост своим управляющим запросом Port_Reset к хабу выполняет сброс и разрешает работу порта (одного!), на котором обнаружено новое подключение. При начальном подключении или после сброса устройство находится в «дежурном» состоянии (Default State) — отзывается только на обращения по основному каналу сообщений (EP0) и имеет нулевой адрес (USB Default Address). Таким образом, обращаясь к устройству по нулевому адресу, хост взаимодействует только с одним новоподключенным устройством. Хост стандартными запросами считывает дескрипторы этого устройства и назначает ему уникальный адрес на шине (1–127). Таким образом хост заполняет свой перечень подключенных устройств. По назначении уникального адреса устройство переходит в состояние «адресовано» (Addressed State), но его прикладное функционирование пока еще не разрешено. Полноценная работа устройства (прикладной обмен с хостом, полное потребление питания от шины) возможна только после управляющего запроса от хоста Set_Configuration, выбирающего конфигурацию из числа доступных — устройство переходит в состояние «сконфигурировано» (Configured State).

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

Когда устройство отключается, хаб автоматически запрещает соответствующий порт и сообщает об отключении хосту, который удаляет сведения о данном устройстве из всех рабочих структур данных (но не из реестра Windows!). Если отключается устройство-функция, уведомление посылается заинтересованному ПО. Если отключается хаб, процесс удаления выполняется для всех подключенных к нему устройств.



Транслятор транзакций

Транслятор транзакций, входящий в хаб USB 2.0, служит для преобразования скоростей обмена по шине: высокой (HS) на стороне восходящего порта в полную или низкую (FS/LS) на стороне нисходящих портов, к которым подключены устройства USB 1.x. Транслятор выполняет расщепленные транзакции ввода/вывода и транслирует маркеры микрокадров в маркеры кадров, передаваемые в порты FS.

Расщепление транзакций организуется хостом, который знает текущую топологию шины (к портам каких хабов USB 2.0 подключены устройства или хабы 1.x). Расщепленные транзакции выполняются в два-три этапа, в зависимости от типа и направления передачи:

  • между хостом и транслятором выполняется специальная транзакция Start Split (SS, расщепленный запуск). Она несет всю информацию, необходимую для запуска транзакции с целевым устройством. На этом этапе транслятор играет роль специфически адресуемого устройства USB;
  • между транслятором и целевым устройством (хабом) USB 1.0 выполняется обычная транзакция, в которой транслятор играет роль хост-контроллера;
  • между хостом и транслятором выполняется специальная транзакция Complete Split (CS, расщепленное завершение), которая доносит хосту результаты выполнения транзакции хаба с целевым устройством. Здесь транслятор также играет роль специфически адресуемого устройства USB. Для изохронного вывода этот этап отсутствует, поскольку никакого ответа от целевого устройства не предусмотрено.

Во всех этих транзакциях используется обычная «молчаливая» реакция на прием поврежденных пакетов и механизм тайм-аутов.

Каждый нулевой маркер микрокадра хаб транслирует в виде полноскоростного маркера кадра SOF. Расщепленные транзакции на стороне FS/LS выполняются внутри этих кадров. Старт расщепленных транзакций хост планирует на нулевой микрокадр, чтобы к концу последнего (седьмого) микрокадра расщепленная транзакция могла быть завершена и все данные оказались бы переданы (чтобы не накапливать переходящих остатков). Временные соотношения между транзакциями на обеих сторонах транслятора иллюстрирует рисунок, где в качестве примера рассмотрено расщепление транзакции ввода.

Общая структура транслятора транзакций приведена на следующем рисунке. HS-обработчик (HS Handler) помещает информацию расщепленных запусков в свои буферы, а по запросам завершений выбирает из буферов результаты и передает их в виде пакетов хосту. Этот обработчик отрабатывает все обычные функции протокола USB, включая генерацию и проверку CRC, посылку хосту подтверждений и т. п. F/LSобработчик (F/LS-Handler) по выбранным из буферов запросам запусков формирует обычные транзакции USB, начинающиеся с маркеров IN, OUT, SETUP (а для LSпортов и с преамбулы PRE). Результаты этих транзакций (данные и подтверждения) он помещает в буферы. Транслятор транзакций обладает буферами, в которых размещаются все необходимые данные о текущих выполняемых расщепленных транзакциях. По завершении транзакции (на обеих сторонах) буфер освобождается для обслуживания следующих расщепленных транзакций.

Периодические транзакции (изохронные и прерывания), критичные к времени выполнения, транслятором обрабатываются по конвейерной схеме. Данные запусков периодических транзакций помещаются в SS-буфер, из которого они выбираются F/LS-обработчиком (буфер реализует дисциплину FIFO) и запускаются в виде транзакций на вторичную шину. Результаты этих транзакций помещаются в CS-буфер (тоже FIFO), откуда их извлекает хост. За порядок наполнения и опустошения этих буферов отвечает хост — он планирует транзакции SS и CS. Транзакции запусков проходят без подтверждений со стороны транслятора; хост узнает о судьбе транзакции только в фазе завершения.

Непериодические транзакции (управление и передача массивов) обрабатываются иначе: у транслятора имеется два или более буфера B/C In/Out, каждый из которых обслуживает по одной транзакции, от начала и до конца. Здесь транзакции запусков подтверждаются транслятором: ответ NAK означает невозможность приема транзакции к исполнению (нет свободных буферов), то есть хосту следует повторить попытку запуска. Ответ ACK означает, что транзакция принята к исполнению и через некоторое время следует забрать результат, выполнив транзакцию завершения.

Спецификация предусматривает два варианта реализации транслятора; какой именно применяется, можно узнать из кода протокола интерфейса хаба:

  • по одному транслятору на каждый нисходящий порт (код протокола — 2); это самый производительный вариант для умножения пропускной способности шины для устройств FS/LS;
  • один транслятор на все порты (код протокола — 1); здесь возможности умножения пропускной способности зависят от объема буферов периодических транзакций и количества буферов для непериодических.

В расщепленных транзакциях фаза маркера, определяющая продолжение транзакции, состоит из двух пакетов-маркеров: специального маркера SPLIT, формат которого приведен в таблице, за которым следует маркер обычной транзакции (IN, OUT, SETUP). Пакет-преамбула PRE в расщепленных транзакциях не используется — скорость целевого устройства задается в маркере SPLIT, что позволяет хабу провести транзакцию на нужной скорости. Транслятор сам генерирует преамбулу, если вторичный порт, через который обращаются к LS-устройству, опознал FSподключение (это означает, что между хабом, транслирующим транзакцию, и целевым устройством есть хаб USB 1.x). Маркер SPLIT адресуется к порту хаба (номера в полях HubAddr и PortAddr), а следующий за ним обычный маркер адресует конечную точку целевого устройства. Маркеры SPLIT, используемые для запуска (SS) и завершения (CS) расщепленных транзакций, различаются полем SC: 0 — для SS, 1 — для CS. Поле ET описывает тип целевой конечной точки, с которой будет производиться транзакция (00 — Control, 01 — Isochronous, 10 — Bulk, 11 — Interrupt). Поля S и E трактуются по-разному. Для управляющих транзакций и прерываний поле S определяет скорость (0 — FS, 1 — LS), E = 0. Для остальных транзакций, кроме запуска изохронного вывода, поля S и E содержат нули. В транзакциях запуска изохронного вывода поля S и E трактуются как признаки начала и конца данных соответственно.

Таблица. Формат маркеров SPLIT

Поле Sync PID Check Hub Addr SC Port Addr S E ET SRC EOP
Длина, бит 32 4 74 7 1 7 1 1 2 5 8


«Универсальный» хост-контроллер — 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 от мощности и загрузки центрального процессора. Такой подход к организации ввода/вывода трудно назвать эффективным.



Устройства хранения данных

Задача USB для устройств хранения сводится к передаче устройствам команд, определяющих выполняемую операцию, получению от устройства информации о завершении исполнения команды и, наконец, транспортировке хранимых данных. Спецификация USB для устройств хранения (Mass Storage) определяет несколько подклассов и протоколов. Подкласс определяет содержимое командного блока, протокол — способ транспортировки команд, состояния и данных; подклассы и протоколы независимы (любой формат блока можно доставлять любым транспортом). Специальных классовых дескрипторов у устройств хранения нет, но есть два классовых запроса (см. таблицу).

Таблица. Классовые запросы к устройствам хранения

Запрос bmRequestType bRequest Применимость для протоколов
Get_Max_Lun 10100001b FEh 50h
Bulk-Only_Mass_Storage_Reset 00100001b FFh 50h
ADSC 00100001b 00 00, 01

Протокол Bulk-Only-транспорт (код 50h) применяется в устройствах хранения со скоростями FS и HS, он рекомендован для всех новых разработок. Этот протокол обеспечивает взаимную синхронизацию устройства и хоста, используя никак не синхронизируемые (системой USB) потоки независимых каналов Bulk-IN и Bulk-OUT через пару соответствующих точек. Кроме того, используются два классовых запроса для определения числа доступных логических устройств и сброса интерфейса.

По запросу Get_Max_LUN устройство возвращает байт с максимальным возможным номером логического устройства (LUN, нумерация с нуля). В запросе в поле wIndex указывается номер интерфейса, wLength = 1.

По запросу Bulk-Only_Mass_Storage_Reset выполняется сброс интерфейса, указанного в поле wIndex: точки Bulk-IN и Bulk-OUT разблокируются, переключатель (Toggle Bit) устанавливается в положение DATA0, интерфейс переводится в состояние ожидания команды, все предыдущие запросы сбрасываются.

Блоки команд и состояний распознаются в последовательности пакетов по фиксированной длине пакета (они всегда ложатся точно в один пакет), сигнатурам и соответствию содержимого полей соглашениям (проверяются и нули в резервных полях). Командный блок длиной до 16 байтов позволяет транспортировать любые наборы команд, используемые в устройствах хранения с традиционными интерфейсами (ATA/ATAPI, SCSI и другие). Протокол передачи команд и данных работает следующим образом:

  • хост посылает командный блок CBW (Command Block Wrapper) «в обертке» — пакет фиксированной длины (31 байт), включающий:
  1. 4-байтную сигнатуру (dCBWSignature = 43425355h);
  2. 4-байтный тег (dCBWTag), который служит для пометки и идентификации ответного блока состояния;
  3. 4-байтное поле длины передаваемых данных (dCBWDataTransferLength);
  4. байт флагов (bmCBWFlags), в котором используется лишь бит 7, указывающий направление передачи данных остальные биты — нули;
  5. байт с 4-битным номером логического устройства, к которому обращается данный командный блок (bCBWLUN в битах [3:0], остальные биты — нули);
  6. байт длины командного блока (bCBWCBLength в битах [4:0], допустимо 1–16,
  7. собственно командный блок (CBWCB) длиной от 1 до 16 байт и заполнитель, доводящий длину этого поля до 16 байт;
  • устройство подтверждает успех приема ACK’ом, анализирует пакет и, если «обертка» корректна и командный блок действителен, выполняет прием или передачу заказанного блока данных. Обмен данными инициирует хост в соответствии с посланной командой (данные могут и не предполагаться, тогда указывается их нулевая длина);
  • на каждый командный блок (после успешного исполнения или отвергая его) устройство отвечает блоком состояния CSW в аналогичной «обертке» — 13-байтным пакетом, содержащим:
  1. 4-байтную сигнатуру (dCSWSignature = 53425355h);
  2. 4-байтный тег (dCSWTag), привязывающий этот ответ к конкретному командному блоку;
  3. 4-байтное поле (dCSWDataResidue), в котором указывается разность между заказанным (и переданным) количеством данных и количеством, реально отработанным устройством;
  4. байт состояния (bCSWStatus) выполнения команды: 00 — успешно, 01 — отказ (failed), 02 — фазовая ошибка (нарушение последовательности команд и данных).

Если устройство получает недопустимый командный пакет, оно его отвергает соответствующим CSW (с байтом состояния 01). На каждый выпущенный командный пакет хост должен получить ответ — состояние с тем же тегом (теги назначает хост, устройство ими только метит ответ). Фазовая ошибка (нарушение этой последовательности) отрабатывается с помощью классового запроса «сброс интерфейса», передаваемого через EP0, — интерфейс переходит в исходное состояние (готов принять командный блок). Этим же сбросом устраняется возможная блокировка конечных точек.

Протокол Control-Bulk-Interrupt (CBI, коды 00 и 01) предназначен только для FSустройств, для новых разработок он не рекомендуется, на HS его применение не допускается. Для доставки команд служит классовый запрос ADSC (Access_Device_Specific_Command), передаваемый через точку EP0 (Основной канал сообщений). Для доставки данных используются точки Bulk-IN и Bulk-OUT. Через эти же точки (включая и EP0) передается и информация о состоянии завершения команды; в протоколе с кодом 00 для передачи состояний выделяется дополнительная точка Interrupt-IN с длиной пакета 2 байта.

Командный блок передается в фазе данных транзакции управления, реализующей запрос ADSC. В запросе в поле wIndex указывается номер интерфейса, wLength — длина командного блока. Положительное подтверждение (ACK) на стадии состояния означает, что команда успешно принята (этот ответ может быть задержан на неопределенное время посылкой NACK’ов).

Состояние выполнения команды может передаваться несколькими способами:

  • по прерыванию: когда у устройства есть что сообщит о состоянии выполнения команды, оно в транзакции с точкой Interrupt-IN возвращает два байта, трактовка которых зависит от подкласса устройства;
  • по основному каналу сообщений — устройство в фазе завершения может ответить пакетом STALL, что будет означать отвергнутую команду. Уточнить состояние можно, послав соответствующую команду, предполагающую получение состояния в фазе данных через точку Bulk-IN;
  • по каналу передачи данных: обнаружив ошибку в процессе выполнения команды, устройство на очередную транзакцию Bulk-IN/OUT ответит пакетом STALL. Уточнить состояние можно будет, послав следующий командный блок (предварительно разблокировав точки запросом Clear_EP_Halt).

Данные передаются пакетами через точки Bulk-IN и Bulk-OUT, укороченный пакет служит признаком конца блока данных. Хост и устройство отслеживают соответствие объема передаваемых данных запрошенному в команде. В случае обнаружения несоответствия устройство может сигнализировать об этом передачей состояния через точку Interrupt-IN или через ответ STALL в транзакциях передачи данных.

Сброс устройства можно выполнить, послав в запросе ADSC специальный командный блок с содержимым 1D, 04, FF, FF, FF... По этой команде устройство предпримет попытку безопасного прекращения текущей операции, очистит все буферы и очереди. После этого хост должен выполнить запросы Clear_EP_Halt, чтобы разблокировать точки и привести в исходное состояние переключатели Toggle Bit. Сброс через порт USB (по запросу к хабу) во время исполнения команды чреват потерей данных.

Прерывания (точка Interrupt-IN) используются только для протокола 00. На каждый посланный ADSC хост ждет прерывание; если устройство ответит на ADSC условием STALL, то для этой команды прерывание уже не ожидается. Если у устройства есть непереданный запрос прерывания, а хост посылает уже следующий ADSC, то прежний запрос прерывания устройство аннулирует.



Каналы

Коммуникационные каналы USB разделяются на два типа:

  • потоковый канал (streaming pipe) доставляет данные от одного конца канала к другому, он всегда однонаправленный. Один и тот же номер конечной точки может использоваться для двух разных потоковых каналов — ввода и вывода. Передачи данных в разных потоковых каналах друг с другом не синхронизированы. Это означает, что запросы клиентских драйверов для разных каналов, поставленные в определенном порядке друг относительно друга, могут выполняться другом порядке. Запросы для одного канала будут исполняться строго в порядке их поступления; если во время исполнения какого-либо запроса происходит серьезная ошибка (об этом устройство сообщает ответом STALL), поток останавливается. Поток может реализовывать передачи массивов, изохронные и прерывания. Потоки несут данные произвольного формата, определенного разработчиком устройства (но не спецификацией USB). В потоках типично использование транзакций, в которых длина поля данных соответствует максимальному размеру, допустимому для его конечной точки. Если требуется разделение потока на логические блоки данных, то это можно сделать, применяя в качестве признака конца блока укороченные пакеты. Если оказывается, что блок укладывается в целое число пакетов максимального размера, в качестве разделителя можно использовать пакеты с нулевой длиной поля данных;
  • канал сообщений (message pipe) является двунаправленным. Передачи сообщений во встречных направлениях синхронизированы друг с другом и строго упорядочены. На каждое сообщение противоположная сторона обязана ответить подтверждением его приема и отработки. Последующее сообщение не может быть послано до обработки предыдущего, но при отработке ошибок возможен сброс необслуженных сообщений. Форматы сообщений определяются спецификацией USB: имеется набор стандартных сообщений (запросов и ответов) и зарезервированных идентификаторов сообщений, формат которых определяется разработчиком устройства или интерфейса.

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

Каналы различаются и по назначению:

  • основной канал сообщений (Default pipe, он же Control pipe 0), владельцем которого является USBD, используется для доступа к конфигурационной информации всех устройств. Этот канал устанавливается с нулевой конечной точкой, EP0 (endpoint zero), которая у всех устройств всегда поддерживает только управляющие передачи;
  • клиентские каналы (Client pipes), владельцами которых являются драйверы устройств. По этим каналам могут передаваться как потоки, так и сообщения; они поддерживают любые типы передач USB (изохронные, прерывания, массивы и управление).

Интерфейс устройства, с которым работает клиентский драйвер, представляет собой связку клиентских каналов (pipe’s bundle). Для этих каналов драйверы устройств являются единственными источниками и потребителями передаваемых данных.

Владельцем основных каналов сообщений всех устройств является драйвер USB (USBD); по этим каналам передается информация конфигурирования, управления и состояния. Основным каналом сообщений может пользоваться и клиентский драйвер для текущего управления и чтения состояния устройства, но опосредованно через USBD. Например, сообщения, передаваемые по основному каналу, используются драйвером принтера USB для опроса текущего состояния (передаются три признака в формате регистра состояния LPT-порта: ошибка ввода/вывода, принтер выбран, отсутствие бумаги).

 



Подкатегории