Здесь опубликован перевод на русский язык уникального документа USB in a NutShell, облегчающего разработчикам всего мира первое знакомство с протоколом USB. Наилучшая точка старта для новичков, и неплохое средство прочистить мозги более опытным разработчикам (которым кажется, что они что-то знают). Если какие-то термины и сокращения будут непонятны, пользуйтесь разделом [Термины] в конце статьи.

[Глава 1: введение]

Начало работы с протоколом USB выглядит устрашающе. Например, одна только документация стандарта USB 2.0 на 650 страниц может оттолкнуть любого новичка. И это только начало длинного списка связанных стандартов для USB. Стандарты классов USB, как например HID Class Specification с общим описанием работы устройств (клавиатур, мышей, и т. д.), попадающих в класс HID (Human Interface Devices) – занимают еще 97 страниц. Если Вы разрабатываете USB хост, то нужно выбрать один из трех стандартов интерфейса хоста (Host Controller Interface Standards). Ни один из них не детализирован в спецификации USB 2.0.

Хорошие новости – нет необходимости читать весь стандарт USB. Некоторые главы вышли из стен маркетинга, другие посвящены нижнему уровню, о котором заботится Ваша микросхема USB контроллера и хост вместе с разработчиками хаба. Давайте немного попутешествуем по различным главам спецификации USB 2.0, и кратко рассмотрим основные моменты.

Теперь можно начать читать те части стандарта, которые нам действительно нужны. Если Вы разрабатываете драйвера (программное обеспечение) для периферии USB, то Вам понадобятся только следующие части:

• 4 - Обзор архитектуры
• 5 - Модель потока данных USB (Data Flow Model)
• 9 - Фреймворк устройства USB
• 10 - Аппаратура и программное обеспечение хоста USB.

Разработчикам железа периферии (электроника) понадобятся только следующие главы:

• 4 - Обзор архитектуры
• 5 - Модель потока данных USB (Data Flow Model)
• 6 - Механика
• 7 - Электрика.

USB in a NutShell для дизайнеров периферии

Теперь допустим (и это наверняка правда) что (1) большинство из нас разрабатывают периферию USB и (2) прочитали стандарт, но после этого в голове никаких идей по поводу того, как все-таки реализовать разрабатываемое устройство. В следующих 7 главах мы сфокусируемся на необходимых в разработке устройства USB частях стандарта. Это позволит Вам «воткнуться» в USB и производить дальнейшие разработки в соответствии с Вашим приложением (назначением устройства USB).

Стандарт USB 1.1 был недостаточно сложен для High Speed, и перерос в USB 2.0. Чтобы упростить понимание фундаментальных принципов USB, мы пропустим многое, касающееся непосредственно устройств USB High Speed.

Введение в Universal Serial Bus (USB)

USB версии 1.1 поддерживает две скорости – режим full speed 12 Mbits/s и режим low speed 1.5 Mbits/s. Режим 1.5 Mbits/s медленнее, и менее чувствителен к EMI (помехам), чем уменьшает стоимость ферритовых колец и снижает требования к качеству компонентов. Например, кварцы могут быть заменены на дешевые резонаторы. USB 2.0, который в настоящее время господствует для десктопов и ноутбуков, поднимает планку до 480Mbits/s. Эти 480Mbits/s обозначены как режим High Speed, и по этому параметру он может конкурировать с последовательной шиной Firewire.

Скорости USB

• High Speed - 480Mbits/s
• Full Speed - 12Mbits/s
• Low Speed - 1.5Mbits/s

Universal Serial Bus – шина, управляемая исключительно хостом. На шине допустим один и только один хост. Спецификация USB сама по себе не поддерживает любую форму мультихостинга. Однако в спецификации On-The-Go, появившейся в стандарте USB 2.0, введен протокол Host Negotiation Protocol, который позволяет двум устройствам USB договориться, кто будет выполнять роль хоста. Это предназначено и ограничено одиночными подключениями точка-точка, например мобильный телефон – персональный органайзер, и не распространяется на хабы и конфигурации компьютеров. Хост USB ответственен за то, что предпринял все транзакции и выбрал полосу пропускания. Данные могут быть посланы методами различных транзакций, используя token-based протокол (протокол, основанный на символах).

По моему мнению, шинная топология USB несколько ограниченная. Одной из начальных целей USB было уменьшение количества кабелей, воткнутых в заднюю (или переднюю) стенку Вашего PC. Приверженцы Apple могут сказать, что эта идея пришла от Apple Desktop Bus, где клавиатура, мышь и другая периферия могут соединяться друг с другом (по топологии daisy chain), с использованием одного кабеля.

Однако USB использует топологию «tiered star» (многоярусная звезда), похожую на топологию 10BaseT Ethernet. Это предполагает возможное использование хабов, что добавляет неудобства – больше коробочек на Вашем столе и большее количество кабелей. Но это не так плохо, как может показаться поначалу. Многие устройства имеют интегрированные в себя хабы. Например, Ваша клавиатура может содержать хаб, подключенный к компьютеру. Ваша мышь и другие устройства (цифровая камера и т. п.) могут быть просто воткнуты в клавиатуру. Многие мониторы также имеют встроенный хаб.

Топология tiered star имеет некоторые преимущества перед простой топологией daisy chain. Первое – потребляемая мощность каждого устройства может отслеживаться, и переключения, перегрузки не влияют на работоспособность других устройств USB. Все high, full и low speed устройства могут поддерживаться одновременно – хаб отфильтровывает транзакции high speed и full speed, таким образом устройства с низкими скоростями не получают данные со слишком высокой скоростью.

Одновременно к одной шине USB может быть подключено до 127 устройств. Нужно больше устройств? – просто добавьте другой порт/хост. Многие старые хосты USB имели 2 порта, и многие производители сочли это недостаточным, и начали производство 4 и 5 портовых карт хоста и материнских плат, с внутренними портами USB (например, для жестких дисков). Ранние хосты имели один контроллер USB, и два порта разделяли между собой доступную полосу пропускания USB. Поскольку требования к полосе пропускания росли, мы теперь видим многопортовые платы с двумя или больше контроллерами, позволяющими организовать отдельные каналы для данных.

