Каналы
USB канал - соединение между конечной точкой на устройстве и программным обеспечением на хосте. Каналы представляют возможность перемещаться данным между программным обеспечением на хосте через буфер памяти и конечной точкой на устройстве. Есть два различных, взаимно исключающих, режима связи в канале:
- Поток. Данные, перемещающиеся через канал не имеют никакой определенной USB структуры.
- Сообщение. Данные, перемещающиеся через канал имеют некоторую определенную USB структуру.
- Требованием доступа на шине USB и использования пропускной способности.
- Тип передачи.
- Характеристики связанные с конечной точкой типа направление и максимальные размеры полезной нагрузки данных (The associated endpoint’s characteristics such as directional ity and maximum data payload sizes). Полезная нагрузка данных(The data payload) - данные, которые переносятся в полях данных, пакета данных внутри транзакции шины (как определено в Главе 8).
- Клиент может ожидать переменную с размером данных в IRP(A client can expect a variable sized amount of data in an IRP). В этом случае, короткий пакет, который не заполнит буфер данных IRP может использоваться просто как межзонный(inband) разделитель, чтобы указать “ конец модуля данных”.(In this case, a short packet that does not fill an IRP data buffer can be used simply as an inband delimiter to indicate “end of unit of data.” ) IRP нужно удалить без ошибки, и хост контроллер должен перейти к следующему IRP.
- Клиент может ожидать определенное по размеру количество данных. В этом случае, короткий пакет, который не заполнит буфер данных IRP - индицирует ошибку. IRP нужно удалить, канал должен быть остановлен, и любые задержанные IRPs связанные с каналом должны также удаляться.
USB не интерпретирует содержание данных, которые она доставляет по каналу. Даже при том, что канал сообщений требует, чтобы структура данных была согласована с определением USB, содержание данных не интерпретируется USB.
Дополнительно, каналы связаны с :
Каналы появляются, когда устройство USB сконфигурировано. Так как Конечная Точка 0 всегда сконфигурирована, как только устройство включается, всегда есть канал для Конечной Точки 0. Этот канал называется Создаваемый по Умолчанию Канал. Этот канал используется программным обеспечением системы, чтобы осуществить идентификацию устройства и определить требования к конфигурации, и сконфигурировать устройство(This pipe is used by system software to determine device identification and configuration requirements, and to configure the device). Создаваемый по Умолчанию Канал может также использоваться специфически программным обеспечением устройства после того, как устройство сконфигурировано. Программное обеспечение системы USB сохраняет право “монопольного использования” Создаваемого по Умолчанию Канала и добивается не(!!!) использования канала другим клиентским программным обеспечением(USB system software retains “ownership” of the Default Pipe and mediates use of the pipe by other client software.)
Клиентское программного обеспечения обычно запрашивает передачу данных в канале с помощью Пакетов Запроса Ввода - Вывода (IRPs) и затем или ждет или сообщает что они завершены (A software client normally requests data transfers via I/O Request Packets (IRPs) to a pipe and then either waits or is notified when they are completed). Подробности относительно IRPs определены в операционной системе специфическим способом. Эта спецификация использует термин простого обращения к запросу идентификации клиентским программным обеспечением для перемещения данных между собой (хостом) и конечной точкой устройства в соответствующем направлении(This specification uses the term to simply refer to an identifiable request by a software client to move data between itself (on the host) and an endpoint of a device in an appropriate direction). Клиентское программного обеспечения может заставлять канал возвратить все ожидающие обработки IRPs, если это требуется. Клиентскому программному обеспечению сообщают, что IRP завершен, когда транзакции шины, связанные с ним завершены или успешно или из-за ошибок.
Если нет никаких задержанных(pending) IRPs или движения в канале, то канал неактивен и хост контроллер не будет выполнять никаких действие относительно канала; то есть, конечная точка для такого канала не будет видна любыми транзакциями шины направленными к ней. Какие либо действия будут выполняться шиной связанные с каналом тогда, когда IRPs - задержаны для этого канала.
Если в не-изохронном канале происходит условие ОСТАНОВА(STALL) (обратитесь к Главе 8) или происходят три ошибки на шине в любом пакете IRP, IRP отменяется/удаляется, все ожидающие обработки IRPs также удаляются, и никакой последующие IRPs не принимаются, пока клиентское программного обеспечения не восстановится в рабочее состояния (в зависимости от способа заложенного при разработки) и подтвердит ОСТАНОВ(STALL) или условие ошибки через вызов USBD. Соответствующее состояние информирует клиентское программного обеспечения касательно специфического результата IRP для версий ошибки ОСТАНОВА (обратитесь к Главе 10)(An appropriate status informs the software client of the specific IRP result for error versus STALL ). Поведение при изохронном канале описано в Разделе 5.6.
IRP может требовать, чтобы несколько полезных нагрузок данных чтобы переместить данные клиента по шины (An IRP may require multiple data payloads to move the client data over the bus). Все данные заказанные IRP разбиваются на пакеты, все кроме последнего будут иметь максимально возможный размер пакета, последний содержит остаток от полного IRP. Рассмотрим описание каждого специфического типа передачи более подробно. Для такого IRP, короткие входные пакеты (то есть, меньшие, чем максимально установленый размер полезной нагрузки данных) полностью не заполняются, IRP буфер данных может иметь одно из двух возможных значений в зависимости от того что ожидает клиент(For such an IRP, short packets (i.e., less than maximum sized data payloads) on input that do not completely fill an IRP data buffer can have one of two possible meanings depending upon the expectations of a client).
Так как хост контроллер должен вести себя по-разному в двух случаях и он не может знать сам какой способ поведения выбрать для данного IRP, поэтому возможно указать в IRP желаемое поведение клиента.
Конечная точка может сообщать хосту, что она занята, отвечая NAK. NAKs не используются как условие удаления при возврате IRP клиентскому программному обеспечению.(NAKs are not used as a retire condition for returning an IRP to a software client.) Можно столкнуться с любом числом NAKs в течении обработки данного IRP. Ответ NAK не означает ошибку в транзакции и не считается одной из трех ошибок, описанных выше.
