USB

Запросы, пакеты и транзакции

Модель передачи данных

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

Запросы, пакеты и транзакции

Для передачи или приема данных клиентское ПО посылает к каналу пакет запроса ввода/вывода — IRP (Input/Output Request Packet) и ждет уведомления о завершении его отработки. Формат IRP определяется реализацией драйвера USBD в конкретной ОС. В IRP имеются только сведения о запросе (местоположение буфера передаваемых данных в оперативной памяти и длина передачи); от свойств конкретного текущего подключения (скорость, допустимый размер пакета) драйвер устройства абстрагируется. Отработкой запроса в виде транзакций на шине USB занимается драйвер USBD; при необходимости он разбивает на части длинные запросы (пакеты), пригодные для передачи за одну транзакцию. Транзакция на шине USB — это последовательность обмена пакетами между хостом и ПУ, в ходе которой может быть передан или принят один пакет данных (возможны транзакции, в которых данные не передаются). Отработка запроса считается завершенной, когда успешно выполняются все связанные с ним транзакции. «Временные трудности», встречающиеся при их выполнении (неготовность к обмену данными), до сведения клиентского драйвера не доводятся — ему остается только ждать завершения обменов (или выхода по тайм-ауту). Однако устройство может сигнализировать о серьезных ошибках (ответом STALL), что приводит к аварийному завершению запроса, о чем уведомляется клиентский драйвер. В этом случае отбрасываются и все последующие запросы к данному каналу. Возобновление работы с данным каналом возможно лишь после явного уведомления об обработке ошибочной ситуации, которое драйвер устройства делает с помощью специального запроса (тоже вызова USBD).

Длинные запросы разбиваются на транзакции так, чтобы использовать максимальный размер пакета. Последний пакет с остатком может оказаться короче максимального размера. Хост-контроллер имеет средства обнаружения приема от устройства «неполновесного» пакета, размер которого меньше ожидаемого. В запросе IRP указывается, следует ли особым образом реагировать на это событие. Особая реакция может быть двоякой:

  • считать короткий пакет разделителем, указывающим на конец блока данных. При этом данный IRP завершается нормально и исполняются следующие запросы к данному каналу;
  • считать короткий пакет признаком ошибки, по которому канал останавливается (все его последующие ожидающие запросы сбрасываются).

При передаче массивов использование укороченных пакетов в качестве разделителей наиболее естественно. Таким образом, например, в одном из вариантов протоколов для устройств хранения данных укороченные пакеты известной длины используются в качестве управляющих.




Sitelinkx by eXtro-media.de
Яндекс.Метрика