Контроллеры хоста USB имеют собственные спецификации. В стандарте USB 1.1 имеется две спецификации Host Controller Interface:

• UHCI (Universal Host Controller Interface) – спецификация, разработанная Intel, которая перекладывает большинство функций на программное обеспечение (Microsoft) и позволяет применить дешевую аппаратуру.
• OHCI (Open Host Controller Interface) – спецификация, разработанная Compaq, Microsoft и National Semiconductor, где больше функций возложено на аппаратуру (Intel), что упрощает программное обеспечение. Типичное взаимодействие инженеров железа / программ. . .

С появлением USB 2.0 понадобилась новая спецификация Host Controller Interface Specification для описания деталей регистрового уровня, специфичного для USB 2.0. Родился EHCI (Enhanced Host Controller Interface). Известные поставщики включая Intel, Compaq, NEC, Lucent и Microsoft объединились вместе, чтобы предоставить нам один стандарт интерфейса, и таким образом, только один новый драйвер для реализации в операционных системах. Вовремя.

USB носит имя, подразумевающее последовательную шину. Она использует 4 экранированных провода, из которых два передают питание (+5v & GND). Остальные два представляют витую пару (twisted pair) дифференциальных сигналов данных. Используется схема кодирования NRZI (Non Return to Zero Invert, без возврата к нулю с инверсией) для передачи данных с полем синхронизации для синхронизирования тактов хоста и приемника.

USB поддерживает «горячее» (plug’n’play) соединение с динамически загружаемыми и выгружаемыми драйверами. Пользователь просто втыкает устройство, подключая его тем самым к шине. Хост детектирует присоединение, опрашивает только что установленное устройство и загружает подходящий драйвер, индицируя песочными часами на экране момент загрузки (если драйвер для устройства USB уже установлен в системе). Конечный пользователь не заботится ни о терминировании, ни об IRQ (прерываниях) и адресах портов, ни о перезагрузке компьютера (перезагрузка не требуется). Когда пользователь закончил работу с USB-устройством, он просто вынимает его (или отсоединяет кабель), хост обнаружит отсутствие устройства и автоматически выгрузит драйвер.

Загрузка (выбор) подходящего драйвера осуществляется по комбинации PID/VID (Product ID/Vendor ID). VID предоставляется организацией USB Implementor's forum за деньги, и это еще одна точка преткновения для USB. Последняя информация о ценах может быть найдена на сайте http://www.usb.org/developers/vendor/.

Другие организации по стандартам предоставляют дополнительные VID для некоммерческого использования, такого как обучение, разработка и прочее (радиолюбительство). USB Implementors forum все-таки должен оказать эту услугу. В этих случаях Вы можете использовать VID, назначенный поставщику системы разработки. Например, большинство производителей чипов имеют комбинации VID/PID, которые Вы можете использовать для Ваших чипов, и будет известно, что эти VID/PID не существуют в коммерческих устройствах. Другие производители чипов могут даже продать Вам для Вашего коммерческого устройства личный PID, чтобы использовать его с VID производителя.

Другая более достойная внимания особенность USB - его режимы передачи. USB поддерживает Control, Interrupt, Bulk и Isochronous передачи. В то время как мы будем смотреть на другие режимы передачи позже, Изохронный режим позволяет устройству резервировать определенную часть от полосы пропускания с гарантируемым временем ожидания (latency). Это идеально для аудио и видео приложений, где перегрузка канала может привести к заметной потере данных или понижению частоты кадров. Каждый режим передачи предоставляет разработчику компромиссы в области детектирования ошибок и восстановления, гарантированного времени ожидания и полосы пропускания.

[Глава 2: Железо]

Коннекторы

Все устройства имеют upstream-соединение к хосту, и все хосты имеют downstream-соединение к устройству. Коннекторы upstream и downstream механически не взаимозаменяемы, что устраняет недопустимые петлевые соединения на хабах, такие как подсоединение downstream-порта в downstream-порт. Обычно используют два вида соединителей, называемые type A и type B, которые показаны ниже.

Type A USB Connector (сокет, нумерация контактов при виде снаружи)		Type B USB Connector (сокет, нумерация контактов при виде снаружи)

Type A plug (т. е. папа) всегда обращен к upstream (т. е. к хосту). Type A socket (т. е мама) обычно можно найти на стенке хоста и хаба. Например, сокеты type A расположены на компьютерных материнских платах и хабах. Type B plug всегда соединяются с downstream и, следовательно, type B socket расположены на USB устройствах. На первый взгляд звучит довольно путано, но разобраться можно =).

Интересно обнаружить в некоторых компьютерных магазинах кабели type A <--> type A с прямой разводкой проводов и многочисленные зарядники USB-типа. Это входит в противоречие со спецификацией USB. Устройства, являющиеся переходником между штеккером type A в штеккер type A являются мостом, используемым для соединения двух компьютеров друг с другом. Другие запрещенные кабели – удлинители USB, имеющие на одном конце штеккер (либо type A, либо type B) и сокет на другом конце (либо type A, либо type B). Эти кабели нарушают требования к длине кабелей USB.

USB 2.0 включает в себя errata, которое представляет коннекторы mini-usb B. Подробная информация по этим коннекторам может быть найдена в Mini-B Connector Engineering Change Notice. Причина появления коннекторов mini появилась для применения USB в малогабаритных электронных устройствах типа мобильный телефоны и органайзеры. Обычный коннектор type B слишком большой, чтобы его можно было просто применить в этих устройствах.

Совсем недавно была разработана спецификация On-The-Go, которая добавляет для USB функциональность peer-to-peer. Она представляет хосты USB в мобильных телефонах и электронных органайзерах, и таким образом включена спецификация для mini-A джеков, mini-A разъемов и mini-AB разъемов. Я предполагаю, что скоро получат широкое распространение кабели mini USB, и также набор кабелей-конвертеров mini в standard.

