Usb spread что это
Итак, начнём мы с того, что спецификацией определены для USB-устройств 6 состояний, в которых они могут находиться. В каждом из этих состояний наше устройство должно себя адекватно вести и уметь переходить из одного состояния в другое. Состояния могут быть такими:
Подключено (attached) — устройство подключено к хабу, но питание от шины не подано. В этом случае устройство никак не может себя проявить. Для устройств с внешним питанием такое состояние отсутствует.
Запитано (powered) — в это состояние устройство переходит после того, как хаб его запитает. В таком состоянии устройство может заявить о себе, подтягивая резистором линию D+ или D- к шине питания. Понятно, что в первом состоянии мы ничего и не сможем сделать, если питаемся от шины (как можно себя проявить, если у тебя нет питания). Во втором состоянии подтяжка происходит автоматически. У нас просто в устройстве впаян резистор, который подтягивает нужную линию к питанию, как только это питание появится. То есть в этих двух состояниях нам особо ничего и делать-то не нужно, всё происходит само.
Дежурное состояние (default state) — после того, как нам подали питание и мы заявили о своём присутствии на шине — мы должны сразу перейти в дежурное состояние. В этом состоянии устройство должно отзываться на нулевой адрес, причём только на обращения к точке EP0, а также потреблять от шины не более 100 мА.
Адресовано (addressed) — в это состояние устройство переходит после того, как запросом Set_Address ему будет присвоен уникальный адрес на шине. В таком состоянии устройство должно отзываться только на присвоенный ему уникальный адрес, но также только при обращениях к точке EP0, и также потреблять от шины не более 100 мА.
Сконфигурировано (configured) — в это состояние устройство переходит после того, как запросом Set_Configuration для него установлена рабочая конфигурация. В таком состоянии устройство откликается только на присвоенный ему уникальный адрес, но уже при обращении ко всем точкам, описанным в установленной конфигурации, и может потреблять от шины заявленный ток.
Приостановлено (suspended) — в это состояние устройство должно переходить автоматически при отсутствии активности шины. При этом устройству запрещается что-либо передавать в шину, а также запрещается потреблять от шины более 2,5 мА. Единственное, что устройство может сделать — это послать в порт сигнал удалённого пробуждения, но только в том случае, если ранее ему специальным управляющим запросом разрешили подавать такой сигнал. При пробуждении устройства (причём не важно, кем оно инициировано), в порт, к которому оно подключено, хаб в течении 20 мс транслирует специальный сигнал возобновления, завершающийся сигналом LS-EOP. В приостановленном состоянии устройство сохраняет выбранную конфигурацию, присвоенный адрес и все остальные настройки.
Что нам делать в состоянии запитано мы уже обсудили. А вот для того, чтобы адекватно себя вести в дежурном состоянии, а также в состояниях адресовано, сконфигурировано и приостановлено — нам придётся отвечать на запросы и сигналы от хоста, поэтому придётся разобраться, какие это могут быть запросы и как нам на них реагировать.
Изучать запросы мы, естественно, начнём со стандартных запросов. Эти запросы должны поддерживать все USB-устройства. Но прежде чем их рассматривать, давайте кое-что вспомним (чтобы пазл полностью сложился).
Вспомним мы вот что. Ранее (в первой части) мы говорили, что для управления устройствами используются управляющие передачи (control transfer). А поскольку обсуждаемые нами стандартные запросы и ответы — это и есть ни что иное, как управление устройством, то формируются они именно в формате управляющих передач. Сейчас, зная о пакетах и транзакциях, мы можем рассмотреть формат этих передач более подробно.
Итак, управляющая передача состоит из 2-х или 3-х стадий: стадии установки (Setup Stage), стадии передачи данных (Data Stage), которая в некоторых запросах может отсутствовать, и стадии состояния (Status Stage).
Стадия Setup Stage состоит из транзакции управления, в пакете данных которой хост передаёт устройству сам запрос.
Стадия Data Stage состоит из одной или нескольких транзакций ввода или вывода, в которых передаются дополнительные данные запроса или ответ устройства. Как уже было сказано выше, эта стадия может отсутствовать.
Стадия Status Stage состоит из пустой транзакции ввода или вывода и служит для определения успешности или неуспешности завершения управляющей передачи.
Чтобы стало понятнее — внимательно смотрим рисунок ниже, на котором показаны варианты того, как могут выглядеть управляющие передачи.
Пакет данных транзакции управления всегда должен иметь PID Data0. Далее идентификаторы Data1, Data0 чередуются, но пакет данных передаваемый на стадии Status Stage должен иметь идентификатор Data1, независимо от того, какой идентификатор использовался перед этим.
На стадии Status Stage устройство при успешном выполнении запроса отвечает пустым пакетом Data1 на транзакцию IN или пакетом Ack на транзакцию OUT. Если оно ещё не завершило выполнение запроса, то оно отвечает пакетом NAK. Если при выполнении запроса произошла ошибка, то устройство отвечает пакетом STALL (для управляющих конечных точек такая ситуация не требует вмешательства хоста и не вызывает блокировки канала).
Далее давайте рассмотрим более подробно из каких полей состоит пакет данных, передаваемый на стадии Setup Stage:
Байт стандартных характеристик содержит следующую информацию:
- старший бит показывает направление передачи данных (0 — от хоста, 1 — от устройства)
- биты 6,5 определяют тип запроса (00 — стандартный, 01 — для класса, 10 — специфичный, 11 — зарезервировано)
- младшие 5 бит определяют получателя (00000 — устройство целиком, 00001 — интерфейс, 00010 — конечная точка, 00011 — другой, остальные значения зарезервированы)
С размером и форматом полей будет легче ориентироваться, если вы запомните маленькую хитрость, придуманную программистами для облегчения своего труда. Первые буквы названия полей (до заглавной) означают следующее:
bm — сокращение от bit mask, такие первые буквы названия означают, что значение имеют отдельные биты поля, то есть поле рассматривается побитово;
b — сокращение от byte, такое поле рассматривается целиком и имеет размер 1 байт
w — сокращение от word, такое поле также рассматривается целиком и имеет размер 2 байта
В дальнейшем я буду битовые поля писать в формате 0bBBBBBBBB, поля размером 1 байт — в формате 0xHH, а двухбайтовые поля — в формате 0xHHHH
Этот запрос используется для получения состояния устройства USB, интерфейса или конечной точки. При этом остальные поля запроса могут принимать следующие значения:
- bmRequestType
- 0b10000000 — получить состояние USB-устройства
- 0b10000001 — получить состояние интерфейса
- 0b10000010 — получить состояние конечной точки
- Как видите, для всех трёх вариантов старший бит равен 1, то есть на стадии передачи данных устройство должно передавать данные хосту (отвечать на этот запрос).
- wValue
- 0x0000
- wIndex
- 0x0000 — если запрос обращён к USB-устройству
- если запрос обращён к интерфейсу или к конечной точке, то в этом поле указывается номер интерфейса или конечной точки
- wLength
- 0x0002 — то есть, в ответ на этот запрос, хост, на стадии передачи данных, должен получить от устройства 2 байта информации (слово состояния). Соответственно, если запрос был адресован USB-устройству, то хост получает слово состояния устройства, если запрос был адресован интерфейсу — слово состояния интерфейса, если конечной точке — слово состояния конечной точки. Как видите, всё не так уж и сложно.
Слово состояния устройства имеет следующий формат:
- бит 0 — режим питания устройства: 0 — питание от шины, 1 — от внешнего источника
- бит 1 — реакция на сигнал пробуждения (remote wakeup): 0 — устройство игнорирует сигнал пробуждения, 1 — устройство реагирует на этот сигнал
- биты 2..15 не используются и должны содержать нули
Слово состояния интерфейса всегда должно быть равно нулю (все его биты равны нулю).
Слово состояния конечной точки имеет следующий формат:
Этот запрос используется для запрета какого-либо свойства или состояния. При этом остальные поля запроса могут принимать следующие значения:
- bmRequestType
- 0b00000000 — сбросить свойство USB-устройства
- 0b00000001 — сбросить свойство интерфейса
- 0b00000010 — сбросить свойство конечной точки
- wValue
- В этом поле содержится код свойства, которое нужно сбросить.
- wIndex
- 0x0000 — если запрос обращён к USB-устройству
- если запрос обращён к интерфейсу или к конечной точке, то в этом поле указывается номер интерфейса или конечной точки
- wLength
- 0x0000 — то есть, на стадии передачи данных никаких данных передавать не нужно и управляющая передача с таким запросом будет состоять только из двух стадий.
Этот запрос используется для разрешения какого-либо свойства или состояния. При этом остальные поля запроса могут принимать следующие значения:
Этот запрос используется для назначения USB-устройству адреса на шине USB. При этом остальные поля запроса могут принимать следующие значения:
Этот запрос используется для получения дескрипторов. Подробнее о дескрипторах и их форматах мы поговорим позднее, а пока скажу лишь, что это специальные структуры данных, содержащие описание устройства, его интерфейсов, конечных точек и т.д. При этом остальные поля запроса могут принимать следующие значения:
- bmRequestType
- 0b10000000 — получить дескриптор устройства
- 0b10000001 — получить дескриптор интерфейса
- 0b10000010 — получить дескриптор конечной точки
- 0x01 — стандартный дескриптор устройства
- 0x02 — дескриптор конфигурации
- 0x03 — дескриптор строки
- 0x04 — дескриптор интерфейса
- 0x05 — дескриптор конечной точки
- 0x06 — уточняющий дескриптор устройства (для HS-устройств)
- 0x07 — дескриптор дополнительной конфигурации
- 0x08 — дескриптор управления питанием интерфейса
- 0x09 — дескриптор OTG
- 0x0A — отладочный дескриптор
- 0x0B — дополнительный дескриптор интерфейса
- wIndex
- В дескрипторах строк в этом поле содержится идентификатор языка, для остальных типов дескрипторов это поле должно быть равно нулю
- wLength
- Максимальный размер дескриптора в байтах. Если реальный размер запрашиваемого дескриптора меньше этого значения, то устройство должно просто целиком отослать запрашиваемый дескриптор, а если реальный размер дескриптора больше, то устройство должно послать хосту только первые wLength байт этого дескриптора
Этот запрос используется для изменения существующих или добавления новых дескрипторов. Остальные поля могут принимать такие же значения, как и в запросе Get_Descriptor, только старший бит поля bmRequestType в этом случае будет равен нулю, поскольку данные на стадии передачи данных будут передаваться от хоста к устройству.
Этот запрос используется для того, чтобы узнать номер активной (выбранной в данный момент) конфигурации. При этом остальные поля запроса могут принимать следующие значения:
Этот запрос используется для того, чтобы выбрать новую активную конфигурацию для USB-устройства. При этом остальные поля запроса могут принимать следующие значения:
Этот запрос используется для того, чтобы узнать какая альтернативная установка в настоящий момент используется для указанного интерфейса:
Этот запрос используется для того, чтобы выбрать новую альтернативную установку для указанного интерфейса. При этом остальные поля запроса могут принимать следующие значения:
- bmRequestType
- 0b00000001
- wValue
- 0x00NN, где NN — номер альтернативной установки, которую мы хотим выбрать
- wIndex
- 0xNNNN, где NNNN — номер интерфейса, для которого мы выбираем новую альтернативную установку
- wLength
- 0x0000
На этом пока всё. Для того, чтобы приступать к написанию кода и экспериментам, нам осталось обсудить только такие (уже всплывавшие несколько раз) понятия, как «дескрипторы» и «классы». Этим мы и займёмся в следующей статье.
Почитав вот этот пост и сопутствующую ему дискуссию, я решил попробовать внести ясность в то, что такое USB Power Delivery и как это работает на самом деле. К сожалению у меня сложилось впечатление, что большинство участников дискуссии воспринимают 100 ватт по USB слишком буквально, и не до конца понимают что за этим стоит на уровне схематики и протоколов.
Итак, кратко – основные пункты:
О кобелях Про кабели
USB Power Delivery работает с шестью типами коннекторов:
- USB 3.0 PD Standard-A USB 3.0 PD Standard-B plug
- USB 3.0 PD Standard-A USB 3.0 PD Micro-B plug
- USB 3.0 PD Micro-A USB 3.0 PD Micro-B plug
- USB 3.0 PD Micro-A USB 3.0 PD Standard-B plug
- USB 2.0 PD Standard-A USB 2.0 PD Standard-B plug
- USB 2.0 PD Standard-A USB 2.0 PD Micro-B plug
- USB 2.0 PD Micro-A USB 2.0 PD Micro-B plug
- USB 2.0 PD Micro-A USB 2.0 PD Standard-B plug
Про порты
После сертификации USB PD порты маркируются следующим образом:
Данное лого информирует о версии USB (2.0 или 3.0 SuperSpeed), а также о профилях электропитания которые поддерживает данный порт. Значение ”I” означает потребляемый профиль, необходимый для полноценного функционирования устройства, а значение «О» то какой профиль порт может предоставить. Примеры маркировки портов:
- Первый порт поддерживает USB2. Он может давать питание по Профилю 1 ( 2A@5V) и использует Профиль 3 ( 5V@2A или 12V@3A) для полноценного функционирования. Например порт для планшета или нетбука.
- Второй порт поддерживает USB2. Он может давать питание по Профилю 2 (2A@5V или 12V@1.5A) и использует Профиль 4 ( 5V@2A или 12V@3A или 20V@3A) для полноценного функционирования. Например порт для ноутбука или лаптопа.
- Третий порт поддерживает USB3. Он только дает питание по Профилю 1 (5V@2A). Сам он по VBus не запитывается. Например порт десктопа, монитора, телевизора, и т.д.
- Четвертый порт поддерживает USB3. Как и в первом примере он может давать питание по Профилю 1 (5V@2A) и сам требует питание по Профилю 3 для полноценного функционирования (5V@2A или 12V@3A). Пример придумайте сами :)
Физический канал
USB PD определяет принципиальную схему физической организации соединения посредством кабеля следующим образом:
Как видно из схемы, USB PD также требует чтобы и в источнике и в приемнике были реализованы схемы определения падения/скачка напряжения, а так же методы определения разряженной батареи для случаев когда одна из сторон не может запитаться от своего внутреннего источника.
И соответственно такая же блок-схема для приемника:
Сериализированная кодировка 4b5b и декодировка 5b4b подразумевает что все данные по шине, кроме преамбулы пакета, передаются пятибитными последовательностями в соответствии c таблицей кодировки, определяемой стандартом. Каждая такая последовательность кодирует либо одну из 16 цифр (0x00..0x0F), либо сигналы начала / синхронизации / сброса и конца пакета. Таким образом передача одного байта занимает 10 бит, 16-битного слова – 20 бит и 32-битного двойного слова – 40 бит и т.д.
Логический канал
USB PD протокол основывается на последовательных парах типа запрос-ответ. Запросы и ответы пересылаются с использованием пакетов. Пакеты состоят из преамбулы (фаза подготовки к передаче), начала пакета SOP (три сигнала Sync-1 и завершающий Sync-2 в кодировке 4b5b), заголовок, 0..N байт полезной нагрузки, контрольной суммы (CRC-32) и сигнала конца пакета (одиночный сигнал EOP):
Как было упомянуто выше, преамбула не кодируется в 4b5b. SOP, CRC и EOP кодируются 4b5b на физическом уровне, заголовок и полезная нагрузка кодируются на уровне логического протокола.
Сброс шины производится путем посылки трех сигналов RST1 и завершающего сигнала RST2, в соответствии с кодировкой 4b5b.
Протокол
Отдельно следует упомянуть что поля вида tSourceActivity, tSinkRequest и т.д. — это константы, значения которых глобально заданы самой спецификацией в отдельной главе. Сделано это потому что они определялись опытным путем в результате прототипирования, и найденные оптимальные значения просто подставили в отдельную главу, чтобы не рыскать по всей спецификации.
- Power Data Object (PDO) – используется для описания характеристик порта источника или требований приемника
- Request Data Object (RDO) – используется портом приемника для установки соглашения по характеристикам электропитания
- BIST (Built In Self Test) Data Object (BDO) – используется для тестирования подключения на соответствие требованиям спецификации для физического соединения
- Vendor Data Object (VDO) – используется для передачи нестандартной, дополнительной или иной проприетарной информации определяемой производителем оборудования и выходящей за рамки спецификации USB PD.
PDO соответствующий элементу с постоянным типом электропитания 5V всегда должен идти первым в цепочке объектов.
Структура объекта PDO:
Для каждого типа электропитания предлагаются различные характеристики.
Постоянный тип электропитания, напряжение постоянное. Источник должен иметь хотя бы один такой элемент:
Программируемый тип электропитания, напряжение может регулироваться путем запросов в пределах между минимальным и максимальным:
Вариативный тип электропитания, напряжение может изменяться в заданных пределах абсолютного минимума и абсолютного максимума, но не может регулироваться:
Батарея, данный тип используется для обозначения батарей которые могут быть напрямую подключены к линии VBus:
Структура объекта RDO:
На мой взгляд данной информации достаточно, чтобы получить хорошее представление о принципах работы USB Power Delivery. Я сознательно не стал углубляться в дебри, связанные с таймерами, счетчиками и обработкой ошибок.
Взаимодействие с традиционным USB
Как уже было упомянуто выше, Power Delivery – это самостоятельная подсистема, которая функционирует параллельно и независимо от канонического USB. Тем не менее, в случаях когда устройства реализуют оба протокола – и USB и Power Delivery, спецификация рекомендует реализацию т.н. System Policy Manager или SPM, компонента который может контролировать оборудование USB PD посредством традиционных запросов USB.
Для систем с поддержкой SPM, спецификация рекомендует предоставить PD информацию посредством специальных типов USB дескрипторов. Не считаю нужным в них детально углубляться, просто перечислю их названия:
- Power Delivery Capability Descriptor, является составной частью BOS дескриптора и сообщает о том поддерживает ли устройство зарядку батареи через USB, поддерживает ли оно стандарт USB PD, может ли оно выступать источником питания, и может ли оно быть приемником. Кроме того данный дескриптор содержит информацию о количестве портов-источников, портов-приемников и версии поддерживаемых спецификаций USB Battery Charging и Power Delivery.
- Battery Info Capability Descriptor, требуется для всех устройств заявивших батарею в качестве одного из элементов электропитания. Содержит информацию о названии, серийном номере и производителе батареи, ее емкости, а также о пороговых значениях тока в заряженном и разряженом состоянии.
- PD Consumer Port Capability Descriptor, требуется для всех устройств которые заявили поддержку хотя бы одно порта-приемника. Содержит информацию о поддержке стандартов Power Delivery и Battery Charging, минимальное и максимальное напряжение, операционную мощность, максимальную пиковую мощность и максимальное время, которое оно может эту пиковую мощность потреблять
- PD Provider Port Capability Descriptor, требуется для всех устройств которые заявили поддержку хотя бы одного порта-источника питания. Содержит информацию о поддержке стандартов Power Delivery и Battery Charging, а так же список всех PDO объектов, характеризующих элементы электропитания доступных устройству.
- PD Power Requirement Descriptor, требуется для всех устройств-приемников поддерживающих USB PD. Каждое устройство должно возвращать хотя бы один такой дескриптор в составе дескриптора конфигурации. Этот дескриптор должен идти сразу после первого дескриптора интерфейса. В случае когда их несколько, он должен идти после каждого первого дескриптора интерфейса функции, если используется IAD, или в случае композитного устройства без IAD, непосредственно после каждого дескриптора интерфейса, и до endpoint дескрипторов.
Заключение
Надеюсь что данным постом я подогрел интерес публики к USB Power Delivery. Скромно замечу, что автор имеет непосредственное отношение к данной спецификации, поэтому готов ответить на любые вопросы по Power Delivery в частности и USB в общем.
Когда мы в SberDevices делаем новое устройство, работаем над его аппаратной частью, перед нами встаёт вопрос выбора интерфейсов. Важным моментом при выборе является их доступность и совместимость с другими устройствами.
В своих устройствах мы не могли пройти мимо интерфейса USB-C. Помимо того, что он очень популярен в современных девайсах, он серьёзно расширил функциональность USB по сравнению со своими предшественниками. Давайте расскажу о нём поподробнее.
Краткий обзор особенностей USB TYPE-C
Стандарты USB существуют много лет, развиваются и совершенствуются по мере увеличения технологических потребностей и возможностей. Несмотря на свою универсальность, которая следует из аббревиатуры, привычный USB перестал удовлетворять по объему своей функциональности. В частности, не может решить задачу по обеспечению питания многих современных устройств, потребление которых серьёзно увеличилось. Первая версия USB TYPE-C появилась в 2013 году. Помимо возможностей USB 2.0 и USB 3.0, USB-C стал поддерживать существенно более энергоёмкие профили питания, а также альтернативные режимы работы. В альтернативных режимах контакты разъёма используются для передачи данных высокоскоростных стандартов, таких как Display Port, Thunderbolt, HDMI, Mobile High-Definition Link (MHL). Недавно была опубликована новая реализация стандарта — USB4, которая также ориентируется на спецификацию USB-C.
Описание и назначение контактов разъёма
Разъём включает в себя 24 контакта. Такое большое число контактов по сравнению с привычными разъёмами USB связано как с добавлением новых контактов, расширяющих функциональность, так и с дублированием контактов на противоположную часть разъёма. Так группы сигналов USB 2.0 и USB 3.0 задублированы, разъем стал симметричным, поэтому теперь его можно вставлять любой стороной.
Рассмотрим группы сигналов USB-C соединителя:
Группа | Цепи |
---|---|
Питание | VBUS (4 контакта), GND (4 контакта) |
USB 2.0 | DP (2 контакта), DN (2 контакта) |
USB 3.0 | TX1+, TX1-, TX2+, TX2-, RX1+, RX1-, RX2+, RX2- |
Конфигурационные контакты | CC1, CC2 |
Дополнительные (Альтернативный режим) | SBU1, SBU2 |
Видно, что под питание заложено 4 пары контактов. Это намекает на то, что через разъём стала возможна доставка существенно большей энергии для питания устройства. Через контакты питания возможна передача до 100 Ватт в нагрузку.
Профили питания доступные через USB TYPE-C:
USB 2.0 | 5 В 500 mA |
USB 3.0/USB 3.1 | 5 В 900 mA |
USB BC 1.2 | 5 В, до 1.5 А |
USB Type-C Current 1.5A | 5 В 1.5 A |
USB Type-C Current 3.0A | 5 В 3.0 A |
USB Power Delivery | до 20 В, до 5A |
Режим питания зависит от того, какая функциональность USB-C используется. Появившиеся контакты CC позволяют установить требуемый режим питания и открывают некоторые дополнительные возможности, но об этом позже.
Чтобы иметь возможность использовать профиль питания с большим током, при установке соединения нужно воспользоваться конфигурационными контактами CC.
Конфигурационные контакты СС
С помощью конфигурационных контактов CC (Configuration channel) происходит подключение двух устройств, установка параметров соединения, профилей питания, а также информационный обмен протокола USB Power Delivery. Функционально CC1- и CC2-пины решают следующие задачи:
Источник (он же DFP) подтягивает линии CC к плюсу через резисторы Rp или использует источники тока. Потребитель (UFP) в свою очередь через резисторы Rd подтягивает линии CC к минусу.
Выставляя определённый номинал Rp (или создавая определённый ток на линии СС), host сообщает, какой ток для питания устройства он может обеспечить. Измеряя падение напряжения на Rd, потребитель понимает, какой Rp используется на противоположном конце и, следовательно, определяет ток питания, который может обеспечить host. Без использования USB Power Delivery по такой схеме возможно установить соединение c током до 3А с единственно возможным напряжением 5В.
Экономичный вариант реализации без USB PD
Как видно выше, спецификация USB-C поддерживает широкий спектр стандартов передачи данных и профилей электропитания, но это не означает, что разработчик обязан использовать всю функциональность. Минимальный набор USB TYPE-C может включать в себя USB 2.0 с контактами CC и единственным напряжением питания 5V. В такой конфигурации можно обеспечить потребителю до 15 Вт (5 В, 3А), что значительно больше, чем может дать стандартный порт USB 3.0 – 4,5 Вт (5В, 900 мА).
Чтобы реализовать логику подключения между DFP и UFP, можно использовать микросхему контроллера конфигурации CC, например, PTN5150. Этот вариант значительно проще и дешевле навороченных контроллеров, поддерживающих USB Power Delivery. Структурная схема выглядит так:
Как видно, основные узлы представляют собой: монитор напряжений на СС контактах, набор источников тока, резисторов для переключения состояния выводов, модуль управления ролями устройства.
Микросхема имеет интерфейс I2C, с его помощью можно определить или изменить роль устройства (DFP, UFP, DRP).
Когда выбирается роль DFP, устройство предполагается как Power Source, для которого есть возможность выбрать 3 профиля питания. После выставления соответствующих бит в регистре управления, происходит подключение соответствующего источника тока на линию CC.
Ток на СС-линии | Режим питания |
---|---|
80 uA | 5V / 0.9 A |
180 uA | 5V / 1.5 A |
330 uA | 5V / 3 A |
В случае определения микросхемы в качестве UFP, контакты CC подключаются через резистор 5,1 кОм на землю. Монитор измеряет падение напряжения на этом резисторе и в статусный регистр заносится текущий режим питания.
Также возможно установить роль Dual Role Power (DRP), в этом режиме микросхема последовательно изменяет состояние СС-контактов от “pull-up Rp” до “pull-down Rd” и обратно до тех пор, пока не будет установлено соединение. Соединение возможно только между одним источником (Power Source) и одним потребителем (Power Sink). Таким образом, когда микросхема находится в режиме DRP и монитор напряжения CC-контактов замечает понижение напряжения на противоположном конце (подключён “pull-down Rd”), устройство понимает, что подключено к Sink, и начинает играть роль Source. Такой режим полезен в том случае, когда заранее неизвестно, в каком режиме должно работать устройство.
Рассмотрим пример использования контроллера
Кроме описанных выше СС-пинов и I2C-шины стоит отдельно отметить контакты ID, CON_DET, PORT. Контакт ID отображает режим, в котором в данный момент находится контроллер. Когда устройство определило себя в качестве DFP, ID примет значение LOW. Контакт CON_DET находится в HIGH, когда соединение установлено, LOW — в обратном случае. Эти два логических сигнала будем использовать далее для включения (когда мы DFP) и отключения (UFP) питания подключённого устройства.
Port — это вход, которым задаётся начальный режим устройства после включения питания. В случае, когда используется “pull-up”, контроллер становится DFP, если “pull-down” — UFP. Если нога осталась «висеть в воздухе», будет использоваться режим Dual Role, и устройство будет ждать подключения, чтобы определиться со своей ролью. Это состояние может быть изменено позднее, после конфигурирования по I2C или изменения уровня напряжения на PORT. Таким образом можно управлять режимами работы без использования I2C.
Нужно управлять питанием внешнего устройства, для этого можно воспользоваться дополнительной микросхемой логики и ключом.
Наша задача подавать питание на разъём USB-C только в том случае, когда к нам подключён UFP. ID в таком случае примет значение LOW, CON_DET — значение HIGH. Для того, чтобы открыть ключ высоким уровнем HIGH, надо реализовать функцию Y = CON_DET& (NOT ID). Таким образом, если снаружи подключён UFP, он от нас питается, если DFP, то напряжение на разъём не подаётся и не происходит конфликта двух источников.
В случае, если нет задачи менять роль устройства в процессе работы, а также не требуется определения ориентации кабеля, можно выполнить вариант проще, без микросхемы вообще. Допустим, ваше устройство играет строго одну роль — UFP/Power Sink, например, это флешка. В таком случае достаточно выводы СС1 и СС2 на разъёме подключить через 5,1 кОм на землю.
В случае, если ваше устройство играет только роль DFP/Power source и оно должно подключаться к устройству USB-C Dual Role, также можно обойтись резисторами. В этом случае подбираем номиналы в зависимости от напряжения источника, к которому подключаем резисторы.
Ток на СС-линии | Режим питания | Подтяжка к 5 В, кОм | Подтяжка к 3,3 В, кОм |
---|---|---|---|
80 uA | 5V / 0.9 A | 56 ± 20% | 36 ± 20% |
180 uA | 5V / 1.5 A | 22 ± 5% | 12 ± 5% |
330 uA | 5V / 3 A | 10 ± 5% | 4,7 ± 5% |
Мы рассмотрели относительно простые и дешёвые способы сделать наше устройство совместимым с другими USB-C устройствами, когда мы хотим использовать лишь часть функций спецификации. Этим возможности стандарта не ограничиваются, Power Delivery и Альтернативные режимы существенно расширяют доступные функции, но удорожают и усложняют устройство. Об этих возможностях расскажу в следующих статьях.
Для начала сравнительные фото сегодняшнего героя в компании заслуженных предков.
Коннектор USB Type-C немного крупнее привычного USB 2.0 Micro-B, однако заметно компактнее сдвоенного USB 3.0 Micro-B, не говоря уже о классическом USB Type-A.
Габариты разъема (8,34×2,56 мм) позволяют без особых сложностей использовать его для устройств любого класса, включая смартфоны и планшеты.
Сигнальные и силовые выводы размещены на пластиковой вставке пожалуй это самое слабое его место в центральной части разъёма. Контактная группа USB Type-C содержит 24 вывода. Напомню, что у USB 1.0/2.0 имелось всего 4 контакта, а разъемам USB 3.0 потребовалось уже 9 выводов.
Если внимательно присмотреться к рисунку слева, то видно, что контакты имеют разную длину. Это обеспечивает их замыкание в определённой последовательности. На рисунке в центре мы видим наличие защёлок, которые должны удерживать воткнутый кабель и обеспечивать тактильный щелчок в процессе соединения-рассоединения. На правом графике изображена зависимость усилия в процессе вставки-вынимания разъёма.
Пики, которые мы видим на нём — это моменты срабатывания защёлки.
Можно констатировать, что разработчики стандарта сделали если не всё, то почти всё, чтобы разъём стал максимально удобным и надёжным: он вставляется любым концом и любой стороной с ощутимым щелчком. По их мнению, он способен пережить эту процедуру более 10 тысяч раз.
Многоликий симметричный янус
Крайне приятной и полезной особенностью USB-C стал симметричный дизайн разъёма, позволяющий подключать его к порту любой стороной. Достигается это благодаря симметричному расположению его выводов.
По краям расположены выводы земли. Плюсовые контакты питания также расположены симметрично. В центре находятся контакты, отвечающие за совместимость с интерфейсом USB2 и младше. Им повезло больше всего — они дублируются и поэтому поворот на 180 градусов при соединении не страшен. Синим цветом помечены выводы, отвечающие за высокоскоростной обмен данными. Как мы видим тут всё хитрее. Если мы повернём разъём, то к примеру, выход TX1 поменяется местами с TX2, но одновременно и место входа RX1 займёт RX2.
Выводы Secondary Bus и USB Power Delivery Communication служебные и предназначены для общения между собой двух соединяемых устройств. Ведь им необходимо очень о многом друг другу рассказать, прежде чем начать обмен, но об этом позже.
А пока ещё об одной особенности. Порт USB Type-C изначально разрабатывался в качестве универсального решения. Помимо непосредственной передачи данных по USB, он может также использоваться в альтернативном режиме (Alternate Mode) для реализации сторонних интерфейсов. Такую гибкость USB Type-C использовала ассоциация VESA, внедрив возможность передачи видеопотока посредством DisplayPort Alt Mode.
USB Type-C располагает четырьмя высокоскоростными линиями (парами) Super Speed USB. Если две из них выделяются на нужды DisplayPort, этого достаточно для получения картинки с разрешением 3840×2160. При этом не страдает скорость передачи данных по USB. На пике это все те же 10 Гб/с (для USB 3.1 Gen2). Также передача видеопотока никак не влияет на энергетические способности порта. На нужды DisplayPort может быть выделено даже 4 скоростные линии. В этом случае будут доступны разрешения вплоть до 5120×2880. В таком режиме остаются не задействованы линии USB 2.0, потому USB Type-C все еще сможет параллельно передавать данные, хотя уже с ограниченной скоростью.
В альтернативном режиме для передачи аудиопотока используются контакты SBU1/SBU2, которые преобразуются в каналы AUX+/AUX-. Для протокола USB они не задействуются, потому здесь тоже никаких дополнительных функциональных потерь.
При использовании интерфейса DisplayPort, коннектор USB Type-C по-прежнему можно подключать любой стороной. Необходимое сигнальное согласование предусмотрено изначально.
Подключение устройств с помощью HDMI, DVI и даже D-Sub (VGA) также возможно, но для этого понадобятся отдельные переходники, однако это должны быть активные адаптеры, так как для DisplayPort Alt Mode, не поддерживается режим Dual-Mode Display Port (DP++).
Альтернативный режим USB Type-C может быть использован отнюдь не только для протокола DisplayPort. Возможно, вскоре мы узнаем о том, что данный порт научился, например, передавать данные с помощью PCI Express или Ethernet.
И этому дала, и тому дала. В общем… о питании.
Еще одна важная особенность, которую привносит USB Type-C – возможность передачи по нему энергии мощностью до 100 Вт. Этого хватит не только для питания/зарядки мобильных устройств, но и для работы ноутбуков, мониторов, а если пофантазировать, то и небольшого лабораторного источника питания.
При появлении шины USB, передача энергии была важной, но всё же второстепенной её функцией. Порт USB 1.0 обеспечивал всего 0,75 Вт (0,15 А, 5 В). Достаточно для работы мыши и клавиатуры, но не более того. Для USB 2.0 номинальная сила тока была увеличена до 0,5 А, что позволило получать от неё уже 2,5 Ватта для питания, например, внешних жестких дисков формата 2,5”. Для USB 3.0 номинально предусмотрена сила тока в 0,9 А, что при неизменном напряжении питания в 5В гарантирует мощность в 4,5 Вт. Специальные усиленные разъемы на материнских платах или ноутбуках способны были выдавать до 1,5 А для ускорения зарядки подключенных мобильных устройств, но и это “всего лишь” 7,5 Вт. На фоне этих цифр возможность передачи 100 Вт выглядит чем-то фантастическим.
Для того чтобы наполнить такой энергией порт USB Type-C служит поддержка спецификации USB Power Delivery 2.0 (USB PD). Если таковой нет, порт USB Type-C штатно сможет выдать на гора 7,5 Вт (1,5 А, 5 В) или 15 Вт (3А, 5 В) в зависимости от конфигурации. Для подробного описания этой спецификации в данной статье недостаточно места, да и всё равно я не сделаю это лучше, чем уважаемый stpark в своей замечательной статье.
Однако, совсем обойти эту архиважную тему не получится.
Для того, чтобы обеспечить мощность в 100 ватт при напряжении пять вольт потребуется ток в 20 ампер! Такое при габаритах кабеля USB Type-C возможно пожалуй только если изготовить его из сверхпроводника! Боюсь, что сегодня это будет обходиться пользователям дороговато, поэтому разработчики стандарта пошли по другому пути. Они увеличили напряжение питания до 20 Вольт. “Позвольте, но ведь оно выжжет напрочь мой любимый планшет” — воскликните вы, и будете совершенно правы. Для того, чтобы не пасть жертвой разъярённых пользователей, инженеры задумали хитрый трюк — они ввели систему силовых профилей. Перед соединением любое устройство находится в стандартном режиме. Напряжение в нём ограничено пятью вольтами, а ток двумя амперами. Для соединения с устройствами старого типа этим режимом всё и закончится, а вот для более продвинутых случаев, после обмена данными, устройства переходят в другой согласованный режим работы с расширенными возможностями. Чтобы познакомиться с основными существующими режимами глянем на таблицу.
Профиль 1 гарантирует возможность передачи 10 Вт энергии, второй уже – 18 Вт, третий – 36 Вт, четвёртый целых – 60 Вт, ну а пятый нашу заветную сотню! Порт, соответствующий профилю более высокого уровня, поддерживает все состояния предыдущих по нисходящей. В качестве опорных напряжений выбраны 5В, 12В и 20В. Использование 5В необходимо для совместимости с огромным парком имеющейся USB-периферии. 12В – стандартное напряжение питания различных компонентов систем. 20В предложено с учетом того, что для зарядки аккумуляторов большинства ноутбуков используются внешние БП на 19–20В.
Пара слов о кабелях!
Поддержка описываемого в статье формата в полном объёме потребует огромной работы не только программистов, но и производителей электроники. Потребуется разработать и развернуть производство очень большого количества компонентов. Самое очевидное это разъёмы. Для того, чтобы выдерживать высокие токи питающего напряжения, не оказывать помех передаче сигналов очень высокой частоты, да ещё при этом не выходить из строя после второго коннекта и не вываливаться в самый неподходящий момент, качество их изготовления должно быть радикально выше по сравнению с форматом USB 2.
Для совмещения передачи энергии большой мощности и сигналом с гигабитным трафиком, производителям кабелей придётся серьёзно напрячься.
Полюбуйтесь, как выглядит подходящий для нашей задачи кабель в разрезе.
Кстати, об ограничениях на длину кабелей при использовании интерфейса USB 3.1. Для передачи данных без существенных потерь на скоростях до 10 Гб/c (Gen 2) длина кабеля c разъемами USB Type-C не должна превышать 1 метр, для соединения на скорости до 5 Гб/c (Gen 1) – 2 метра.
Схемотехники производителей материнских плат, докстанций и ноутбуков долго будут ломать голову, как сгенерировать мощность порядка сотни ватт, а трассировщики, как подвести её к разъёму USB Type-C.
Производители чипов на низком старте.
Симметричное подсоединение и работа сигнальных линий в разных режимах потребует применения микросхем высокоскоростных коммутаторов сигналов. Сегодня уже появились первые ласточки. Вот, например, коммутатор от фирмы Texas Instruments, который поддерживает работу в устройствах как в режиме хоста так и ведомого устройства. Он способен коммутировать линии дифференциальных пар с частотой сигнала вплоть до 5ГГц.
При этом размеры чипа HDC3SS460 3.5 на 5.5 мм и в режиме покоя он потребляет ток порядка 1 микроампера. В активном же режиме — меньше миллиампера. Существуют и более продвинутые решения, например чипы производства NXP поддерживают частоту обмена до 10 ГГц.
Стали появляться и менеджеры питания, совмещённые с цепями защиты сигнальных линий от статики, например вот такое изделие от NXP
Оно предназначено для корректной обработки момента подключения разъёма, а так же размыкания цепи питания в случае неполадок. Данный чип уже поддерживает напряжение на VBUS до 30 вольт, а вот с максимальным коммутируемым током всё много хуже — он не должен превышать 1 ампера, что и понятно, учитывая габариты — 1.4 на 1.7 мм!
Безусловным лидером в этой области выступила Cypress, которая выпустила специализированный микроконтроллер с ядром ARM Cortex M0 поддерживающий все пять возможных для стандарта профилей питания.
Типичная схема включения для использования в ноутбуке даёт о нём некоторое представление, а подробнее с ним можно будет ознакомиться скачав даташит.
В отличие от чипа NXP он ориентирован на управление внешними силовыми ключами и поэтому может обеспечить коммутацию требуемых токов и напряжений, не смотря на свои малые размеры.
Внимание, Важная особенность для тех кто уже торопится заказать первые образцы — микроконтроллер не имеет USB интерфейса и не является полным и законченным решением. Он может служить только в качестве менеджера питания. В данный момент открыт предзаказ на поставку образцов и демонстрационных плат. Судьба этого микроконтроллера видимо будет во многом зависеть от того, снабдит ли фирма — производитель разработчиков референсными библиотеками для его использования в разных режимах.
Тот факт, что уже для него уже создано несколько демокитов сильно повышает вероятность последнего.
Лифт в небеса или Вавилонская башня.
Итак сегодня полностью сложилась революционная ситуация. Верхи не могут, а низы не хотят жить по старому. Всем надоела неразбериха с огромным количеством кабелей, зарядных устройств, блоков питания и их низкая надёжность.
Новый стандарт породил невиданную активность. Флагманы электронной индустрии — Apple, Nokia, Asus готовят к выпуску свои первые гаджеты с поддержкой USB Type-C. Китайцы уже штампуют кабели и переходники. На подходе докстанции и хабы с поддержкой высокой нагрузки по мощности. Производители чипов разрабатывают новые микросхемы и думают как бы запихнуть драйвер нового порта в микроконтроллер. Маркетологи решают куда воткнуть новый разъём, а инженеры чешут репу пытаясь реализовать многопрофильные устройства из уже имеющихся электронных компонентов.
Пока не ясно только одно. Что мы получим в результате? Удобный и надёжный разъём, который заменит львиную долю интерфейсов и найдёт повседневное применение, или вавилонское столпотворение, ведь ситуация может начать развиваться по не самому благоприятному сценарию:
Пользователи могут окончательно запутаться в многочисленных спецификациях и кабелях, которые будут выглядеть с виду совершенно одинаково, но при этом будут сертифицированы только под определённые профили. Попробуй разберись с ходу со всеми этими маркировками.
Но даже если получится, то это вряд ли решит проблему — китайцы без зазрения совести легко поставят на любой шнур любой значок. А если надо, то до кучи на каждую сторону одного кабеля разные, их не смутит даже если они будут взаимоисключающими.
Рынок наводнится невероятным количеством переходников разного калибра и сомнительного качества.
Пытаясь подключить одно устройство к другому никогда в результате не будешь знать к какому результату этот процесс приведёт и из-за чего коннект либо вовсе отсутствует, либо всё жутко глючит. То ли один из гаджетов не поддерживает нужный профиль, то ли поддерживает но не слишком корректно, то ли вместо качественного кабеля попалась его грубая китайской подделка. А что прикажете делать, если вдруг на вашем ноутбуке выйдет из строя единственный оставшийся на нём разъём?
Поживём — увидим как оно выйдет. Пока же будем надеяться на лучшее, хотя в переходный период точно придётся не легко. Понимаю, что моя статья ответила далеко не на все вопросы о новом стандарте, но пора закругляться и браться уже за работу, а то у меня вырисовывается как раз первый клиент, который уже мечтает о плате с поддержкой USB Type-C. Есть шанс протестировать это чудо технологий на практике и затем поделиться уже личным опытом.
До новых встреч.
P.S. Новый стандарт уже приводит к появлению весьма экзотических устройств. Так анонсирован кабель 100 метровой длины, который вроде бы никак не вписывается в стандарты. Вся фишка в том, что он активный. На обоих своих концах кабель имеет преобразователь сигналов USB3 интерфейса в оптический. Сигнал передаётся по оптике и на выходе конвертируется назад. Естественно он не передают энергию, а только данные. При этом каждый из преобразователей на его концах питается от разъёма к которому подключен.
Думаю, что в скором времени для подтверждения подлинности уважающие себя фирмы начнут вставлять в кабели активные метки. Проблема хабов породит невиданную активность у разработчиков и производителей DC-DC преобразователей. Как справедливо заметил уважаемый пользователь TimsTims может возникнуть например ситуация, что устройство, которое питает способно выдать только 12 вольт, а подключенные к нему устройства начнут затребовать скажем одно 5, другое 18.
В общем этот стандарт обещает прокормить не одного разработчика, да и производители в накладе не останутся.
Собственно говоря, про то, как происходит передача данных мы уже начали говорить ещё в прошлой статье (помните, мы обсуждали конечные точки, коммуникационные каналы и прочее), просто здесь мы обсудим это более детально и обстоятельно.
А дальше с ними начинает работать USBD.
Здесь у нас всплыл термин «транзакции», поэтому поясню, что это такое. Транзакция — это один сеанс связи с устройством. Поскольку к шине у нас подключено много устройств, то хост физически не может постоянно и одновременно обмениваться данными со всеми этими устройствами. Вместо этого он организует циклы (фреймы, кадры) в каждом из которых осуществляет несколько сеансов связи с различными устройствами. Вот эти сеансы связи и называются транзакциями.
Кадры следуют друг за другом с периодичностью 1 кадр в мс. Ещё раз замечу, что в одном кадре не обязательно должны присутствовать сеансы связи со всеми устройствами на шине или сразу все кусочки информации, предназначенные для одного устройства. Расписание транзакций планируется USBD с учётом приоритета выбранных типов передач и с какими-то конечными точками хост может не осуществлять транзакций несколько фреймов подряд, даже при наличии запроса на обмен данными с этими точками (помните, мы в первой части обсуждали, что принтер может и подождать, а вот передача музыки в USB колонки ждать никак не может). Образно кадры и транзакции показаны на рисунке справа, подробнее их структуру мы рассмотрим позднее.
Вот теперь, с учётом новой информации, мы можем снова вернуться к типам передач и пропускной способности канала. Что для изохронных передач означает способность занять 90% пропускной способности канала. Это значит, что в каждом кадре 90% времени может быть отведено для транзакций этого типа передач. Аналогично, 10% пропускной способности канала, гарантированных для управляющих передач, означают, что в каждом кадре 10% времени гарантированно могут занять транзакции управляющих передач.
Далее ещё раз внимательно посмотрите на рисунок выше. На рисунке я не случайно выделил небольшие интервалы в начале и в конце каждого кадра. В реальности, в начале и конце каждого кадра тоже выделяются небольшие интервалы времени, которые используются специальным образом.
Начало каждого кадра помечается посылкой специального маркер-пакета SOF (start of frame), в состав которого входят 11 младших бит номера кадра. Этот маркер-пакет используется для синхронизации изохронных точек и хабов. В режиме HS каждый кадр делится на 8 микрокадров по 125 мкс, каждый из которых начинается с посылки маркер-пакета SOF (при этом в SOF всех микрокадров, относящихся к одному кадру, передаётся одинаковый номер).
Интервал времени в конце каждого кадра называется EOF. EOF — это время тишины. До наступления этого времени должны быть завершены все транзакции. Если в это время хаб обнаружит, что в какой-то нисходящий порт ему сыпят данные, то он этот порт просто отключит и сообщит об этом хосту.
Теперь вернёмся к транзакциям и разберём более подробно, что же происходит во время сеанса связи с конечной точкой и из чего состоят транзакции.
Сразу отвечу на второй поставленный нами вопрос — транзакции состоят из пакетов. Если помните, мы уже говорили, что любые сеансы обмена данными могут начинаться только по инициативе хоста. Так вот, любая транзакция начинается хостом. И начинается она с отправки маркер-пакета транзакции, в котором указывается адрес устройства, адрес конечной точки, с которой хост хочет «пообщаться», а также направление передачи данных. Получив такой пакет, адресуемое устройство готовится к обмену. Далее, после небольшого таймаута, следует пакет данных от источника (источник определяется направлением, указанным в маркер-пакете). Для изохронных передач транзакция на этом заканчивается (поскольку им не нужно никаких подтверждений доставки данных). Для всех остальных типов передач в транзакцию входит ещё третий пакет — пакет подтверждения или пакет квитирования (handshake). Для наглядности структура транзакций показана на рисунке ниже.
Далее подробнее поговорим про пакеты. Всего существует 4 типа пакетов: маркер-пакеты (token), пакеты данных (data), пакеты подтверждения (handshake) и специальные пакеты (special). Эти пакеты имеют строго определённую структуру, которая зависит от типа пакета, хотя у всех типов пакетов можно выделить и некоторые общие поля. Общая структура пакетов показана на рисунке справа (для скоростей передачи LS/HS). Пакет можно условно разделить на заголовок (2 байта), имеющий общую для всех пакетов структуру (Sync+PID+Check), и тело, защищённое контрольной суммой. Наличие, размер и структура тела, а также количество бит контрольной суммы зависят от типа пакета.
Итак, любой пакет на LS/FS начинается с 8 бит синхронизации — поле Sync. Для синхронизации используется битовая последовательность b’10000000′. (Для HS длина поля синхронизации составляет 32 бита.)
Далее следует 4 бита идентификатора пакета — PID и его инверсная копия — Check. PID определяет назначение пакета и, соответственно, его последующую структуру. В таблице ниже представлено небольшое описание различных идентификаторов пакетов шины USB.
Остальные специальные пакеты не будем рассматривать, поскольку они нам пока не понадобятся.
Идём дальше. Во всех полях пакетов, кроме поля CRC, данные передаются младшим битом вперёд.
Все пакеты состоят из целого числа байт (разрядность полей, входящих в пакет, специально так подобрана, чтобы сумма разрядов всех этих полей была кратна восьми).
Все пакеты заканчиваются специальным сигналом EOP, для LS/FS этот сигнал длится 2 битовых интервала (позже, когда дойдём до физики, мы рассмотрим, как формируется этот сигнал), для HS — таким специальным сигналом является передача определённой последовательности бит.
Передаваемые по шине данные кодируются по методу NRZI с техникой вставки бит (bit stuffing). Расшифруем что это значит. Это значит, что при передаче нулевого бита состояние сигнала на шине меняется на противоположное, а при перередаче единицы — состояние сигнала не меняется. Вставка бит используется для того, чтобы не потерять синхронизацию при монотонном единичном сигнале. Суть этой вставки сводится к тому, что после каждых 6 подряд единиц в передаваемые данные вставляется нулевой бит, независимо от того, какое значение имеет бит, следующий за этой группой единиц. (чтобы использовать NRZI и технику bit staffing — придётся разработать специальную процедурку для перекодирования передаваемых и принимаемых данных. )
Кроме того, нам нужно уметь вычислять CRC5 и CRC16. Вычисление CRC вообще отдельная тема, про неё подробно написано тут. А вот тут можно найти специальные процедурки для вычисления наших CRC5 и CRC16 .
Теперь поговорим про интервал ожидания (помните, на рисунке со структурой транзакций, между пакетами нарисованы небольшие интервалы). Вот давайте поговорим, откуда они и зачем. Как все мы понимаем, сигнал не может дойти от источника до приёмника мгновенно. Во-первых, задержку вносят кабели, во-вторых, задержку вносят хабы (они, как мы помним, должны принять сигнал от источника и ретранслировать его приёмнику), в-третьих, нужно учитывать, что хабов в цепочке от хоста до устройства может быть несколько, ну и наконец, нужно понимать, что приёмник должен иметь некоторое время, чтобы «осмыслить» принятый пакет, решить есть ли в нём ошибки, кому он предназначен и т.д.
Таким образом, ответный пакет источник не может получить мгновенно, потому что приёмнику нужно время чтобы «подумать» над ответом, и всей этой транспортной сети нужно время чтобы «доставить» ответ. С другой стороны, ответ нельзя ждать бесконечно долго, вдруг он вообще не придёт.
Поэтому в устройствах USB нормируется, во-первых, «максимальное время оборота по шине» — это время, за которое данные должны добежать до приёмника и вернуться назад к источнику в самом худшем случае — при прохождении последовательно через 5 хабов (время на то, чтобы «доставить»), и, во-вторых, «максимальная задержка ответа» — максимальное время от конца увиденного EOP до начала передачи ответного пакета (время на то, чтобы «подумать»). В устройствах при ожидании пакета запускаются специальные таймеры, которые отсчитывают интервал, достаточный для формирования ответа и его доставки, и если ответ за это время не получен — это воспринимается как ошибка.
Для FS интервал ожидания составляет 16-18 битовых интервалов, для HS — 736-816 битовых интервалов. Максимальное время, за которое мы должны всё обдумать и начать посылать ответ, составляет 7,5 битовых интервалов на FS и 192 битовых интервала для HS.
Ну и раз уж мы заговорили про битовые интервалы, то следует сказать, что длительность битового интервала для скорости LS составляет примерно 667 нс (1,5 Мбит/с), для FS примерно 83 нс, для HS примерно 2 нс.
Ещё один интересный вопрос. Зачем придумали аж целых 4 идентификатора пакетов данных? Сделали это вот почему. При передачах типа bulk (массивы), control (управляющие) и interrupt (прерывания) приёмник после получения пакета данных должен послать назад к источнику пакет подтверждения. Этот пакет подтверждения (так же, как и сам пакет данных) может испортиться. А если источник не получит подтверждения успешной передачи пакета данных, то в следующей транзакции он повторит отправку отправку этого пакета. Чтобы приёмник понял, что он эти данные уже получал, пакеты данных посылают с чередующимся PID. Чётные пакеты посылают с PID Data0, а нечётные — с PID Data1. Таким образом, получив два раза пакет данных с одним и тем же PID, приёмник понимает, что это не какие-то новые данные, а просто повторная отправка предыдущего пакета, потому что источник в предыдущей транзакции не увидел пакет подтверждения. Специальный бит в конечной точке, который указывает, пакет данных с каким PID мы ждём, называется Toggle Bit.
Ладно, с Data0, Data1 всё ясно, а для чего нужны PID Data2 и MData? Да примерно для того же самого. Они позволяют различить пакеты данных внутри микрокадра для широкополосных изохронных точек (USB2.0).
Ну, на этом пожалуй хватит про всякие транзакции и пакеты (если что — потом допишем), перейдём теперь к самому низкому уровню реализации — к физике.
С точки зрения физики в USB всё достаточно просто. Для связи по USB используются 4 провода: +5В, D+, D- и GND. Эти провода имеют стандартную цветовую маркировку: красный провод — это +5В, чёрный — GND, зелёный — D+, белый — D-.
Для передачи битов используется дифференциальный сигнал между проводами D+ и D-. Провода +5В и GND используются для питания устройства, а так же для индикации некоторых специальных состояний (вместе с D+ и D-).
На линиях D+ и D- высокий уровень соответствует напряжению +3,3 В (от 2,7 до 3,6).
Дифференциальный сигнал, при котором разница между D+ и D- больше 200 мВ при уровне напряжения на линии D+ > 2В называется Diff1.
Дифференциальный сигнал, при котором разница между D- и D+ больше 200 мВ при уровне напряжения на линии D- > 2В называется Diff0.
Состояние, когда на обоих сигнальных линиях присутствует низкий уровень относительно GND (D+
Читайте также: