|
Создание USB-устройств |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Создание
USB-устройств Одни из наиболее удобных качеств USB-устройств это возможность их «горячего» подключения, а также поддержка унифицированных механизмов самоидентификация и конфигурирования, закрепленных в стандарте. Самоиденификация и общая настройка USB-устройств реализуется посредством специальных требований – расширяемой системы команд протокола. Существуют стандартные – общие требования; требования, относящиеся к устройствам некоторых классов, таких, например, как HID-класс. Кроме этого устройства могут поддерживать дополнительные требования. Обеспечить поддержку необходимых требований – первоочередная задача при разработке USB-устройства. Кодирование требований USB Доставка требований осуществляется с помощью специально предназначенной для этого контрольной передачи. Схема обмена данными при контрольной передаче описана в предыдущей статье этой ветви обсуждения (часть 2.1). Напомним что полная транзакция такого вида передачи состоит из 3-х фаз: фазы SETUP, фазы даных и фазы статуса. Данные, идентифицирующие требование и его параметры, передаются в фазе SETUP в одноименном пакете фиксированной длины 8 байт. В формате пакета SETUP различают 5 полей (табл. 1). Таблица 1. Формат пакета SETUP
Поле bmRequestType несет в себе информацию о типе требования. Оно содержит 3 субполя. Его формат представлен в таблице 2. Таблица 2. Формат поля bmRequestType
Номера (значения поля bRequest) стандартных требований и некоторых требований, специфичных для USB-устройств класса HID приведены в таблице 3. В этой статье мы будем использовать некоторые термины, применяемые к устройствам HID-класса, без пояснений. Подробно они рассматриваются в отдельной статье, посвященной этой теме. Таблица 3. Коды стандартных требований и некоторых требований класса HID
Назначение полей wValue и wIndex варьируется в зависимости от требования. Поле wLength показывает какое количество информации должно быть передано в фазе данных. Направление передачи определяет старший бит поля bmRequestType (см. табл. 2). При разработке USB-устройств стандарт определяет возможность встроить поддержку новых требований. При этом обязательным является строгое соблюдение структуры поля bmRequestType и правильное использование поля wLength. Остальные поля разработчик может использовать по своему усмотрению, перед отправкой хост их не анализирует. При добавлении требования, которое будет поддерживать только один тип устройств , следует биты 6 и 5 поля bmRequestType устанавливать в значение 10b, что является признаком требования производителя (продавца). При добавлении требования, которое будет поддерживать целый класс устройств, будет логично описать это требование как принадлежащее классу, т.е. биты 6 и 5 выставить в значение 01b. СТАНДАРТНЫЕ ТРЕБОВАНИЯ Требование GET_STATUS (получить состояние) Требование GET_STATUS используется хостом для выясения состояния устройства, интерфейса или конечной точки. Еще раз отметим, что получатель требования указывается в младших 5-ти битах поля bmRequestType (см. табл. 2). В ответ на это требование соответствующий получатель возвращает 16-ти битное слово состояния. При обращении требования к устройству: l поле bmRequestType имеет значение 10000000b, что кодирует IN-передачу в фазе данных (бит 7 равен 1) стандартного требования (биты 6, 5 содержат 0), обращенного к устройству (биты 4-0 содержат 0); l поле wValue содержит 0 (как и для всех требований GET_STATUS – направленных любому получателю); l поле wIndex равно 0; l поле wLength равно 2 – закрепленный размер ответа на это требование в байтах для всех требований GET_STATUS, адресованного любому получателю. Устройство отвечает на это требование 16-ти битной посылкой, в которой старшие 14 бит зарезервированы для будущего использования и должны быть сброшены в ноль. Бит 1 называется RemoteWakeup и показывает возможность устройства самостоятельно сообщить хосту о выходе из приостановленного состояния. Как мы уже указывали при обсуждении общей организации шины USB, пробуждение ото «сна» от внешнего воздействия это единственный случай, когда устройство потенциально может начать передачу данных без приглашения хоста. Наличием такой возможности управляет флаг RemoteWakeup. Хост может сбрасывать и устанавливать этот флаг командами CLEAR_FEATURE и SET_FEATURE соотвественно. Бит 0 слова состояния устройства носит имя SelfPowered и показывает источник питания устройства: если бит установлен – устройство имеет независимый источник питания, сброшен – устройство питается от шины USB. Хост на способ питания устройства влияния не имеет. При обращении хоста с требованием GET_STATUS к интерфейсу: l поле bmRequestType имеет значение 10000001b (субполе получателя содержит код интерфейса); l поле wValue содержит 0; l поле wIndex содержит номер интерфейса. Номер интрефейса должен быть допустимым в рамках текущей установленной конфигурации. l поле wLength имеет значение 2. Интеррфейс передает 2-х байтную посылку, все биты которой сброшены в ноль и зарезервированы для будущего использования. Поля пакета требования GET_STATUS, адресованного точке имеют значения: l bmRequestType – 10000010b (получатель – точка); l поля wValue и wLength содержат типичные для этого требования значения – 0 и 2 соответственно; l wIndex содержит номер допустимой в текущем режиме работы устройства точки. Еще раз отметитм: контрольная точка 0 доступна в любом режиме работы устройства. В слове состояния точки зарезервированы и имеют нулевое значение 15 старших бит, а младший называется Halt и показывает возможность обмена bulk- и interrupt-точек. Если этот бит имеет установлен, значит точка находится в нетрудоспособном состоянии и на любые попытки хоста завязать с ней диалог отвечает отказом, высылая маркер STALL. Хост может управлять этой чертой с помощью команд CLEAR_FEATURE/SET_FEATURE. Требование CLEAR_FEATURE (очистить свойство) Посредством этого требования хост имеет возможность сбросить некоторые свойства устройства, интерфейса или конечной точки. Фаза данных в транзакции обработки этого требования отсутствует, поле wLength для него всегда нулевое. Поле bmRequestType аналогично такому для предыдущего требования с соответствующими получателями за исключением признака направления передачи в фазе данных. Для требования CLEAR_FEATURE и любого другого требования с отсутствующей фазой данных признак направления передачи в поле bmRequestType сброшен в 0 и кодирует несуществующую OUT-передачу в фазе данных. Напомним, что, во-первых, направление запросов в фазе статуса противоположно направлению запросов в фазе данных, а во-вторых, в отсутствии фазы данных запросы в фазе статуса имеют направление IN. Поле wIndex уточняет получатея требования. Для требования, обращенного к устройству это поле содержит 0. Для требования, направленного к интерфейсу, поле wIndex содержит номер интерфейса. Интерфейс с таким номером должен существовать в текущей активной конфигурации. Для требования CLEAR_FEATURE, адресованного конечной точке, wIndex задает адрес точки. Точка с таким адресом должна поддерживаться в текущей активной конфигурации. Поле wValue определяет свойство, которое необходимо очистить. Для устройства значение 1 в поле wValue означает, что нужно сбросить флаг RemoteWakeup. Это означает, что устройство теряет возможность уведомлять хост о выходе из приостановленного режима, т.е. теряет единственную возможность самостоятельно начать передачу не дожидаясь запроса хоста. Для конечной точки значение 0 говорит о том, что для нее необходимо сбросить флаг состояния Halt. Это означает перевод точки в рабочее состояние. При отработке этого требования для bulk-IN и interrupt-IN точек необходимо установить марекр DATA0 для следующего пакета данных. Требование SET_FEATURE (установить свойство) Требование SET_FEATURE противоположно требованию CLEAR_FEATURE по назначению и аналогично ему по структуре. Требованием SET_FEATURE хост заставляет получателя установить свойство, которое может быть сброшено аналогичным требованием CLEAR_FEATURE. Фаза данных при обработке этого требования также отсутствует, поле wLength для него всегда нулевое. Поле bmRequestType для требований SET_FEATURE, обращенных к устройству, интерфейсу и точке имеют соответственно значения 00000000b, 00000001b и 00000010b. Для требования, адресованного устройству, значение 1 в поле wValue указывает, что устройство должно установить флаг RemoteWakeup, поле wIndex при этом содержит 0. Установка флага RemoteWakeup означает, что устройство получает возможность самостоятельно оповещать хост о выходе из приостановленного режима вследствии внешнего воздействия. Во всех остальных случаях устройство имеет право начать передачу только с запроса хоста. Для устройств, работающих в высокоскоростном режиме, в поле wValue допустимо значение 2, обязывающее устройство перейти в тестовый режим и провести тест, номер которого указан в старшем байте поля wIndex. Для требования, адресованного интерфейсу, его номер указывается в поле wIndex. Интерфейс с таким номером должен существовать в активной конфигурации. Для требования, адресованного точке, ее адрес указывается в поле wIndex. Точка с таким адресом должна существовать в текущем режиме работы устройства. Значение 0 в поле wValue определяет, что для точки должен быть установлен флаг Halt. Установка этого флага означает для bulk- или interrupt-точки приостановку нормальной работы: на все запросы хоста она должна отвечать маркером STALL. Требование SET_ADDRESS (установить адрес) Требование SET_ADDRESS применяется для установки адреса устройству на шине. Корректными адресами на шине USB являются числа от 1 до 127, а также значение 0, указывающее что устройство является неадресованным. Новый адрес устройства оно получает в поле wValue данного требования. Фаза данных при обработке тебования SET_ADDRESS отсутствует – значение поля wLength равно нулю; поле wIndex не используется и содержит ноль. Получателем данного требования разумеется является только устройство, поле bmRequestType также содержит 0. Требование GET_DESCRIPTOR (получить описание) Требование GET_DESCRIPTOR используется для получения описаний определеного типа. Прежде всего стоит следует обратить внимание на следующее. Все описания, используемые в стандарте USB, можно условно разделить на два вида: l описания общего назначения, применяемые для всех USB-устройств; l описания, специфичные для USB-устройств некоторого класса, например, класса HID. Что касается требований GET_DESCRIPTOR на получение общих описаний, то для них получателем может быть только устройство, что закреплено в спецификации USB. При запросе специфичных описаний получателем требований может являться не только устройство. Например, при запросе HID-специфичных описаний, получателем требований является интерфейс, что закреплено в спецификации HID. Рассмотрим подробнее формат требования. Поле bmRequestType для требований GET_DESCRIPTOR содержит значения 100xxxxxb, где xxxxx – двоичный код получателя, которому адресовано требование. Получатели устройство и интерфейс кодируются значениями 00000 и 00001. Список всех кодов получателей для стандартных требований USB см. в табл. 2. Значения указанного вида в поле bmRequestType означают IN-передачу в фазе данных обработки стандартного требования, обращенного соответствующему получателю. Старший байт поля wValue определяет тип описания, которое требуется получить. Применяемые значения, их смысл, а также смысл младшего байта, уточняющего тип описания, приведены в табл. 4. Таблица 4. Коды типов описаний USB-устройств
Значения 0x06 и 0x07 применимы только для устройств, работающих в высокоскоростном режиме. Значения 0x21 и 0x22 применимы только для устройств HID-класса. В устройстве может быть несколько описаний типа конфигурация и строка, поэтому в младшем байте поле wValue задается индекс описания этого типа. Для других типов описаний младший байт не используется и должен быть нулевым. Поле wIndex нулевое для всех типов общих описаний кроме строки. Для строковых описаний в поле wIndex задается номер кодовой страницы. Если в качестве номера страницы будет задан 0, то устройство должно вернуть первое доступное описание строки с заданным индексом. Для HID-описаний поле wIndex содержит номер интрефейса, которому обращено требование. Длина описания заранее не известна, поэтому хост обычно считывает его за два этапа. На первом этапе он задает в поле wLength некоторое ориентировочное значение. Устройство в ответ на требование с таким прогнозируемым значением размера передает начальные wLength байт описания. Первым байтом описания (полный формат описаний мы рассмотрим в следующей статье) передается его размер. Далее хост, повторяет требование с уточненным значением поля wLength. Требование SET_DESCRIPTOR (установить описание) Применяется для установки описаний заданного типа. Это требование аналогично требованию GET_DESCRIPTOR по структуре его SETUP-пакета и противоположно ему по действию. Требование GET_CONFIGURATION (получить конфигурацию) Требование дает возможность получить номер текущей конфигурации устройства. Поле bmRequestType для этого требования равно 10000000b, а поле wLength содержит значение 1. Вместе эти поля передают, что хост расчитывает получить от устройства номер его активной конфигурации в фазе данных в посылке размером 1 байт. Возвращаемое значение 0 является признаком того, что устройство не сконфигурировано. Поля wValue и wIndex для этого требования не несут полезной информации и содержат нулевые значения. Требование SET_CONFIGURATION (установить конфигурацию) Это требование предназначено для установки конфигурации устройства. Поле bmRequestType содержит значение 00000000b, фаза данных при обработке этого требования отсутствует и поле wLength содержит нулевое значение. Поле wIndex не используется и также содержит нулевое значение. Номер устанавливаемой конфигурацтт передается в поле wValue. Установка конфигурации номер 0 означает деконфигурирование устройства. Описания доступных конфигураций хост получает в ответ на требование GET_DESCRIPTOR. При выборе доступной конфигурации отличной от 0, необходимо кроме того выполнить установку интерфейса 0 в данной конфигурации и альтернативной установки 0. Напомним, что любая конфигурация содержит хотя бы один интерфейс, а любой интерфейс содержит хотя бы одну альтернативную установку. Установка требуемых интерфейса и альтернативной установки осуществляется посредством требования SET_INTERFACE. Для всех bulk- и interrupt-точек направления IN в альтернативной требуется установить маркер DATA0 для следующего пакета данных. Флаг Halt сбрасывается для всех конечных точек. Требование GET_INTERFACE (получить интерфейс) С помощью этого требования хост может получить номер текущей альтернативной установки указанного интерфейса активной конфигурации устройства. Это требование хост адресует интрефейсу, от которого в фазе даных ожидает получить номер альтернативной установки в пакете данных размером 1 байт: поле bmRequestType имеет значение 10000001b, а поле wLength значение 1. Поле wValue не исполоьзуется, а поле wIndex содержит номер интерфейса, к которому обращено требоваание. Требование SET_INTERFACE (установить интерфейс) Требование SET_INTERFACE используется хостом для выбора альтернативной установки в заданном интерфейсе активной конфигурации устройства. Хост этим требованием обращается к интерфейсу, номер которого задан в поле wIndex, указывая ему установить альтернативную установку с номером, опреляемым полем wValue. Фаза данных при обработке этого требования отсутствует . Поле bmRequestType содержит значение 00000001b, а поле wLength – 0. Номера доступных интерфейсов и их альтернативных установок хост узнает с помощью требования GET_DESCRIPTOR. При смене альтернативной установки для всех bulk- и interrupt-точек IN-направления нужно установить маркер DATA0 для следующего пакета данных. Флаг Halt для всех точек сбрасывается. Требование SYNCH_FRAME (синхронизировать кадр) С помощью этого требования хост контролирует номер кадра синхронизации для конечной точки в изохронном режиме передачи с неявной синхронизацией. ТРЕБОВАНИЯ КЛАССА HID Свойства USB-устройств класса HID и основные понятия, применяемые к этому классу рассматриваются в отдельной статье, посвященной этой теме. В данной статье рассматриваются лишь некоторые основные требования для устройств HID класса. Требование GET_REPORT (получить репорт) Требование GET_REPORT позволяет хосту получить от устройства репорт – данные в специальном формате – через контрольную точку. Как это ясно из назначения требования, в транзакции его обработки используется фаза данных направления IN. Поле wLength содержит длину репорта. Поле bmRequestType имеет значение 10100001b, что кодирует требование класса, обращенное к интерфейсу, при обработке которого присутствует IN-фаза данных. Поле wIndex содержит номер интерфейса, к которому обращено требование. Поле wValue кодирует тип репорта – младший байт – и его идентификатор – старший байт. Идентификатор репорта может не использоваться: в этом случае старший байт репорта должен содержать 0. Для определения типа репорта используются следующие значения: l 1 – INPUT-репорт, l 2 – OUTPUT-репорт, l 3 – FEATURE-репорт, l значения 4-255 зарезервированы для будущего использования. Требование SET_REPORT (установить репорт) Это требование аналогично предыдущему по назначению и кодированию полей и противоположно ему по назначению: с помощью требования SET_REPORT хост может передать данные устройству через контрольную точку. Поле bmRequestType содержит значение 00100001b. В фазе данных направления OUT хост передает устройству репорт размером, указанном в поле wLength. В младшем байте поля wValue указывается тип репорта, в старшем – его идентификатор. Поле wIndex содержит номер интерфейса, к которому обращено требование.
Литература
начало... продолжение следует... Юрий Козлов Вячеслав Пронин |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