В кабелях USB используется стандартная цветовая маркировка для изоляции внутренних проводников, что упрощает идентификацию проводов от производителя к производителю. Стандарт регламентирует различные электрические параметры для кабелей. Интересно подробно прочитать включенные оригинальные спецификации USB 1.0. Вы бы разобрались в указанных электрических атрибутах, но параграф 6.3.1.2 предлагает рекомендованный цвет для заполнения кабелей USB морозный белый – как скучно! USB 1.1 и USB 2.0 послабляют рекомендации на Черный, Серый или Натуральный.

Разработчики PCB в части 6 стандарта найдут стандартные посадочные места и цоколевки коннекторов.

Электрическая спецификация

Вам не нужны электрические спецификации главы 7, за исключением если Вы не разрабатываете чипы USB устройств/трансиверов или USB хост/хаб. Мы бегло рассмотрим основные вопросы этой главы.

Как мы уже упоминали, USB использует для передачи данных пару проводов. Для кодирования применяется принцип NRZI (Not Return Zero Invert – без возврата к нулю с инверсией), и применяется вставка бит (bit stuffing), чтобы обеспечить нужные изменения уровня в потоке данных. На низкоскоростных (low speed) и полноскоростных (full speed) устройствах дифференциальная ‘1’ передается путем повышения уровня D+ свыше +2.8V резистором 15КОм, подключенным к +3.6V и D- ниже +0.3V резистором 1.5КОм, подключенным к земле. Дифференциальный ‘0’ передается тем же способом, только уровни меняются на противоположные - D- свыше 2.8V и D+ ниже 0.3V. Приемник распознает дифференциальную ‘1’, если уровень D+ больше на 200mV, чем D-, и дифференциальный ‘0’, если D+ на 200mV меньше, чем D-. Полярность сигнала инвертируется в зависимости от скорости шины. Термины состояний ‘J’ и ‘K’ используются для обозначения логических уровней. На low speed состояние ‘J’ – дифференциальный 0. На high speed состояние ‘J’ – дифференциальный 1.

Трансиверы USB имеют одновременно дифференциальные и несимметричные одиночные (single ended) выходы. Определенные состояния шины обозначены несимметричными сигналами на D +, D- или обоими сразу. Например, сигнал SE0 несимметричный и может использоваться для обозначения сброса устройства, если он удерживается дольше 10 мс. Сигнал SE0 генерируется путем удержания и D- и D+ в низком уровне (< 0.3V). О реализации несимметричных и дифференциальных выходов важно знать, если Вы используете трансивер и FPGA в качестве устройства USB. Вы не можете осуществить работу только с помощью дифференциального выхода.

Шина low speed/full speed имеет волновое сопротивление (characteristic impedance) 90 Ом +/- 15%. Таким образом, важно просмотреть даташит при выборе сопротивлений последовательных резисторов для D+ иD-. В любом хорошем даташите указаны величины сопротивлений и допуски на них.

Режим High Speed (480Mbits/s) использует постоянный ток 17.78 mA для передачи сигналов – с целью уменьшения шума.

Идентификация скорости

Устройство USB должно показать свою скорость путем подвешивания линии D+ или D- к напряжению 3.3V. Устройство full speed, как показано на картинке ниже, использует pull up резистор, подключенный к D+ для указания хосту, что это устройство full speed device. Резисторы pull up на стороне устройства используются хостом или хабом для определения присутствия устройства на шине (подключено ли устройство в порт USB). Без pull up резистора считается, что к шине USB ничего не подключено. Некоторые устройства имеют этот резистор встроенным в чип (он может включаться и выключаться программно под управлением firmware), другие требуют наличия внешнего резистора.

Возьмем для примера технологию SoftConnectTM Philips Semiconductor. При подключении к шине микроконтроллер инициализирует функцию устройства USB перед тем, как подключить pull-up резистор для идентификации скорости, показывающий, что устройство подключено к шине. Если pull up резистор был подключен к Vbus, то это означает, что устройство сразу подключается к шине, как только оно воткнуто в порт USB. В этом случае хост может попытаться сбросить устройство и запросить дескриптор, когда микроконтроллер устройства еще не проинициализировал функцию устройства USB (не готов в обработке запросов USB).

Другие вендоры, такие как Cypress Semiconductor, также используют программируемый резистор для технологии Re-NumerationTM в своих устройствах EzUSB, где устройство при подключении сначала определяется как программируемое устройство USB, а потом, после загрузки в устройство программного обеспечения, отключается от шины и под управлением загруженного firmware проходит энумерацию как другое устройство USB (все это происходит незаметно для пользователя). Многие устройства EzUSB не имеют встроенной памяти Flash или OTP ROM для сохранения кода. Они загружают код через подключение по USB.

Рисунок 2: USB устройство Full Speed имеет pull up резистор, подключенный к D+

Рисунок 3: USB устройство Low Speed имеет pull up резистор, подключенный к D-

Обратите внимание, что мы не рассматривали идентификацию скорости для режима High Speed. High speed начинают работу путем подсоединения на full speed (1.5k на 3.3V к сигналу D+). После установления соединения и сброса устройство переходит к соединению на high speed, если хаб или хост поддерживает это. Если резистор работает в режиме high speed, резистор pull up отключается для сохранения баланса линии.

Для совместимости устройства с USB 2.0 не требуется поддержка режима high-speed. Это позволяет производить более дешевые устройства, если скорость не важна. Это также имеет место для USB 1.1 low speed устройства, которое не обязано поддерживать full speed.

Однако высокоскоростное устройство не должно поддерживать режим низкой скорости. Оно должно только поддержать режим full speed для первого соединения, и затем перейти в режим high speed после успешного взаимодействия. USB 2.0 совместимое downstream устройство (хаб или хост) должен поддерживать все три режима - high speed, full speed и low speed.

Питание (VBUS)

Одна из выгод USB – устройства, питаемые от шины (bus-powered devices) – устройства, которые могут получать питание от шины и не требовать никаких дополнительных джеков или кабелей. Однако многие путаются в этой опции без рассмотрения нужных критериев.

USB устройство указывает свое энергопотребление в единицах 2mA в дескрипторе конфигурации, который мы будем детально рассматривать далее. Устройство не может увеличить энергопотребление свыше величины, указанной при энумерации, даже если у него пропадет внешнее питание. Имеется 3 класса функций USB:

