заправка картриджей canon ip1900. Живые елки с доставкой доставка живых елок.
Благодаря универсальности и способности эффективно передавать разнородный трафик шина USB применяется для подключения к PC самых разнообразных устройств. Она призвана заменить традиционные порты PC — COM и LPT, а также порты игрового адаптера и интерфейса MIDI. Спецификация USB 2.0 позволяет говорить и о подключении традиционных «клиентов» шин ATA и SCSI, а также захвате части ниши применения шины FireWire. Привлекательность USB придает возможность подключения/отключения устройств на ходу и возможность их использования практически сразу, без перезагрузки ОС. Удобна и возможность подключения большого количества (до 127) устройств к одной шине, правда, при наличии хабов. Хост-контроллер интегрирован во все современные системные платы. Выпускаются и карты расширения с контроллерами USB (обычно для шины PCI). Некоторое время повсеместное применение USB сдерживалось недостаточной активностью разработчиков ПО (производителей оборудования): просматривая перечни устройств, можно было видеть, что для всех указывается поддержка в Windows 98/SE/ME, а вот в графах Linux, MacOS, Unix и даже Windows 2000/NT часто стоят неприятные пометки N/A (Not Allowed — «не дозволено»). В настоящее время ситуация меняется (теперь возникают проблемы поиска драйверов для Windows 9x), но вопросы совместимости ПО иногда доставляют дополнительные хлопоты.
Для того чтобы система USB заработала, необходимо, чтобы были загружены драйверы хост-контроллера (или контроллеров, если их несколько). При подключении устройства к шине USB ОС Windows выдает сообщение «Обнаружено новое устройство» и, если устройство подключается впервые, предлагает загрузить для него драйверы. Многие модели устройств уже известны системе, и драйверы входят в дистрибутив ОС. Однако может потребоваться и драйвер изготовителя устройства, который должен входить в комплект поставки устройства, или его придется искать в Сети. К сожалению, не все драйверы работают корректно — «сырой» драйвер начальной версии, возможно, потребуется заменить более «правильным», чтобы устройство нормально опознавалось и хорошо работало. Но это общее горе пользователей любых устройств, а не только устройств для шины USB.
Перечислим основные области применения USB:
Конечно же, перечисленными классами устройств сфера применения шины USB не ограничивается.
На современных системных платах имеется встроенный хост-контроллер USB; для плат, выпускаемых с 2002–2003 годов, характерно наличие контроллера USB 2.0 (EHC) с несколькими контроллерами-компаньонами (чаще UHC). Типовое число портов — четыре и более (раньше минимумом было два). В случае поддержки USB 2.0 эти порты могут быть как равноправными (поддерживать подключение на любой скорости), так и выделенными (часть — только HS, часть — FS/LS). Часть портов выводится на внешние разъемы системного блока непосредственно, остальные выводятся на штырьковые разъемы, расположенные на системной плате. К этим промежуточным разъемам внешние разъемы подключаются через кабели«выкидыши». К сожалению, на многих корпусах системного блока отсутствует штатное место для разъемов USB с лицевой стороны, что делает подключение устройств неудобным. Эта проблема решается установкой разъемов на заглушки для 5” или 3,5”отсеков.
ВНИМАНИЕ!
Из-за ошибок при подключении кабеля-«выкидыша» на дополнительных внешних разъемах могут оказаться перепутанными цепи +5V и GND. Из-за такой ошибки подключаемое устройство, питающееся от шины (например, флэш-память), может выйти из строя (сгореть).
Хабы USB выпускаются как в виде отдельных устройств, так и встраиваются в периферийные устройства (клавиатуры, мониторы). Как правило, хабы питаются от сети переменного тока (они должны питать подключаемые устройства). Выпускают и хабы, устанавливаемые внутрь системного блока компьютера и питающиеся от его блока питания. Такие хабы дешевле внешних и не требуют дополнительной питающей розетки. Один из вариантов исполнения — установка хаба на скобку, монтируемую в окно для дополнительных разъемов. Доступ к их разъемам со «спины» системного блока не очень удобен для пользователей. Другой вариант — хаб, устанавливаемый в 3-дюймовый отсек. Его разъемы легко доступны, индикаторы состояния портов хорошо видны, но не всегда удобны кабели, выходящие с передней панели системного блока. С другой стороны, для подключения электронных ключей (если их приходится часто менять) или миниатюрных накопителей этот вариант — самый удобный.
Выпускаются вспомогательные устройства USB, увеличивающие дальность связи (distance extender). Простейший вариант — это обычный 5-метровый кабель USB, на одном конце которого обычная вилка «A», а на другом — миниатюрный однопортовый хаб с гнездом «B». При необходимости между устройством USB и корневым хабом можно использовать цепочку из 5 таких удлинителей, что дает дальность 25 м плюс длина кабеля устройства (до 5 м). Другой вариант — пара устройств, соединяемых между собой обычным кабелем «витая пара» категории 5 (или даже оптоволокном), включаемая между периферийным устройством и корневым хабом. Дальнее (от хоста) устройство этого удлинителя может быть и хабом на несколько портов. К сожалению, увеличение дистанции упирается в ограничения на время задержки сигнала, свойственные протоколу шины USB, и максимально достижимое расстояние составляет 200 футов (около 60 м). Уже с удлинителем на 50 м дополнительные хабы недопустимы — задержка сигнала в кабеле «съедает» лимиты, отпущенные хабам в спецификации USB. Но даже и эта длина позволяет расширить сферу применения USB, например, для удаленного видеонаблюдения. Утверждения изготовителей о достижимой дальности 100 м (а на оптике и до 500 м!) вызывают некоторое недоверие, поскольку ограничения дальности в спецификации USB жестко ограничено установками тайм-аутов ожидания ответа, а быстрее света сигналы в кабелях разогнать не удается.
Далее рассматриваются подробности реализации взаимодействия по шине USB с устройствами некоторых классов. Эти примеры позволяют осмыслить прикладные возможности USB, их можно использовать как отправные точки для разработки собственных устройств, в том числе и совершенно оригинальных по функциональному назначению. Последний раздел главы посвящен разрешению проблем, возникающих при подключении устройств, в том числе и устройств собственной
разработки.
Класс и протоколы принтеров с интерфейсом USB определены документом «Universal Serial Bus Device Class Definition for Printing Devices», первая версия которого появилась в 1997 году, версия 1.1 — в 2000 г. Протоколы определены с учетом обеспечения легкого перехода от традиционных интерфейсов принтера: последовательного (RS-232, RS-422) и параллельного (однонаправленного Centronics или двунаправленного IEEE 1284). Подключение принтера USB эмулирует его подключение к LPT-порту в режиме SPP или двунаправленном (IEEE 1284). Классовое определение USB принтера не затрагивает данные, передаваемые принтеру: это может быть любой язык описания страниц (PDL — Page Descriptor Language). Принтеры могут работать только на скоростях FS или HS (на низкой скорости в USB нет передач массивов).
Принтер имеет все стандартные дескрипторы устройства USB, специфических классовых дескрипторов нет. В дескрипторе устройства принтер сообщает нулевые коды класса, подкласса и протокола. Принтер имеет по крайней мере одну конфигурацию; в конфигурации имеется один интерфейс. На уровне интерфейса для принтеров определен класс 07 подкласс 01. Код протокола определяется выбранной альтернатиной установки интерфейса:
В принтере используется (кроме нулевой) только одна конечная точка для вывода данных (Bulk-OUT), для двунаправленного интерфейса — еще и Bulk-IN для получения данных обратного канала (состояния).
Принтер поддерживает стандартные запросы к устройствам USB, кроме установки метки времени (у принтера нет изохронных точек). Кроме того, он должен поддерживать классовые запросы (см. таблицу).
По запросу Get_Device_Id принтер возвращает строку данных (Capabilities String), описывающих его в формате и синтаксисе, определенном в IEEE-1284. В запросе в поле wValue указывается номер интересующей конфигурации, старший байт wIndex задает номер интерфейса (0), младший — номер альтернативной установки. Возвращаемая строка начинается с 2-байтного поля длины всей строки (старший байт — первый), за которой идет собственно идентификатор.
Запрос | bmRequestType | bRequest |
Get_Device_Id | 10100001b | 0 |
Get_Port_Status | 10100001b | 1 |
Soft_Reset | 00100011b | 2 |
По запросу Get_Port_Status принтер возвращает байт состояния, аналогичный байту состояния LPT-порта. Здесь значимы только 3 бита (остальные — нули):
По запросу Soft_Reset принтер очищает свой буфер данных, переходит в исходное состояние, переводит в исходное состояние и разблокирует (если они были остановлены) конечные точки. На его состояние в плане интерфейса USB (адресован, сконфигурирован) этот сброс не влияет.
Для работы с USB-принтером следует считать дескриптор устройства и дескрипторы всех возможных конфигураций, выбрать конфигурацию и требуемую альтернативную установку интерфейса. При работе с двунаправленным интерфейсом некоторое неудобство вызывает тип конечной точки обратного канала (Bulk): запрос данных о состоянии принтера, который делает драйвер, будет «висеть» до срабатывания тайм-аута драйвера, если принтеру «нечего сказать». Формальное определение результатов запроса Get_Port_Status (по крайней мере, согласно спецификации версии 1.1) не позволяет судить о наличии данных в обратном канале. Однако, вспоминая работу LPT-порта, которую эмулирует подключение по USB, можно предположить, что признаком наличия данных обратного канала будет бит 3 (Not Error). В LPT-порту этот бит представляет текущее состояние сигнала Error#, который во всех режимах IEEE 1284 (исключая режим совместимости с SPP) используется для сигнализации наличия данных обратного канала.
Задача 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 и другие). Протокол передачи команд и данных работает следующим образом:
Если устройство получает недопустимый командный пакет, оно его отвергает соответствующим 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’ов).
Состояние выполнения команды может передаваться несколькими способами:
Данные передаются пакетами через точки 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, то прежний запрос прерывания устройство аннулирует.
К классу HID (Human Interface Device) относятся устройства, обеспечивающие интерфейс между человеком и компьютером:
Для этих устройств характерен небольшой объем передаваемых данных, возникающих для компьютера спонтанно (асинхронно), и умеренные требования к задержке обслуживания. К данному классу относятся и иные устройства с похожим характером данных (считыватели штрихкода, термометры, вольтметры и т. п.). Подробно данный класс описан в документе Device Class Definition for Human Interface Devices (HID), в 2001 году вышла его версия 1.11. Класс HID допускает работу устройств на любой скорости шины USB.
Деление на подклассы учитывает только необходимость поддержки данного устройства на этапе загрузки. Специальный код протокола выделяет только клавиатуру и мышь — стандартные устройства ввода.
С HID-устройствами хост обменивается сообщениями-рапортами (report), которые могут быть трех типов (Report Type):
Если устройство способно обмениваться разнообразными (не по типу, а по назначению) рапортами, то каждый рапорт начинается с байта идентификатора рапорта (Reprt ID). Например, комбинация клавиатуры с указателем может давать как рапорты нажатий клавиш, так и рапорты устройства-указателя.
Интерфейс HID-устройства обеспечивает двунаправленный обмен рапортами между устройством и драйвером. В нем имеется:
HID-устройства имеют специальный классовый HID-дескриптор, ссылающийся на дескриптор рапортов и набор физических дескрипторов (указываются тип и длина этих дескрипторов, что позволяет получить их по запросу Get_Descriptor).
Дескриптор рапорта представляет собой сложную структуру, описывающую передаваемые данные: назначение (ввод, вывод или управление свойствами), использование, диапазон допустимых значений, размер… Эта информация нужна драйверу HID-устройств, разбирающему (и собирающему) рапорты. Драйвер содержит модуль Item Parser, разбирающий, какому приложению следует передать тот или иной рапорт. Без должного дескриптора рапорта приложение рапорт ни принять, ни послать не сможет.
Набор физических дескрипторов описывает, какой частью тела человек воздействует на тот или иной орган управления. Эти дескрипторы необязательны и сообщаются не многими устройствами; они вносят дополнительные сложности в описание, хотя позволяют приложениям точнее использовать те или иные органы.
HID-устройства поддерживают все стандартные запросы к устройствам и специфические запросы, приведенные в таблице.
Запрос | bmRequestType | bRequest |
Get_Report | 10100001 | 01 |
Get_Idle | 10100001 | 02 |
Get_Protocol | 10100001 | 03 |
Set_Report | 00100001 | 09 |
Set_Idle | 00100001 | 0A |
Set_Protocol | 00100001 | 0B |
Запросы Get_Report и Set_Report служат для приема и передачи рапортов через EP0. Здесь в поле wValue старший байт задает тип рапорта, младший — его идентификатор. В поле wIndex задается номер интерфейса, поле wLength задает длину рапорта, который передается в фазе данных.
Запрос Set_Idle позволяет управлять подачей рапортов по каналу прерываний в случае отсутствия изменений состояния рапортуемых величин. Здесь в поле wValue старший байт задает длительность молчания в покое (idle duration), младший — идентификатор рапорта. В поле wIndex задается номер интерфейса, поле wLength = 0 (фаза данных отсутствует). Если задана нулевая длительность, то устройство будет передавать рапорты только в случае изменений состояния (что требуется, например, для клавиатуры). Ненулевое значение трактуется как длительность интервала (в 4-миллисекундных единицах), в течение которого точка Interrupt-IN отвечает на опросы NAK’ами, если нет изменений состояния. Так, например, можно уменьшить поток «пустых» данных опроса устройств-указателей (мыши или джойстика), не теряя быстроты реакции на события (задаваемая длительность и bInterval, задающий частоту опроса точки Interrupt-IN, независимы).
Запрос Get_Idle позволяет считать текущее значение длительности для рапорта, идентификатор которого задан в младшем байте поля wValue. В поле wIndex задается номер интерфейса, поле wLength = 1 (принимается один байт данных).
Запрос Set_Protocol (только для устройств, участвующих в начальной загрузке) позволяет переключать протокол работы устройства. Тип протокола задается в поле wValue: 0 — протокол (упрощенный), используемый при загрузке (Boot Protocol); 1 — нормальный протокол рапортов (Report Protocol). В поле wIndex задается номер интерфейса, поле wLength = 0.
Запрос Get_Protocol позволяет определить текущий протокол. В поле wIndex задается номер интерфейса, поле wLength=1 (принимается один байт данных).
Аудиоустройства с точки зрения USB представляют собой, как правило, композитные устройства, содержащие набор независимых интерфейсов. Путь любого аудиосигнала в аудиоустройстве начинается с входного терминала (Input Terminal) и заканчивается на выходном терминале (Output Terminal). Между терминалами могут находиться различные модули (Unit), осуществляющие какие-то преобразования и соединения.
Терминалы могут быть различных типов:
Всеми этими терминалами требуется управлять по шине USB; для них имеются дескрипторы, описывающие их управляемые свойства.
Модули (units), которые располагаются пути аудиосигнала, могут выполнять самые разнообразные функции: коммутация, регулировка уровня, микширование, панорамирование, фильтрация, реверберация и все возможные эффекты, которые стали легко реализуемыми с применением цифровой формы обработки сигналов. Для этих модулей введен подкласс 01 — AUDIOCONTROL, тоже со своими специфическими дескрипторами и запросами.
С аудиоустройствами тесно связаны и MIDI-устройства, являющиеся приемниками или источниками потоков MIDIсообщений. Для них введен подкласс 03 — MIDISTREAMING со своими специфическими дескрипторами и запросами. MIDIустройство USB может выступать как в роли простого конвертора интерфейсов (выполнять доставку сообщений между хостом и MIDI-разъемами на устройстве), так и MIDI-синтезатора, преобразующего MIDI-сообщения в аудиопотоки. При этом обрабатываться могут сообщения как с внешних разъемов, так и с шины USB. Синтезатор MIDI с точки зрения аудиоустройства является встроенным входным терминалом. Он поставляет аудиопоток, дальнейший путь которого определяется аудиоустройством (через интерфейсы подклассов 01 и 02).