• Low-power питаемые от шины функции
• High-power питаемые от шины функции
• Self-powered функции (с собственным отдельным питанием)

Low power питаемые от шины функции получают питание полностью только от VBUS и не могут потреблять больше, чем 1 юнит нагрузки (one unit load). Спецификация USB задает в качестве юнита нагрузки 100mA. Low power питаемые от шины функции должны быть также разработаны таким образом, чтобы могли работать при снижении напряжения на VBUS до 4.40V и повышении до 5.25V, замеренных на upstream коннекторе устройства. Для большинства устройств 3.3V обязательно применение LDO регуляторов.

High power питаемые от шины функции получают питание только от USB и не могут потреблять больше, чем 1 юнит нагрузки, пока они не будут сконфигурированы хостом, после чего они могут потреблять до 5 юнитов нагрузки (500mA Max), предоставленных в соответствии с запрошенной величиной из дескриптора. High power питаемые от шины функции должны быть способны проходить детектирование и энумерацию при напряжении минимум 4.40V. Когда проходит работа с полной нагрузкой, то минимум для VBUS составляет 4.75 V, и максимум 5.25V. Здесь также измерения происходят с разъема upstream.

Самопитаемые функции (self power functions) могут потреблять от шины до 1 юнита нагрузки и получать остаток мощности от внешнего источника. При пропадании внешнего источника питания должна быть обеспечена возможность потребления от шины USB не больше, чем 1 юнит нагрузки. Самопитаемые функции проще в разработке, поскольку отсутствуют проблемы с потребляемой мощностью. Одноюнитовая нагрузка на шину позволяет проводить детектирование и энумерацию без основного/дополнительного источника питания.

Никакое устройство USB, независимо от типа питания не должно подавать питание на провод VBUS на своем upstream порту. Если VBUS пропадет, устройство должно в течение 10 секунд убрать питание с D+/D- pull-up резисторов, используемых для идентификации скорости.

Другое условие использования VBUS - пусковой ток, который должен быть ограничен. Это выделено в параграфе 7.2.4.1 спецификации USB и обычно пропускается. Пусковой ток происходит из-за наличия электрической емкости в Вашем устройстве между VBUS и землей. Поэтому спецификация указывает максимально допустимую развязывающую емкость, которую Вы можете иметь в своем устройстве - 10uF. Когда Вы отключаете устройство, возникает ЭДС самоиндукции от протекающего тока (за счет индуктивности кабеля USB), которая может достичь большой величины. Для защиты от этого должна присутствовать минимальная развязывающая емкость 1uF на VBUS.

Типичное питаемое от шины устройство не может потреблять ток свыше весьма разумной величины - 500mA. Вы можете спросить – какие осложнения тут могут быть? Может, Suspend Mode (режим приостановки)?

Потребление в режиме приостановки (Suspend Mode)

Suspend mode обязателен для всех устройств. Во время приостановки вступают в силу дополнительные ограничения. Максимальный ток приостановки пропорционален номинальной нагрузке в юнитах. Для устройства с током нагрузки в 1 юнит максимальный ток приостановки (по умолчанию) 500uA. Это включает ток от pull up резисторов на шине. В хабе имеются на обеих линиях D- и D+ pull down резисторы по 15 КОм. Эти pull down резисторы вместе с последовательно включенным резистором в устройстве (1.5 КОм pull up) создают общую нагрузку 16.5 КОм на VTERM обычно 3.3v. Таким образом, этот резистор потребляет 200uA еще до старта.

Кроме того, нужно принимать во внимание для многих устройств регулятор 3.3V. Многие устройства USB работают от 3.3V, например - PDIUSBD11. Линейные регуляторы обычно весьма неэффективны при средних статических электрических токах порядка 600uA, поэтому требуются более эффективные и, таким образом, дорогие регуляторы. В большинстве случаев Вы должны также уменьшить тактовую частоту микроконтроллера или совсем остановить тактовую частоту микроконтроллера, чтобы уложиться в предел 500uA.

Примечание переводчика: многие разработчики firmware не утруждают себя обработкой режима Suspend. Например, среди разработок, основанных на библиотеке V-USB, мне не попадались проекты с поддержкой режима Suspend.

Многие разработчики на форуме USB Implementor's Forum спрашивают – какие проблемы произойдут, если превысить лимит тока Suspend? Само собой разумеется, что большинство хостов и хабов не могут обнаружить перегрузку такой величины, и следовательно Ваше устройство может потреблять ток 5 мА и даже 10 мА и при этом нормально работать – но все-таки Вы при этом нарушаете требования спецификации USB. Однако при нормальном функционировании (не в режиме Suspend), если Вы пытаетесь превысить на 100mA Вашу определенную допустимую нагрузку, то хаб или хост наверняка обнаружат это и отсоединят Ваше устройство в интересах целостности шины.

Конечно, этих вопросов проектирования можно избежать, если Вы хотите спроектировать устройство USB с собственным питанием. Токи Suspend не имеют значения для десктопов, но с введением спецификации On-The-Go хостами USB могут стать мобильные телефоны и мобильные органайзеры. Лишнее потребление энергии Вашими USB устройствами произведет неблагоприятный эффект на время работы мобильного устройства от батареи.

Вход в Suspend Mode

Устройство USB приостанавливается (переходит в режим Suspend), когда на шине нет активности более чем 3.0 мс. В течение следующих 7 мс устройство должно отключиться, и не потреблять ток больше, чем заданный ток suspend. Таким образом, через 10 мс после прекращения активности шины ток потребления от неё не должен превышать suspend current. Для поддержания состояния соединения к приостановленному хабу или хосту, устройство во время режима Suspend должно все еще предоставлять питание на pull up нагрузочный резистор, определяющий выбор скорости.

У USB есть пакет start of frame (SOF), который строго периодично (каждые 1 мс для low speed и full speed) посылается на шину для поддержания её в активном состоянии. Это препятствует тому, чтобы шина стала неактивной (вошла режим приостановки) при отсутствии данных на шине.

• Шина high speed имеет микрофреймы, отсылаемые каждые 125.0 µs ±62.5 ns.
• Шина full speed отправляет фрейм каждые 1.000 ms ±500 ns.
• Шина low speed имеет keep alive EOP (End of Packet) каждые 1ms только в случае отсутствия любых low speed данных.

Термин "Global Suspend" используется, когда вся шина USB входит в режим suspend целиком. Однако также может быть приостановлено выбранное устройство путем посылки команды хабу, куда подключено устройство. Это называют как "Selective Suspend."

Устройство возобновит работу, как только примет любой «не idle» сигнал. Если устройство имеет возможность удаленного пробуждения (remote wakeup enabled), то оно может сигнализировать хосту о необходимости выхода из режима Suspend (resume).

Скорость сигнала данных (Data Signalling Rate)

Другая область, которая часто пропускается, является допуск на такты USB. Эта информация имеется в секции 7.1.11 спецификации USB.

• High speed data тактируются 480.00Mb/s с допуском на скорость ± 500ppm.
• Full speed data тактируются 12.000Mb/s с допуском на скорость ±0.25% или 2,500ppm.
• Low speed data тактируются 1.50Mb/s с допуском на скорость ±1.5% или 15,000ppm.

Эти допуски позволяют для устройств low speed применять недорогие резонаторы, но исключает их для full speed или high speed устройств.

[Глава 3: протоколы USB]

В отличие от RS-232 и похожих последовательных интерфейсов, где формат отправляемых данных не задан, USB составлен из нескольких слоев протоколов. Звучит сложно, но не опускайте руки. Как только поймете, что происходит, нужно беспокоиться только о протоколах верхних уровней. Фактически большинство контроллеров USB берет на себя заботу о нижних уровнях протоколов, делая их невидимыми для конечного разработчика.

Каждая транзакция USB состоит из:

• Token Packet (заголовок, показывающий – что должно передаваться далее)
• необязательный Data Packet (содержит полезный payload)
• Status Packet (используется для подтверждения транзакций и предоставляет средство устранения ошибок)

Как мы уже упоминали - USB является шиной, где главным является хост. Хост начинает все транзакции. Первый пакет, так называемый token, генерируется хостом для описания того, что проследует далее и будет ли это транзакция чтения или записи, и какой адрес устройства и определенная конечная точка (endpoint). Следующий пакет обычно пакет данных, несущий полезную нагрузку, за которым идет пакет рукопожатия (handshaking packet), сообщающий о том, что данные или token были приняты успешно, или конечная точка (endpoint) остановлена (stalled) или недоступна для принятия данных.

Общие поля пакета USB

Данные на шине USB передаются в таком порядке: первым идет LSB (Least Significant Bit, младший значащий бит). Пакеты USB состоят из следующих полей:

• Sync

Все пакеты должны начинаться с поля синхронизации (sync). Поле sync имеет длину 8 бит на low speed и full speed или 32 бита на high speed, и используется для синхронизации тактов приемника с тактами передатчика. Последние 2 бита показывают, где начинается поле PID.

• PID

PID означает Packet ID. Это поле используется для обозначения типа пакета, который сейчас отправляется. Следующая таблица показывает возможные значения этого поля.

У PID здесь 4 бита, однако чтобы обеспечить его правильный прием, 4 бита дополнены (complemented) и повторены, в результате получился 8-битный PID. Полученный формат показан ниже:

• ADDR

Поле адреса указывает, какому из устройств USB предназначен пакет. Адрес имеет длину 7 бит, что позволяет адресовать до 127 поддерживаемых одновременно устройств. Адрес 0 недопустим, он предназначен для устройств, адрес для которых пока не назначен. Любое устройство, которому не назначен адрес, должно отвечать на пакет с адресом 0.

• ENDP

Поле endpoint составлено из 4 бит, что позволяет 16 возможных конечных точек. Однако устройства low speed могут иметь только 2 дополнительные конечные точки сверх заданного по умолчанию канала (4 конечных точки максимум).

• CRC

Cyclic Redundancy Checks (Циклическая Избыточная проверка) выполняется над данными в пределах полезной нагрузки пакета. Все пакеты token имеют 5 бит CRC, а пакеты data имеют 16 бит CRC.

• EOP

End of packet, конец пакета. Сигнализируется несимметричным нулем (Single Ended Zero, SE0) на время примерно 2 бита, и далее следует состояние J длительностью 1 бит.

Типы пакетов USB

USB имеет 4 разных типа пакета. Пакеты token индицируют тип последующей транзакции, пакеты data содержат payload, пакеты handshake используются для подтверждения данных или сообщений об ошибках, и пакеты start of frame (SOF) показывают начало нового фрейма.

• пакеты Token

Имеется 3 типа пакетов token:

In – информируют устройство USB о том, что хост хочет прочитать информацию.
Out - информируют устройство USB о том, что хост хочет отправить информацию.
Setup – используется для начала управляющих передач (control transfers).

Пакеты token должны удовлетворять следующему формату:

• пакеты Data

Имеется 2 типа пакетов данных, каждый из которых может передать до 1024 байта данных.

Data0
Data1

Режим High Speed задает два других data PID - DATA2 и MDATA.
Пакеты Data имеют следующий формат:

Максимальный размер полезной нагрузки (payload) для low-speed устройств составляет 8 байт. Максимальный размер полезной нагрузки для full-speed устройств составляет 1023 байт. Максимальный размер полезной нагрузки для high-speed устройств составляет 1024 байт. Данные нужно послать в единицах байт.

• пакеты Handshake

Имеется 3 типа пакетов handshake, которые состоят просто из PID

ACK – подтверждение о том, что пакет успешно принят. NAK – сообщение о том, что устройство временно не может отправить или принять данные. Также используется в interrupt транзакциях для информирования хоста о том, что нет никаких данных для передачи. STALL – устройство находится в состоянии, которое требует вмешательства со стороны хоста.

Пакеты handshake имеют следующий формат:

• пакеты Start of Frame (SOF)

Пакет SOF состоит из 11-битного номера фрейма, отсылаемого хостом каждые 1ms ± 500ns на full speed или каждые 125 µs ± 0.0625 µs на high speed.

Функции USB

Когда мы представляем себе устройство USB, мы думаем о нем как о периферийном устройстве USB, но устройство USB могло означать USB трансивер, используемый в хосте или периферии, USB хаб или микросхему контроллера хоста, или периферийное устройство USB. Поэтому стандарт ссылается на функции USB, которые можно видеть как USB устройства, которые обеспечивают определенный функционал наподобие принтера, Zip-драйва, сканера, модема или другой периферии.

Сейчас мы уже должны знать ряд понятий, составляющих пакет USB. Нет? Вы уже забыли, сколько бит входит в поле PID? Не будьте слишком обеспокоены этим. К счастью, большинство функций USB уже в кремнии (специальных чипах) получают обработку низких уровней протокола USB (до слоя транзакций, который мы рассмотрим в следующей главе). Мы рассматриваем информацию о низких слоях протокола USB потому, что большинство контроллеров функций USB сообщают об ошибках, таких как PID Encoding Error. Не рассмотрев бегло низкий уровень, можно было бы спросить, что означает PID Encoding Error? Если бы Вы предположили, что последние четыре бита PID не соответствовали инверсии первых четырех битов, то Вы были бы правы.

У большинства функций есть серия буферов, обычно 8 байт длиной. Каждый буфер будет принадлежать конечной точке (endpoint) - EP0 IN, EP0 OUT и т. п.. Например, хост отправляет запрос дескриптора устройства (device descriptor request). Функция аппаратно прочитает пакет setup и определит из поля адреса, предназначен ли пакет именно ей, и если да, то скопирует полезную нагрузку (payload) последующего пакета данных в соответствующий буфер конечной точки, заданный величиной в поле endpoint токена setup. Также отправится пакет handshake для подтверждения приема байта и сгенерируется внутреннее прерывание в микроконтроллере для соответствующей конечной точки, обозначающее, что пакет был принят. Все это делается обычно в «железе» (аппаратуре чипа контроллера USB устройства).

Программное обеспечение (firmware микроконтроллера) получит прерывание, в котором оно должно прочитать содержимое буфера конечной точки и проанализировать запрос на дескриптор устройства (parse device descriptor request).

Конечные точки (endpoints)

Конечные точки могут быть описаны как источники или приемники данных. Поскольку шина является хост-ориентированной, конечные точки оказываются в конце канала связи, на функции USB. Например, на уровне программного обеспечения Ваш драйвер устройства может отправлять пакет в конечную точку EP1 устройства. Так как данные поступают от хоста, они попадут в OUT буфер EP1. Ваше firmware теперь может не спеша прочитать эти данные. Если устройство хочет вернуть данные, функция не может просто записать их на шину, так как шина полностью управляется хостом. Поэтому firmware помещает данные в буфер EP1 IN, и эти данные находятся в буфере до тех пор, пока хост не отправит пакет IN, которым он запрашивает данные конечной точки. Конечные точки можно также рассматривать как интерфейс между железом функции устройства и firmware, работающем на функции устройства.
Все устройства должны поддерживать конечную точку 0. Это конечная точка, которая принимает все управляющие запросы и запросы статуса во время энумерации и в течение всего времени, когда устройство остается работоспособным на шине.

Потоки, или каналы (Pipes, дословно - трубы)

Когда устройство отправляет и принимает данные через несколько конечных точек, клиентское программное обеспечение передает данные через потоки. Поток – логическое соединение между хостом и конечной точкой (точками). Потоки также имеют набор параметров – тип передачи (Control, Bulk, Iso или Interrupt), направление потока данных и максимальные размеры пакета/буфера. Например, поток по умолчанию – двунаправленный поток, составленный из IN конечной точки 0 и OUT конечной точки 0 с типом передачи control.
USB определяет два типа потоков (pipes)

• Stream Pipes не имеют предопределенного USB формата, поэтому Вы можете послать данные любого типа через stream pipe и восстановить данные на другом конце. Потоки данных последовательны и имеют предопределенную направленность – IN или OUT. Stream pipes поддерживают типы передач bulk, isochronous и interrupt. Stream pipes могут управляться либо от хоста, либо от устройства.
• Message Pipes имеют предопределенный USB формат. Они управляются хостом, инициируются запросом, отправляемым от хоста. Данные пересылаются в нужном направлении, заданном в запросе. Таким образом, message pipes позволяют передавать данные в обоих направлениях, но поддерживают только передачи control.

[Глава 4: Типы конечных точек (Endpoint Types)]

Стандарт USB определяет 4 типа конечных точек/передач:

• Control
• Interrupt
• Isochronous
• Bulk

Передачи Control

Управляющие передачи (control transfer) обычно используются для команд и операций получения состояния. Основная настройка устройства USB со всеми функциями энумерации происходит с использованием передач control. Это обычно быстрые, случайные по времени пакеты, инициированные хостом, которые имеют наилучший приоритет по доставке (best effort). Максимально допустимая длина полезной нагрузки (payload, или размер пакета) управляющей передачи полноскоростных (full-speed) устройств USB составляет 8, 16, 32 или 64 байта; для высокоскоростных (high-speed) устройств этот размер составляет 64 байта, и для низкоскоростных (low-speed) устройств это 8 байт (только 8 байт, и никаких других вариантов).

У передач control могут быть до 3 стадий.

• Setup Stage – стадия установки, определяет, куда посылаются данные. Состоит из трех пакетов. Токен setup отправляется первым, он содержит адрес и номер конечной точки. Пакет данных (data packet) отправляется следующим, и всегда имеет тип PID data0 и включает setup packet, который детализирует тип запроса. Мы позже подробно рассмотрим setup packet. Последний пакет из трех – рукопожатие (handshake), используемое для подтверждения успешности приема или для сообщения об ошибке. Если функция успешно приняла setup data (CRC, PID и т. п. в порядке), она отвечает рукопожатием (handshake) ACK, иначе игнорирует данные, не отправляя пакет handshake. Функция не может послать пакеты STALL или NAK в ответ на пакет setup.
• Data Stage – эта стадия необязательна. Она состоит из одной или нескольких передач IN или OUT. Запрос setup показывает, сколько данных будет передаваться на этой стадии. Если количество данных превышает максимальный размер пакета, данные будут переданы в нескольких передачах, каждая из которых (за исключением последней) имеет размер максимального пакета.

Стадия data stage имеет два различных сценария, в зависимости от направления передачи данных.

Сценарий IN: когда хост готов принять данные control data, он выпускает IN Token. Если функция получает IN token с ошибкой, например PID не соответствует инвертированным битам PID, то она игнорирует пакет. Если токен принят успешно, устройство может либо ответить пакетом DATA, содержащим отправляемые control data, либо stall packet, индицирующий ошибку конечной точки, либо пакет NAK, показывающий хосту, что конечная точка работает, но пока не имеет данных для отправки.

Сценарий OUT: когда хосту нужно передать устройству пакет с управляющими данными (control data packet), он выпускает OUT token, за которым идет пакет, содержащий control data в качестве полезной нагрузки. Если любая часть – или OUT token, или data packet ошибочны, функция игнорирует пакет. Если буфер конечной точки пуст, она заполняет буфер данными и передает ACK, информирующий хост о том, что данные получены успешно. Если буфер конечной точки не пуст, поскольку идет обработка предыдущего пакета, функция отвечает NAK. Однако, если у оконечной точки была ошибка, и ее бит останова (halt bit) был установлен, она возвращает STALL.

• Status Stage сообщает состояние полного запроса, и меняется в зависимости от направления передачи. Функция всегда возвращает сообщение состояния.

Стадия status stage также имеет два различных сценария, в зависимости от направления передачи данных.

Сценарий IN: если хост отправил токен (токены) IN token(s) во время стадии data stage для приема данных, хост должен подтвердить успешный прием данных. Это делается путем отправки токена OUT, за которым идет пакет data нулевой длины. Функция может теперь сообщить свой статус на стадии handshaking. ACK указывает на то, что функция завершила команду и готова к приему следующей команды. Если во время обработки этой команды произошла ошибка, функция выдает STALL. Однако если пока продолжается обработка команды, функция выдает NAK, указывающий хосту повторить позже стадию status stage.

Сценарий OUT: если хост отправил токен (токены) OUT на стадии data stage – чтобы отправить данные, функция подтверждает успешный прием данных отправкой пакета нулевой длины в ответ на токен IN. Однако если произошла ошибка, функция должна выдать STALL, или если пока обрабатываются данные, должна выдать NAK, указывая хосту повторить позже status phase.

Передачи Control: общий обзор

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

Хост отправляет токен Setup, говорящий функции, что следующий пакет будет пакет Setup. Поле адреса будет содержать адрес устройства, от которого главный компьютер просит дескриптор. Номер конечной точки должен быть 0, что указывает канал по умолчанию (default pipe). Затем хост отправит пакет DATA0. Он будет содержать 8 байт полезной нагрузки, которая будет являться запросом Device Descriptor Request, описанным в Главе 9 спецификации USB. Функция USB подтверждает пакет setup, что он был прочитан корректно, без ошибок. Если пакет принят с ошибкой, устройство просто игнорирует этот пакет. Хост должен отправить пакет позже заново, после короткой задержки.

Три вышеуказанных пакета представляют из себя первую транзакцию USB. Теперь устройство USB будет декодировать 8 принятых байт, и определять по ним, что это device descriptor request (запрос на дескриптор устройства). После этого устройство попытается отправить Device Descriptor, что произойдет в следующей транзакции USB.

В этом случае мы подразумеваем, что максимальный размер полезной нагрузки 8 байт. Хост отправляет токен IN, чем говорит устройству, что он может теперь отправить данные для этой конечной точки. Поскольку максимальный размер пакета 8 байт, мы должны для отправки разделить 12 байт дескриптора устройства на кусочки. Каждый кусочек должен быть размером по 8 байт, за исключением последней транзакции. Хост подтверждает каждый пакет, который мы посылаем ему.

Как только дескриптор устройства отправлен, начинается транзакция статуса. Если транзакции были успешны, хост отправляет пакет нулевой длины, показывающий, что полная транзакция была успешна. Функция отвечает на это пакетом нулевой длины, индицирующим её состояние (status).

Передачи Interrupt

Любой, кто имел дело с запросами на прерывание у микроконтроллеров, знает, что прерывания генерируются устройством (в микроконтроллере). Однако под управлением USB, если устройство требует внимания хоста, оно должно ждать, пока хост его не опросит, чтобы понять, что устройство нуждается в срочном обмене данными! Передачи Interrupt имеют следующие особенности:

• Гарантированная латентность (latency)
• Однонаправленный поток канала
• Определение ошибок и последующая повторная попытка передачи.

Передачи Interrupt обычно непериодические, когда USB устройство "инициирует" связь, требующую ограниченного времени ожидания. Запрос на «прерывание» ставится устройством USB в очередь, пока компьютер не опросит устройство USB с целью получения данных.

Максимальная полезная нагрузка для low-speed устройств - 8 байт.
Максимальная полезная нагрузка для full-speed устройств - 64 байта.
Максимальная полезная нагрузка для high-speed устройств - 1024 байта.

На диаграмме показан формат транзакций Interrupt IN и Interrupt OUT.

Interrupt IN: хост периодически опрашивает конечную точку interrupt. Скорость опроса указана в описателе конечной точки (endpoint descriptor), который мы рассмотрим позже. Каждый опрос сопровождается отправкой хостом токена IN. Если токен IN испорчен, функция игнорирует пакет, и продолжает мониторинг шины в ожидании новых токенов.

Если interrupt поставлено в очередь устройством USB, функция отправит пакет data, содержащий данные, соответствующие interrupt при приеме токена IN. После успешного приема хостом, хост возвратит ACK. Однако, если данные были испорчены, хост не вернет status. Условие прерывания не присутствовало, когда главный компьютер опросил оконечную точку прерывания токеном IN, но функция ответила о своем состоянии NAK. Если на этой конечной точке произошла ошибка, то в ответ на токен IN будет отправлен STALL.

Interrupt OUT: когда хост хочет отправить устройству данные interrupt, он выдает токен OUT, за которым идет пакет data, содержащий данные interrupt. Если любая часть - токен OUT или пакет data ошибочны, функция игнорирует пакет. Если буфер конечной точки функции был пуст, и функция вывела данные в буфер конечной точки, она выдает ACK, информируя хост об успешно принятых данных. Если буфер конечной точки не пуст (еще идет обработка предыдущего пакета), то функция выдает NAK. Однако, если ошибка произошла с конечной точкой и ее бит останова был установлен, то функция выдает STALL.

Изохронные передачи (Isochronous Transfers)

Изохронные передачи происходят периодически и продолжительное время. Они обычно содержат информацию, привязанную ко времени (чувствительную к времени доставки), например аудио или видео потоки. Если произойдет задержка или повторная передача данных в аудио потоке, то Вы должны в результате получить искаженный звук. Дополнительная неприятность – может пропасть синхронизация звука. Однако выпадение пакетов или фреймов могут случаться постоянно снова и снова, и это будет менее заметно для слушателя. Изохронные передачи обеспечивают:

• Гарантированное выделение полосы пропускания шины USB.
• Ограниченную латентность.
• Однонаправленный поток канала.
• Детектирование ошибок с помощью CRC, но без гарантии доставки (нет повторов при ошибках).
• Работают только на скоростях Full speed и high speed.
• Нет переключения данных.

Для изохронной конечной точки максимальный размер полезной нагрузки по данным указывается в дескрипторе конечной точки (endpoint descriptor). Этот размер может быть максимум до 1023 байт для full speed и до 1024 байт для high speed. Поскольку максимальный размер полезной нагрузки влияет на требование к шине по полосе пропускания, следует внимательно отнестись к его выбору. Если Вы используете большую полезную нагрузку, то может оказаться хорошим выбором задать серию альтернативных интерфейсов (alternative interfaces) с различными изохронными размерами полезной нагрузки. Если во время энумерации хост не может предоставить Вашей изохронной конечной точке привилегированную полосу из-за ограничений полосы пропускания, то у него еще будут другие варианты полосы вместо того, чтобы потерпеть неудачу полностью. Данные, посылаемые через изохронную конечную точку, могут быть меньше предварительно оговоренного размера, и могут измениться по длине от транзакции к транзакции.

На диаграмме показан формат изохронных транзакций IN и OUT. Изохронные транзакции не имеют стадии установления связи (рукопожатия, handshaking stage) и не могут сообщать об ошибках или событиях STALL/HALT.

Передачи Bulk

Bulk-передачи можно использовать для большого объема быстро передаваемых данных. В качестве примера можно привести задание по выводу на печать, посланное в принтер, или изображение, сгенерированное от сканера. Bulk-передачи предоставляют коррекцию ошибок полезной нагрузки с помощью поля CRC16 и механизмы детектирования ошибок и повторной передачи, гарантирующие отсутствие ошибок в передаваемых или принятых данных.
Bulk-передачи будут использовать остаточную полосу пропускания шины после того, как все другие транзакции были распределены. Если шина занята данными isochronous и/или interrupt, то данные bulk могут передаваться через шину медленно. Следовательно, передачи Bulk должны использоваться только для интенсивных коммуникаций с негарантированным временем доставки. Особенности передачи Bulk:

• Используются для передачи большого объема данных на высокой скорости за короткое время.
• Детектирование ошибок с помощью CRC, с гарантией доставки.
• Не гарантируется полоса пропускания или минимальная задержка (минимальная латентность).
• Однонаправленный поток данных канала.
• Работает только на скоростях Full speed и high speed.

Bulk-передачи поддерживаются только full speed и high speed устройствами. Для конечных точек full speed максимальный размер пакета bulk бывает 8, 16, 32 или 64 байта длиной. Для конечных точек high speed, максимальный размер пакета может до 512 байт длиной. Если полезная нагрузка данных меньше максимального размера пакета, она не должна быть дополнена нулями. Bulk-передачу считают законченной, когда она передала точное количество запрошенных данных, передала пакет меньше, чем максимальный размер оконечной точки, передала пакет нулевой длины.

На диаграмме показан формат транзакций bulk IN и bulk OUT.

Bulk IN: когда хост готов принять данные bulk, он выдает токен IN. Если функция принимает токен IN с ошибкой, она игнорирует пакет. Если токен принят корректно, функция может ответить либо пакетом DATA (содержащим отправляемые данные bulk), либо пакетом stall, (показывающим, что конечная точка имеет ошибку), либо пакетом NAK (показывающим, что конечная точка в работе, но у нее пока нет данных для отправки).

Bulk OUT: когда хост хочет отправить функции пакет bulk data, он выдает токен OUT, за которым идет data пакет, содержащий данные bulk. Если любая часть токена OUT или пакета data повреждена, функция игнорирует пакет. Если буфер конечной точки функции пуст, функция вдвигает данные в буфер конечной точки и выдает ACK, информируя хост об успешно принятых данных. Если буфер конечной точки функции не пуст по причине обработки предыдущего пакета, функция возвращает NAK. Однако если конечная точка в состоянии ошибки, и её halt-бит установлен, функция возвращает STALL.

Управление полосой пропускания

Хост отвечает за управление полосой пропускания шины. Это происходит при энумерации, и конфигурировании изохронных конечных точек и конечных точек interrupt через операции на шине. Спецификация накладывает ограничения на шину, которые разрешают выделение не более 90% всех фреймов для периодических передач (Interrupt или Isochronous) на шине full speed. На шине high speed это ограничение уменьшено - не более 80% микрофреймов можно выделить для периодических передач.

Таким образом, очевидно - если у Вас есть шина, очень нагруженная периодическими передачами, то оставшиеся 10% оставлены для передач управления (control transfers), и как только они будут распределены (обработаны), передачи bulk получат оставшуюся часть полосы.

[Продолжение статьи...]

[Ссылки]

1. What is USB? site:microchipdeveloper.com.