Usb протокол обмена – USB

USB

Подробности

Родительская категория: USB

Категория: Протокол шины USB

Изохронные транзакции обеспечивают гарантированную скорость обмена, но не обеспечивают надежности доставки. По этой причине в протоколе отсутствуют подтверждения, поскольку повтор пакета приведет к сбою в планах доставки данных. Управление потоком, основанное на подтверждениях, отсутствует — устройство обязано выдерживать темп обмена, заявленный в дескрипторе изохронной конечной точки.

Транзакции изохронного вывода состоят из двух пакетов, посылаемых хост-контроллером, — маркера OUT и пакета данных DATA. В транзакции ввода хост посылает маркер IN, на который устройство отвечает пакетом данных, возможно, и с нулевой длиной поля данных (если нет готовых данных). Любой другой ответ устройства (как и «молчание») хостом расценивается как ошибка, приводящая к остановке данного канала.

При изохронном обмене имеется контроль достоверности (отбрасывание пакетов с ошибками) и целостности данных (обнаружение факта пропажи пакета). Контроль целостности основан на строгой детерминированности темпа обмена — в соответствии со своим дескриптором точка ожидает транзакцию с периодом 2bInterval–1 микрокадров. Для обычной изохронной конечной точки в микрокадре возможна лишь одна транзакция, и ошибка при приеме пакета выражается в отсутствии принятых данных в микрокадре, в котором они ожидаются. Таким образом, нумерация пакетов (переключатель Toggle Bit) не требуется. Полноскоростные устройства и хостконтроллеры должны посылать пакеты только типа DATA01. Для широкополосных изохронных конечных точек (USB 2.0) в каждом микрокадре возможна передача до трех пакетов данных. Любой из этих пакетов может потеряться, и для обнаружения этой ситуации требуется нумерация пакетов внутри микрокадра. Для этой нумерации введено два новых типа пакетов данных: DATA2 и MDATA. Многообразие типов пакетов кроме нумерации позволяет еще и информировать партнера по связи о своих планах на данный микрокадр. В транзакциях IN идентификатором пакета устройство указывает, сколько еще пакетов оно собирается выдать в том же микрокадре, что позволяет хосту не делать лишних попыток ввода. Так, если в микрокадре передается один пакет, то это будет DATA0; если два — последовательность будет DATA1, DATA0; три — DATA2, DATA1, DATA0. В транзакциях OUT для вывода не последнего пакета в микрокадре используется пакет MDATA (More Data), а идентификатор последнего пакета показывает, сколько было до него передано пакетов. Так, при одной транзакции вывода используется пакет DATA0, при двух — последовательность MDATA, DATA1, при трех — MDATA, MDATA, DATA2. Во всех транзакциях, кроме последней в микрокадре, должны использоваться пакеты максимального размера. Отметим, что между широкополосными транзакциями в микрокадре могут вклиниваться другие транзакции.

perscom.ru

Интерфейс USB. Еще немного теории.

Появилось немного свободного времени, и я решил написать небольшую «внеплановую» статью.

Итак, из предыдущей статьи, мы знаем, что для обмена данными используются некие виртуальные каналы – «конечные точки». Давайте рассмотрим, как происходит обмен.

Обмен данными по USB

Нужно помнить, что интерфейс USB предусматривает использование разветвлителей – хабов. Более того, допускается каскадное включение хабов. Следовательно, необходимо как-то идентифицировать конкретное USB устройство в «гирлянде» из хабов и USB устройств. Для этого каждому устройству присваивается адрес.

Здесь остановимся немного подробнее. Адрес кодируется 7 битами. Изначально (в момент подключения), устройство, грубо говоря, само себе назначает адрес 0. Этот адрес зарезервирован стандартом как раз для вновь подключаемых устройств. Далее, в процессе инициализации (об этом поговорим позже), хост присваивает устройству уникальный адрес отличный от 0, а адрес 0 «освобождается» для вновь подключаемых устройств.

И так, для того чтобы передать данные конкретному устройству, нужно знать адрес устройства и номер виртуального канала «внутри» устройства (адрес «конечной точки»).

Как мы уже выяснили, сразу после включения, устройство имеет особый, «нулевой» адрес. Каждое устройство, согласно стандарту, имеет «нулевую конечную точку» типа Control. Соответственно, сразу после подключения, хост может начинать обмениваться данными с новым устройством (адрес = 0, номер конечной точки = 0).

Рассмотрим, как происходит обмен данными.

Инициатором обмена всегда выступает хост. Устройство не может начать передачу данных по собственной инициативе. Хост поочередно (емнип, с интервалом в 1 мс, но «низкоскоростные» устройства могут опрашиваться не каждый раз, а, например, раз за 10 циклов опроса) опрашивает все подученные устройства. Каждый раз, при опросе, устройство может получить данные от хоста и отправить данные хосту.

Сам обмен осуществляется пакетами. Стандартом предусмотрено несколько типов пакетов. «Побайтно» мы пока разбирать пакеты не будем, но коснемся этого вопроса в практической части.

Дело в том, что часть работы по формированию и передаче пакетов (например, вопросы синхронизации, расчет контрольных сумм и т. д.) возьмет на себя USB периферия МК. Для тех, кто хочет сразу углубиться в биты и байты могу порекомендовать ознакомиться с разделом 8 официальной спецификации USB 2.0

Пока нам достаточно знать, что существуют «пакеты данных» и несколько типов «служебных пакетов».

USB и Plug and Play

Давайте рассмотрим, что с нашим устройством будет происходить дальше, после того как хост определил подключение нового устройства и готов начать обмен данными. Нам нужно ненадолго подняться на «высокий» уровень – уровень ОС.

Дело в том, что в стандарт USB поддерживает концепцию Plug and Play (подключи и играй). Данная концепция подразумевает, что пользователю достаточно «воткнуть» устройство в соответствующий порт ПК. Дальше ОС автоматически определит тип подключенного устройства, найдет подходящий для данного устройства драйвер, сконфигурирует устройство и т. д. (правда, это конечно в идеале :))

Для того чтобы вся эта красота работала, стандартом USB предусмотрены некие общие требования для всех устройств:

1. Каждое устройство содержит «собственное описание» (дескриптор устройства).

2. Есть некий, общий для всех USB устройств, механизм который позволяет ОС прочитать дескриптор устройства для того, чтобы идентифицировать устройство, узнать его характеристики.

3. Есть некий, общий для всех USB устройств, механизм который позволяет ОС выполнить первичную конфигурацию устройства (например, присвоить устройству новый адрес, о чем мы говорили выше).

Данными вещами (чтение дескриптора устройства, идентификация устройства) занимается некая служба ОС, которая отвечает за базовую поддержку USB.
После того как устройство будет идентифицировано и проведена некая первичная инициализация, данная служба передаст управление устройством драйверу, который «закреплен» за данным типом устройств (или конкретно за этим устройством).

Что будет, если служба не сможет найти «подходящий» драйвер для данного устройства знают все 🙂

Теперь возвращаемся на наш «низкий» уровень.

Начало работы с устройством. Стандартные заросы.

На практике, для чтения дескриптора устройства и первичной инициализации используются та самая «нулевая конечная точка». Есть несколько предусмотренных стандартом запросов (Standard Device Requests), которые должны обрабатываться всеми USB устройствами. Пока приведу несколько примеров таких запросов:

GET_DESCRIPTOR – запрос на получения дескриптора устройства. Данный запрос содержит дополнительную информацию о том, какой именно дескриптор должно вернуть (в устройстве «хранится» несколько разных дескрипторов, но об этом позже).

GET_CONFIGURATION – запрос на получение текущей конфигурации устройства.

SET_ADDRESS – данный запрос используется для присвоения устройству «нормального» (отличного от 0) адреса. Сам адрес содержится в запросе.

Нужно понимать, что запрос — это не более чем стандартизированная структура данных, которая содержит код запроса (bRequest) и дополнительные данные. Ответы на каждый из запросов тоже, естественно, стандартизированы.

Кроме стандартных запросов, которые устройство «обязано» поддерживать, можно определить «свои» запросы, специфические для конкретного устройства (класса устройств).

Детально со всей «кухней» запросов и ответов мы познакомимся в «практической» части.

Заодно, для того чтобы показать как выглядит тот самый дескриптор устройства приведу пример:

static const BYTE devDescriptor[] = {
	/* Device descriptor */
	0x12,   // длина дескриптора в байтах;
	0x01,   // тип дескриптора: 1-Device descriptor
	0x00,   // 2 байта - версия USB: 2.0
	0x02,   //
	0x02,   // класс устройства: 2-CDC class code
	0x00,   // подкласс: 0-CDC class sub code
	0x00,   // протокол: 0-CDC Device protocol
	0x08,   // максимальный размер пакета для "нулевой конечной точки"
	0xEB,   // 2 байта - код производителя VID
	0x03,   //
	0x26,   // 2 байта - код устройства PID
	0x61,   //
	0x10,   // 2 байта - версия (ревизия) устройства
	0x01,   //
	0x01,   // индекс строки с названием производителя
	0x02,   // индекс строки с названием устройства
	0x03,   // индекс строки с серийным номером устройства
	0x01    // количество поддерживаемых конфигураций
};
 

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

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

Извиняюсь за отсутствие в статье наглядности (иллюстраций, схем и т. д.) о чем было справедливо замечено в комментариях к предыдущей статье. В следующей статье попытаюсь исправиться.

we.easyelectronics.ru

Разбираем и собираем обратно стек USB / Habr

Иллюстрированная проекция модели сетевого взаимодействия OSI на универсальную последовательную шину.

Три «замечательных» уровня стека USB

Меня не устроил вид стека USB, который можно встретить чаще всего на просторах сети:Не сильно полезный стек USB
Уровень шины, логический, функциональный… Это, конечно, замечательные абстракции, но они скорее для тех, кто собирается делать драйвер или прикладной софт для хоста. На стороне же микроконтроллера я ожидаю шаблонный конечный автомат, в узлы которого мы обычно встраиваем свой полезный код, и он сперва будет по всем законам жанра глючить. Или же глючить будет софт на хосте. Или драйвер. В любом случае кто-то будет глючить. В библиотеках МК тоже с наскока не разобраться. И вот я смотрю на трафик по шине USB анализатором, где происходящие события на незнакомом языке с тремя замечательными уровнями вообще не вяжутся. Интересно, это у меня от гриппозной лихорадки в голове такой диссонанс?

Если у читателя бывали сходные ощущения, предлагаю альтернативное, явившееся мне неожиданно ясно в перегретом мозгу видение стека USB, по мотивам любимой 7-уровневой модели OSI. Я ограничился пятью уровнями:

Я не хочу сказать, что весь софт и библиотеки уже сделаны или должны проектироваться, исходя из этой модели. Из инженерных соображений код c уровнями будет сильно перемешан. Но я хочу помочь тем, кто начинает своё знакомство с шиной USB, кто хочет понять протоколы обмена устройств и терминологию предметной области, подобраться поближе к готовым примерам, библиотекам и лучше ориентироваться в них. Эта модель не для загрузки в МК, но в ваши блестящие умы, дорогие друзья. А ваши золотые руки потом всё сами сделают, я не сомневаюсь:)

Итак, поехали, поправляйте, если увидите косяки. Это draft-версия, и если уже такое где-то было нарисовано, прошу простить, я не нашёл и потому скрутил сам. Думаю, картинка никуда не убежит, а я пока объясню почтенной публике, зачем вообще взялся за эту публикацию.

Очередной флэшбэк из девяностых

Свой первый баг из чужого кода я вытряхнул в конце девяностых, будучи студентом на подработках. Это был pppd под FreeBSD, который мы тогда прикрутили на модемный пул. Мотороловские модемы залипали в отбое, дозвониться никто не мог, линия пропадала зазря, и единственный оставшийся способ через PPP keep-alive почему-то глючил. Вот тогда я и выяснил, что pppd зачем-то ждёт шесть ответных байтов LCP вместо положенных четырёх. Почувствовал я себя тогда эдаким лихим жукотрясом из девяностых:-) При чём тут PPP? Просто он на USB похож: пакетный и двухточечный. Правда, в отличие от USB 2.0, полнодуплексный.

Хотим мы этого или нет, но эволюция микроконтроллеров на месте стоять явно не собирается. Нет, нет, да и мелькнёт в публикациях (http://habrahabr.ru/post/208026/, http://habrahabr.ru/post/233391/) «тяжёлая периферия» — вмонтированные в МК реализации шины USB, с разборами примеров, использованием HID и т.п. Надо воздать должное автору RaJa: из восьми примеров, приведённых в стандартной библиотеке STSW-STM32121 (UM0424) и кое-как документированных, он выбрал самый полезный (Custom HID), портировал его в бесплатную среду Em::Blocks, изложил понятным языком, немного приукрасил, браво! Это сэкономило мне уйму времени.

Как пройти в библиотеку?

Получив на GitHub любезно выложенный автором проект RHIDDemo для Em::Blocks, я начал портировать его в Keil (мой отладчик CoLink на базе FTDI; кто-нибудь, подскажите плагин от Coocox для Em::Blocks). Но никак не мог понять: где, чёрт возьми, автор раздобыл SPL 3.6.1 выпуска 2012г, если на сайте выложен 3.5.0 от 2011г? Я прошёл довольно скучный квест, который к моему удивлению привёл… прямо на готовый проект Custom HID для Keil в составе библиотеки USB FS 4.0.0. Лежит у всех на виду, как мышь под веником. Ну и ладно. Зато я раскурил, наконец, релизы STMicroelectronics, нашёл описание библиотеки USB FS STSW-STM32121 (UM0424) и пресёк попытки разработчика свести меня с ума. Вот скажите, это нормально подкладывать винтажный CMSIS 1.30 образца 2009г в набор SPL 3.5.0 выпуска 2011г, новый SPL 3.6.1 релиза 2012г прятать в USB-FS 4.0.0 релиза 2013г (подложив туда же и CMSIS 3.0.1 от 2012г), при том, что у них же выложена актуальная версия CMSIS 3.30 релиза 2014г? Кстати, в SPL 3.6.x для STM32F10X исправили пару багов с USART, касающихся сигналов о переполнении буфера. Спасибо, хоть release notes оставили…

HID vs SNMP

Итак, взявшись за STM32F103C8T6, я тоже решил слегка задвинуться по теме USB HID, уж больно хорошо абстракция USB HID укладывается в концепцию всяческих датчиков, сенсоров и прочих ШИМ-управляемых драйверов питания. Чем-то напомнило мне SNMP, только в сильно упрощённом виде: дескрипторы HID играют роль SNMP MIB. Когда устройство инициализируется хостом: «Привет, хост! Я кофеварка. У меня есть кнопка [старт], регуляторы [сливки], [сахар], датчики [остаток кофе], [остаток воды], [остаток сахара], [остаток сливок]. Подтягивай драйвера, дави на кнопку, кофейку попьём». Ничего не напоминает? Пример диалога по SNMP: «Ну, привет, управляющая станция с софтом за $100000. А я шасси коммутатора за $200000, и на мне сидят ещё 4 модуля по $100000 за штуку; в каждом ещё по 16 портов с неприличной скоростью, и всех функций тут просто не перечислить… спрашивай отдельно по каждому пункту; ах, да загрузка процессора такая-то, памяти столько-то…». И ещё на дюжину страниц в таком же духе.

Понравилась мне идея HID. Но стоило выйти из Windows за рамки учебных задач мигания светодиодами (вперёд к реальным окружениям UNIX!), как начало сквозить из всех незаделанных щелей, и я почувствовал себя каким-то беспомощным ламером. Отлаживая проект, я инстинктивно схватился за некое подобие tcpdump (так и называется: usbdump(8), или usbmon), но увидел лишь сообщения на незнакомом языке.

Стало очевидно: не хватает фундаментальных знаний о шине USB. Если модель OSI и стек TCP/IP любой тёртый айтишник осознаёт где-то на уровне спинного мозга просто в силу необходимости, то с USB ситуация другая. Оно и понятно: там можно (нужно) подсмотреть трафик через тот же tcpdump да настроить железо с софтом, а тут полный plug and play, и исправить что-то можно, обновив драйвер или прошивку (или переустановив ОС). Но ведь мы тут с вами собрались как раз за тем, чтобы делать хорошие прошивки, не так ли? Почитав некоторые описания USB в сети, я был удивлён, насколько запутанной может быть документация. У меня даже возникло ощущение, что нас специально хотят сбить с пути истинного, напустив туману и избавившись от конкуренции в зародыше. Я не согласен с таким положением вещей!

Ещё одна замечательная схема

На просторах сети встретил ещё такую иллюстрацию (лежало в формате BMP, без шуток):

Сперва выглядит оптимистично. Наконец-то, стек в разобранном виде. Кадры, правда, обозначены неудачно: я бы нарисовал их вертикальными пунктирными линиями, а EOF — это просто пауза, реально данные не передаются. Но начинаем читать контекст и теряем понимаем истинный замысел автора (запутать нас):

Хост-контроллер интерфейса шины USB формирует кадры;
Кадры передаются последовательной передачей бит по методу NRZI.

И вот ещё:

каждый кадр состоит из наиболее приоритетных посылок, состав которых формирует драйвер хоста;
каждая передача состоит из одной или нескольких транзакций;
каждая транзакция состоит из пакетов;
каждый пакет состоит из идентификатора пакета, данных (если они есть) и контрольной суммы.

Вроде бы и нарисовано всё правильно, но по мере прочтения вопросов становится всё больше. Минимальная передаваемая структура данных по шине — это кадр или пакет? Вообще, это сверху вниз надо смотреть или наоборот? И что кодируется по методу NRZI — кадры, пакеты или просто весь битовый поток по шине? Из транзакций состоит посылка, передача, или, может быть, ценная бандероль какая?
Почему нельзя просто: хост группирует пакеты в транзакции и распределяет их по временным квантам, именуемым кадрами, чтобы давать приоритет критичным по времени данным (видео, аудио) исходя из текущей пропускной способности шины? Да, в USB есть нюансы с планированием передачи пакетов, я их пока не затрагиваю.

Моё видение стека USB

Хорошей документацией считаю упоминавшийся тут на хабре USB in a NutShell (ура, перевод), а также USB Made Simple. По ним я и собрал свою версию стека USB, нарисую её ещё раз.

Физический уровень

На физическом уровне используется набор электрических режимов дифференциальной пары проводников (вместе с землёй) для обозначения состояний, с помощью которых кодируется битовый поток по методу NRZI со вставкой битов (bit stuffing): здесь после шести идущих подряд «1» (ну захотелось передать, скажем, 0xffff) вставляется «0», чтобы приёмник подолгу не залипал в одном состоянии; приёмник узнает вставленный «0» и как данные не засчитает, это довольно распространённый приём в кодировании для лучшей автоподстройки частот. Пара проводов вместе с землёй даёт возможность сформировать, как минимум, четыре статических состояния (они обозначаются J, K, SE0, SE1). В USB 2.0 SE1 не используется, а три оставшихся дополнительно разыгрываются в динамике (с часами и переходами) для передачи ещё нескольких управляющих символов (границы пакетов, сброс, подключение/отключение, энергосбережение/выход). Хорошие иллюстрации есть в USB Made Simple, Part 3 — Data Flow.
Т.е. в итоге передаются данные в виде ноликов и единичек, плюс всякие управляющие символы, чтобы можно было из всей этой электродинамической кухни готовить нормальные пакеты данных.
(дополнено по просьбе читателей)

Пакетный уровень

На пакетном уровне между хостом и устройством передаются безадресные пакеты (пара устройств на полудуплексной линии может обойтись и без адресации). Пакет состоит из маркера SYNC для синхронизации тактов приёмника, последовательности байт и символа EOP. Длина пакета переменная, но оговаривается через верхние уровни стека. Первый байт называется Packet Identifier (PID), имеет простой избыточный формат для помехоустойчивости и пригоден для скармливания автомату следующего уровня (для сборки транзакций из пакетов). Пакеты с начинкой (длиннее одного байта PID) снабжаются контрольной суммой (короткой CRC5 или длинной CRC16, в зависимости от типа пакета). Анализатор протоколов должен, как минимум, показывать нам пакеты.

Уровень транзакций

На следующем уровне из пакетов собираются транзакции. Транзакция — это малый набор пакетов (в Full Speed USB 1, 2 или 3), следующих строго друг за другом, которыми (в полудуплексном режиме) хост обменивается с оконечной точкой (endpoint), и только с одной. Очень важно, что транзакцию открывает только хост, это специфика USB (нам в прошивке МК меньше мороки). На уровне транзакций можно говорить о канале (pipe) между хостом и одной из оконечных точек устройства, но я намеренно избегаю термина «канальный уровень» (Data Link) из модели OSI. Анализатор протоколов должен хотя бы декодировать транзакции.

Уровень передач

Поверх транзакций расположим уровень передач (transfers). Их в USB используется четыре типа: контрольные с оконечной точкой №0 (control transfers), передачи с прерываниями (interrupt transfers), изохронные (isochronous transfers) и крупноблочные передачи (bulk transfers). Последние три являются вариантами потоковых каналов (stream pipe), про которые я ещё скажу несколько слов. Этот уровень тоже должен отобразить хороший анализатор протоколов.

Прикладной уровень

Венчает стек, как обычно, прикладной уровень. Здесь происходят: установка адреса устройству хостом, рассказ устройства о себе на языке дескрипторов, команды хоста на выбор конфигурации (контрольные передачи), обмен данными с HID-устройствами (в примерах пока нашёл передачу с прерываниями, хочу попробовать контрольную), печать на принтере и сканирование, доступ к накопителю USB (крупноблочные), общение через гарнитуры и веб-камеры (изохронные) и многие другие замечательные вещи.

Последний штрих

Сбежав на секунду вниз по уровням, можно добавить, что хост периодически вбрасывает по шине те самые пакеты Start of Frame (SOF), разбивая время на равные интервалы, но так, чтобы не разбить при этом сами транзакции. Поэтому пакеты SOF можно считать самостоятельными транзакциями. Не следует путать кадр (фрейм) USB с омонимом канального уровня модели OSI. Лучше уж вспомнить кадры (фреймы) аудио CD, это просто квант времени: хост «тикает» в шину пакетами SOF, чтобы подключённые устройства заранее планировали участие в т.н. изохронных передачах, гоняющих потоки данных в реальном времени. Ну или вот так: группы транзакций планируются хостом по временным интервалам, именуемым кадрами. Кадр составляет 1мс на Full Speed и 125мкс на High Speed USB, но High Speed — более сложный стандарт, его лучше изучать отдельно.
UPD:
Хороший вопрос задали читатели: а как насчёт фрагментации? Я не нашёл в USB 2.0 признаков фрагментации на уровне транзакций и ниже, т.е. транзакции для того и есть, чтобы передаваться целиком. Передачи же в ряде случаев могут и должны разбиваться на несколько транзакций, особенно с учётом изохронных режимов. И я повторю, что всем планированием у нас пока заведует хост (на стороне МК меньше думать приходится).

Смотрим на трафик по USB

Хорошая подборка иллюстраций есть в упомянутой книжке USB Made Simple, глава 5: www.usbmadesimple.co.uk/ums_5.htm
Вот одна из них
Итак, транзакция всегда инициируется хостом в отношении одной выбранной оконечной точки на устройстве (помимо специальной точки с номером 0, их может быть ещё до 15 штук на одном устройстве, например, комбинированная клавиатура с мышью, термометром, флэшкой, кофеваркой и кнопкой вызова сантехника заказа пиццы).
В случае приёма хостом данных с устройства последнее не может само открыть транзакцию, но может только дождаться нужного момента и поучаствовать в ней. Хост открывает транзакцию устройству пакетом с PID = IN (группа Token) и гарантирует на нужное время свободу шины, устройство вбрасывает пакет из группы Data, в зависимости от типа транзакции хост может подтвердить успех третьим пакетом из группы Handshake (ACK, NAK, STALL, NYET), транзакция закрыта.
При отправке данных на устройство (PID = OUT, группа Token) хост открывает транзакцию, отправляет пакет с данными (Data), также в зависимости от режима может принять пакет Handshake с подтверждением успешности транзакции.
По окончании транзакции всё вернётся на круги своя, устройство снова будет ждать управляющих пакетов от хоста.

Режимы передачи USB в примерах STM32 USB FS

Чтобы по одной паре проводов можно было гнать копирование с диска одновременно с аудио-видео потоком, жестами мышью и сигналом скоростного осциллографа, существуют разные типы сообщений и передач.
Чуть выше я только что описал простой потоковый канал (Stream Pipe) между хостом и оконечной точкой, где пакеты с начинкой (группы Data) не несут никакой специальной или управляющей информации самой подсистеме USB. Полная свобода переписки, библиотека контроллера должны предоставлять примитивы для закачки буфера произвольного размера из памяти МК хосту или обратно. Нарезкой на пакеты, пересылкой и «дефрагментацией» пусть занимаются библиотека МК на пару с драйвером хоста. В STM32 это USB_SIL_Write() и USB_SIL_Read(), описаны в UM0424. Они и есть тот самый логический уровень абстракции. На стороне хоста см. описание соответствующего драйвера (например, во FreeBSD это ugen(4)).
Однако использовать тяжёлую периферию вроде USB для организации простого потокового канала я считаю кощунством (спрашивается: чем USART не угодил?). Но ситуации, конечно, бывают всякие.
В любом случае, чтобы подсистема USB вообще ожила и устройство определилось, требуется обмен контрольными транзакциями.

DISCLAIMER

Дальше будут упоминаться примеры из той самой библиотеки UM0424 для работы с Full Speed USB от STMicroelectronics, но они рассчитаны под их родные демоплаты. Берите пример с автора Raja, проявляйте инженерную смекалку в адаптации проектов под свою демоплату.

По софту всё понятно: это примеры не для промышленного использования, там могут быть баги, некоторые части (типа таблицы ссылок в примере Mass storage) защищены патентом, и вы не имеете прав их использовать в коммерческом проекте. Но это ещё ничего, китайцы ухитряются потом продавать на рынке USB-изделия, у которых даже библиотечные VID и PID не удосужились поменять.

По железу, как я понял, надо начинать с кварца. У меня челябинский PinBoard II с кварцем 12Мгц (все библиотеки заточены под 8МГц), я менял умножитель ФАПЧ с 9 на 6 (ссылка с разъяснениями), иначе МК разгонится до 108МГц вместо 72МГц, а USB на 72МГц вместо положенных 48МГц вообще не поедет. Можно ещё сбавить обороты МК до 48МГц, поменяв делитель шины USB с полутора до единицы. Использовать внутренний генератор МК HSI спецы не любят: частота может слегка уплыть от нагрева, последствия для USB предсказать затрудняюсь. Ну и не забываем о периферии, конечно. Без флэш-памяти SPI/SDIO из примера Mass storage можно сделать разве что аналог /dev/null, но его ведь хрен отформатируешь:-)

Контрольные передачи и каналы сообщений

Думая про USB, вспоминаю добрый старый протокол PPP с его LCP, IPCP, CCP и ещё хзCP. Обмен хоста с оконечной точкой №0 сообщениями особого вида и есть местный эквивалент xзCP.
Через контрольные передачи устройство инициализируется, получает адрес, рассказывает о себе хосту на языке дескрипторов (чтобы тот подыскал и активировал нужный драйвер). Без контрольных операций не «поедут» и простые потоковые передачи, если устройство не ответит по форме, хост поскорее заглушит порт: протокол надо соблюдать.
В принципе, протокол не запрещает повесить на контрольную точку №0 и обмен данными, аналогично режиму с прерываниями. Заодно задумайтесь: как будете обновлять прошивку МК, так сказать, в полевых условиях? Программатор наготове держать? Есть и другое решение.
Пример: Device firmware upgrade

Передачи с прерываниями

Эта разновидность (interrupt transfer) предназначена для обмена небольшими транзакциями, сходными с контрольными. Нет, устройство не может прерывать хоста, оно ждёт опроса, их частота и размеры пакетов оговариваются заранее в дескрипторе устройства. Хорошо подходят для всевозможных пультов, датчиков, сенсоров, мышек, светодиодов и прочих HID-кофеварок. Канал с прерываниями каждой точки однонаправленный.
Примеры: Custom HID, Joystick mouse, Virtual COM port

Передачи изохронные

Χρόνος по-гречески значит «время». Изохронная передача (isochronous transfer) — местный хайтек, позволяющий управлять потоками данных в реальном времени. Отличается гарантированной (но необязательно широкой) полосой пропускания и отсутствием подтверждающих транзакций, почти как UDP с QoS. Битый пакет? Это бог Хронос толкнул МК по ноге. Не надо пытаться отправить пакет заново, иначе бог огорчится. Контрольные суммы, тем не менее, проверяем втихую от Хроноса. Изохронные передачи хороши для аудио-видео и измерительных систем реального времени, а также прочих игрушек двойного назначения. Хотя на некоторые из них м.б. интереснее повесить какой-нибудь AVR, связав его с нашим ARM по USART или SPI. Изохронные операции участвуют во фреймовой сигнализации (вспомним про тиканье пакетом SOF).
Пример: USB voice speaker

Передачи крупноблочные

Нет, мешки с цементом таскать не будем. Я думаю, все узнали режим работы всевозможных накопителей USB. Передачи bulk transfer имеют цель отправить данных как можно больше и быстрее, обязательно с пересылкой битых пакетов, но без гарантий по полосе пропускания, уступая её изохронным передачам при необходимости (как в TCP без QoS). О внутреннем устройстве USB флэшек я как-то уже рассказывал, теперь можно скачать и запустить действующий прототип. Я сам его не пробовал, но таблица команд SCSI в описании примера (как-бы, между прочим) весьма символизирует. Признаков алгоритма управления износом для NAND-памяти я не нашёл:-)
ВНИМАНИЕ: местами действует патентная защита STM.
Пример: Mass storage

Что осталось нераскрытым

Я не имею цель сделать ещё один учебник по USB, их и без меня хватает, и там хорошо описаны: электрическая часть, подробности протоколов, работа с концентраторами, дескрипторный язык и уровень абстракции HID, проблемы с уникальностью VID/PID, USB 3.0 и многие другие замечательные возможности шины USB, как полезные нам, так и не очень. Айтишникам особо рекомендую экскурсию на тёмную сторону с обзором вражеских девайсов (флэшка с замаскированной HID-клавиатурой, которая будет делать страшные вещи).

Ссылки

Адаптация примера Custom HID к бесплатной среде Em::Blocks и бюджетной демо-плате STM32F103C8T6 производства LC-Tech: habrahabr.ru/post/208026
Битва за ИБП: habrahabr.ru/post/233391 ещё одна битва за ИБП: habrahabr.ru/post/233391/#comment_7944489
Экскурсия на тёмную сторону (шпионский девайс из AVR): habrahabr.ru/post/153571
Инструкции по анализу USB в Wireshark для Windows и Linux: wiki.wireshark.org/CaptureSetup/USB
Книжка USB in a NutShell: www.beyondlogic.org/usbnutshell/usb1.shtml
Перевод USB in a NutShell: microsin.ru/content/view/1107/44
Книжка USB Made Simple (действительно упростили): www.usbmadesimple.co.uk
STSW-STM32121, библиотека STMicroelectronics USB full speed device library и все упомянутые примеры (UM0424) www.st.com/web/en/catalog/tools/PF258157

P.S.
Читая публикации на хабре, посвящённые в той или иной степени микроэлектронике, я разглядел две инженерных касты, назовём их условно: Промэлектронщики и Айтишники. Это своего рода инженерный Инь и Ян, в каждом из нас есть доля того и другого.

Промэлектронщики имеют блестящие знания и навыки по железу, паяют радиодетали толщиной с волос левой рукой с закрытыми глазами (причём потом это работает). Взглянув на электронную схему, почти физически начинают ощущать все её токи с потенциалами, работают также и с силовыми схемами, и с (большими, быстрыми, опасными) промышленными изделиями. Подход к программированию МК соответствующий: он просто должен выдать нужные логические уровни на нужные ножки в нужное время, не столь важно каким способом. Консервативны в технологиях (не влезай — работает), тяжёлую периферию МК не особо жалуют. При обсуждении объектно-ориентированного программирования, информационной безопасности, гигантских проектов в миллион строк кода и всяких навороченных графических интерфейсов скучнеют. Вместо пакетно-ориентированной шины USB предпочитают потоковый режим USART, усиленный либо привычным RS-232, либо более брутальным RS-485 (последовательная шина для промышленных применений, до 10Мбит/с на 15м, до 100кБит/с на 1200м, до 32 устройств).

Айтишники воспитаны на понимании операционных систем, сетевой инфраструктуры и сложных взаимодействий, элита хорошо подкована в информационной безопасности и разбирается во всяких незримых способах проникновения в чужую систему. Некоторые при этом очень любят котиков (ну как их можно не любить? я, правда, не держу, не развожу и не готовлю:-). Многие любят свободу информации, ругать корпорации/правительства и побеждать силы природы усилием мысли. Паталогически ленивы, но обожают новые технологии и закрученные инженерные ребусы с дорогими игрушками (желательно решаемые на уровне софта или, в крайнем случае, перемычек). Отношения с паяльником настороженные: не спрашивайте у айтишника, любит ли он паяльник, может неправильно понять; лучше спросите, любит ли он паять электронные схемы.

К чему я? Мы просто видим этот мир по-разному… Ведь ядро Linux кроили такие же ребята, из модулей на С и ассемблерных вставок для конкретных платформ, и без холиваров вроде обошлись. По-настоящему серьёзный проект я вижу как многоядерную систему, сочетающую современнейшие МК с тяжёлой периферией, но не исключаю связки с классическими моделями типа AVR: ими можно обвесить какие-нибудь критичные быстровращающиеся острия технического прогресса. Если код проверенный годами, то почему нет?

habr.com

Интерфейс USB. Часть 2. Как происходит передача данных по шине — radiohlam.ru

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

Итак, пусть мы хотим из клиентского ПО отправить какие-то данные к конечной точке нашего девайса. Мы посылаем IRP к каналу, который USBD установил с нашей точкой и сообщаем адрес буфера, где лежат данные, которые нам нужно отправить, и размер пересылаемого блока данных. Что происходит с этими данными дальше?

А дальше с ними начинает работать 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.

Имя	PID	Описание
Идентификаторы маркер-пакетов:
SOF	0101	Идентификатор маркер-пакета начала кадра. Пакет с таким PID содержит в теле 11 младших бит номера кадра, защищённых контрольной суммой CRC5.
SETUP	1101	Идентификатор маркер-пакета транзакции управления. Пакет с таким PID содержит в теле семибитный адрес устройства, четырёхбитный номер конечной точки, с которой хост хочет «пообщаться», и контрольную сумму CRC5.
OUT	0001	Идентификатор маркер-пакета транзакции вывода. Пакет с таким PID содержит в теле семибитный адрес устройства, четырёхбитный номер конечной точки, которой хост будет слать данные, и контрольную сумму CRC5.
IN	1001	Идентификатор маркер-пакета транзакции ввода. Пакет с таким PID содержит в теле семибитный адрес устройства, четырёхбитный номер конечной точки, откуда хост будет получать данные, и контрольную сумму CRC5.
Идентификаторы пакетов данных:
Data0	0011	Идентификатор пакета данных. Пакет с таким PID содержит в теле n байт данных, защищённых контрольной суммой CRC16.
Data1	1011	Идентификатор пакета данных. Пакет с таким PID содержит в теле n байт данных, защищённых контрольной суммой CRC16.
Data2	0111	Идентификаторы дополнительных типов пакетов, используемых в транзакциях с широкополосными изохронными точками (для HS в USB2.0)
MData	1111
Идентификаторы пакетов подтверждения:
ACK	0010	Пакет с таким PID состоит только из заголовка (тело пакета пустое — никаких данных и контрольной суммы нет) и используется для подтверждения безошибочного приёма пакета данных.
NAK	1010	Пакет с таким PID состоит только из заголовка и используется для сообщения хосту о неготовности конечной точки к обмену данными (индикация занятости).
STALL	1110	Пакет с таким PID состоит только из заголовка и используется для сообщения хосту о необходимости его вмешательства для разрешения проблемы.
NYET	0110	Пакет с таким PID состоит только из заголовка и используется для подтверждения безошибочного приёма и сообщения об отсутствии места для приёма следующего пакета максимального размера (в USB2.0)
Идентификаторы специальных пакетов:
PING	0100	Пакет с таким PID является пробным маркером управления потоком (USB2.0). Таким маркером хост как бы предварительно спрашивает устройство, готово ли оно принимать данные, вместо того, чтобы сразу эти данные послать (потому что, если устройство не готово и пришлёт NAK, то всю отправку данных придётся повторять заново).

Остальные специальные пакеты не будем рассматривать, поскольку они нам пока не понадобятся.

Идём дальше. Во всех полях пакетов, кроме поля 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+SE0 (single-ended zero).

Для идентификации скорости работы устройства используется резистор на 1,5 кОм, подтягивающий одну из сигнальных линий к высокому сигнальному уровню (+3,3В). Для LS-устройств подтягивается линия D-, для FS/HS-устройств подтягивается линия D+.

Сигналы Diff0 и Diff1 кодируют состояния шины, которые называются J (data J state) и K (data K state). Для LS состояние J соответствует сигналу Diff0, а состояние K — сигналу Diff1. Для FS/HS наоборот — J соответствует сигналу Diff1, K — сигналу Diff0.

Состояние покоя шины (bus idle) для LS/FS соответствует длительному состоянию J, а для HS — состоянию SE0.

Признаком начала передачи является переход из состояния покоя в состояние K. Поскольку первым всегда передаётся нулевой бит (любая передача начинается с передачи синхропоследовательности), то это первоначальное состояние K соответствует нулевому биту, дальнейшее значение передаваемых битов определяется в соответствии с NRZI кодированием.

Для обозначения конца пакета (EOP) на LS/FS используется сигнал SE0, длительностью 2 битовых интервала. На HS сигналом EOP служит передача специальной последовательности b’11111110′ (младшим битом вперёд, не используя технику bit stuffing). Приёмник отслеживает нарушение техники вставки бит (сигнал на шине не изменяется течении семи битовых интервалов) и считает это признаком конца пакета.

На этом пока всё, дальше мы рассмотрим, какие стандартные действия должно уметь делать любое USB-устройство, какую информацию содержать, как и на какие запросы отвечать.

1. Часть 1. Основы.
2. Часть 2. Как происходит передача данных по шине.
3. Часть 3. Что должно уметь любое USB-устройство.
4. Часть 4. Дескрипторы и классы.
5. Часть 5. Программная реализация low speed устройства USB. Схема.
6. Часть 6. Программная реализация LS устройства USB. Физика и приём пакетов.
7. Часть 7. Программная реализация LS устройства USB. Разбираем пакеты по типам.
8. Часть 8. Программная реализация LS устройства USB. Передача по USB произвольного буфера и пакетов подтверждения.
9. Часть 9. Программная реализация LS устройства USB. Продолжаем разбираться с принятыми пакетами.

radiohlam.ru

Протоколы USB

[Глава 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 имеет длину 8 бит на low speed и full speed или 32 бита на high speed, и используется для синхронизации тактов приемника с тактами передатчика. Последние 2 бита показывают, где начинается поле PID.

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

Группа	Значение PID	Идентификатор пакета
Token	0001	OUT Token
	1001	IN Token
	0101	SOF Token
	1101	SETUP Token
Data	0011	DATA0
	1011	DATA1
	0111	DATA2
	1111	MDATA
Handshake	0010	ACK Handshake
	1010	NAK Handshake
	1110	STALL Handshake
	0110	NYET (No Response Yet)
Special	1100	PREamble
	1100	ERR
	1000	Split
	0100	Ping

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

PID0

PID1

PID2

PID3

nPID0

nPID1

nPID2

nPID3

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

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

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

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

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

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

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

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

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

Sync

PID

ADDR

ENDP

CRC5

EOP

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

Data0
Data1

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

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

Имеется 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.

Sync

PID

Frame Number

CRC5

EOP

Сейчас мы уже должны знать ряд понятий, составляющих пакет 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.

webhamster.ru

Интерфейс USB. Введение. / Связь железа с компьютером. / Сообщество EasyElectronics.ru

В данном цикле статей будет рассмотрен под разными углами интерфейс USB (USB 2.0) Попробуем разобраться, как он работает и закрепить полученные знания практически. «Копать» мы будем достаточно глубоко, не коснемся только физического уровня передачи данных (вернее коснемся вскользь). Физический уровень возьмет на себя соответствующий периферийный модуль МК.

Все примеры, которые я буду приводить, будут привязаны к линейке МК AT91SAM7S. Так как эта линейка МК не очень популярна в Сообществе, я постараюсь акцентировать внимание на работе самого интерфейса и по минимуму затрону специфические для этого МК особенности реализации.

Примеры будут базироваться на «глубоко модернизированном» и достаточно низкоуровневом примере реализации USB от Atmel. Готовые библиотеки рассматривать не будем. Не по тому, что это плохо, просто наша цель разобраться — как работает интерфейс.

В качестве практического задания – давайте поставим целью создать CDC-ACM устройство. На практике, за сокращением CDC-ACM стоит «обыкновенный» виртуальный СОМ-порт. С терминологией разберемся позже, пока скажем так: на уровне ОС устройство будет автоматически распознаваться как последовательный интерфейс (COM-порт в Win, /dev/ttyS в Linux и т. д.).

И так, поехали…

Общие сведения.

USB –последовательный интерфейс, используемый для подключения периферийных устройств. Соответственно, существуют понятие «главное устройство» (хост, он управляет обменом данными через интерфейс, выступает инициатором обмена) и «периферийное устройство» (клиент, в процессе обмена данными «подчиняется» хосту).

Логика работы у хоста и клиента принципиально отличается, соответственно нельзя напрямую соединять устройства «хост – хост» и «клиент – клиент».

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

Полагаю, изложенные факты общеизвестны, двигаемся далее.

Физический уровень.

Физически интерфейс USB использует 4 провода: «земля (GND)», «+5В (VBUS)», «D+», «D-». Первые два могут использоваться для питания периферийного устройства (максимальный ток 500 мА). Два последних служат для передачи данных (обозначение D+ и D- условны, с электрическими потенциалами это никак не связанно).

Как я уже сказал, физическую передачу данных через D+ и D- нам обеспечит USB модуль МК.

Нам нужно знать следующее:

1. Питание на периферийное устройство подается сразу после подключения к USB разъему хоста. Сам разъем сконструирован таким образом, что первыми входят в «зацепление» контакты «GND» и «VBUS», только потом «D+» и «D-».

2. Подключение устройства к USB разъему хоста не означает, что хост сразу определит подключение нового устройства. Если не вдаваться в подробности, подключение/отключение устройства хост определяет по наличию вешней подтяжки на линиях D+ и D-. Такая формулировка очень упрощена, детально ознакомиться с вопросом можно в разделе 7.1.7.3 официальной спецификации USB 2.0.

В нашем случае, для того чтобы «заявить о себе» нужно подтянуть линию D+ посредством сопротивления 1.5 кОм к напряжению 3.3 вольта. Если мы уберем данную подтяжку – хост определит отключение устройства.

Подтяжку можно сделать постоянной (в таком случае хост будет определять подключение / отключение устройства одновременно с подключением / отключением устройства к разъему USB), либо управлять подтяжкой через ключ, дергая ногой МК (тогда наше устройство сможет самостоятельно подключатся и отключатся от хоста).

Логический уровень

На логическом уровне, обмен данными происходит через некоторые логические, виртуальные каналы внутри одного физического USB интерфейса. Такие каналы называют «Конечными точками» (EndPoints).

Конечные точки (каналы) бывают 4 видов:

Control – данный тип канала используется хостом для управления периферийным устройством. Хотя иногда данный тип канала используется для передачи данных.

Bulk — данный тип канала используется для обмена данными. Гарантирование целостности данных и гарантированная доставка данных для данного типа канала реализована «в железе». Однако скорость передачи данных по такому каналу ограничена.

Isochronous — данный тип канала в основном используется для обмена потоковыми данными. Целостность и доставка данных не контролируются, зато скорость значительно выше чем для Bulk каналов.

Interrupt – используются для реализации подобия «прерываний». Такие «прерывания» являются логическими, и никак напрямую не связанны с аппаратными прерываниями МК или прерываниями ОС.

Минимальная реализация USB устройства требует наличие всего одного Control канала (так называемая «нулевая конечная точка»). Остальные типы каналов, как и их количество определяет разработчик устройства исходя из функций устройства.

Однако, существуют некоторые стандартизированные классы USB устройств. Для каждого такого класса количество каналов, их типы и назначение установлено стандартом для данного класса устройств.

Мы стремимся создать устройство класса CDC (communications device class). Использование стандарта, в данном случае, избавит нас от необходимости писать драйвер для ОС. Как правило, драйвера для стандартных классов устройств уже «вшиты» во все популярные ОС.

Детально ознакомляться с типами каналов будем по ходу реализации нашего устройства. Забегая наперед, скажу, что в нашем устройстве будет 3 канала. Control канал для управления и два Bulk канала для предачи данных по направлению «ПК-МК» и, соответственно «МК-ПК».

Первая — вводная статья получилась слишком теоретической.

В следующей статье мы поговорим о дескрипторах USB устройства и рассмотрим процедуру инициализации устройства (запрос дескрипторов хостом и т. д.). Увы, но опять будет много теории, запаситесь терпением. 🙂 Ничего, нам осталось «пережевать» дескрипторы устройств, после чего появятся примеры кода.

Скачать официальную спецификацию USB 2.0 можно здесь.

Продолжение следует.

we.easyelectronics.ru

USB

Подробности

Родительская категория: USB

Категория: Физический интерфейс USB

Кабель USB содержит две пары проводов: одну для сигнальных цепей (D+ и D-) и одну пару для схемной земли (GND) и подачи питания +5 В (Vbus). Допустимая длина сегмента (кабеля от устройства до хаба) — до 5 м. Ограничения на длину сегмента диктуются затуханием сигнала и вносимыми задержками. Задержка распространения сигнала по кабельному сегменту не должна превышать 26 нс, так что при большой погонной задержке допустимая длина кабеля может сократиться. Максимальное удаление устройства от хост-контроллера определяется задержкой, вносимой кабелями, промежуточными хабами и самими устройствами.

В кабеле USB 1.x для сигнальных цепей используется витая пара проводов калибра 28AWG с импедансом 90 Ом. Характеристики кабеля нормированы в частотном диапазоне до 16 МГц. Для питания используется неперевитая пара проводов калибра 20AWG–28AWG. Требований к экранированию кабелей в USB 1.x не выдвигалось. Для низкой скорости может использоваться кабель с неперевитой парой сигнальных проводов (он дешевле и тоньше), но его длина не должна превышать 3 м.

В кабелях USB 2.0 используются провода тех же калибров, но в спецификации описана конструкция кабеля, в которую входит обязательный экран и связанный с ним дополнительный проводник. Такой кабель пригоден для работы на любых скоростях, включая и HS (480 Мбит/с).

Разъемы USB сконструированы с учетом легкости подключения и отключения устройств. Для обеспечения возможности «горячего» подключения разъемы обеспечивают более раннее соединение и позднее отсоединение питающих цепей по отношению к сигнальным. В USB определено несколько типов разъемов:

• тип «A»: гнезда (рисунок а) устанавливаются на нисходящих портах хабов, это стандартные порты подключения устройств. Вилки типа «A» устанавливаются на шнурах периферийных устройств или восходящих портов хабов;
• тип «B»: используются для шнуров, отсоединяемых от периферийных устройств и восходящих портов хабов (от «мелких» устройств — мышей, клавиатур и т. п. кабели, как правило, не отсоединяются). На устройстве устанавливается гнездо (рисунок б), на кабеле — вилка;
• тип «Mini-B» (рисунок в): используются для отсоединяемых шнуров малогабаритных устройств;
• тип «Mini-A»: введен в спецификации OTG, вилки используются для подключения устройств к портам малогабаритных устройств с гнездом «mini-AB».
• тип «Mini-AB»: гнезда введены в спецификации OTG для портов двухролевых устройств, которые могут вести себя как хост (если в гнездо вставлена вилка miniA) или как периферийное устройство (если в гнездо вставлена вилка mini-B).

Назначение выводов разъемов USB приведено в таблице, нумерация контактов показана на рисунке выше. Штырьковые разъемы, устанавливаемые на системной плате (рисунок г), предназначены для кабелей-«выкидышей», которыми подключаются дополнительные разъемы USB, устанавливаемые на передней или задней стенках корпуса компьютера (иногда и на боковых). На эти разъемы порты выводятся парами, причем у разных производителей подход к универсальности и защите от ошибочных подключений различен. Подключение «выкидыша», не подходящего к разъему, приводит к неработоспособности порта (к счастью, как правило, временной). Ошибка в подключении цепей GND и +5V может приводить к нагреванию кабелей и разъемов из-за короткого замыкания питающей цепи.

Все кабели USB «прямые» — в них соединяются одноименные цепи разъемов, кроме цепи ID, используемой для идентификации роли устройства в OTG. На вилке mini-A контакт 4 (ID) соединен с контактом 5 (GND), что заставляет порт, к которому подсоединена такая вилка, взять на себя роль нисходящего порта хаба. На вилке miniB такого соединения нет.

Ошибка в полярности подводимого питания может повредить подключаемое устройство (и необратимо). По этой причине наиболее безопасными для подключаемого устройства являются внешние разъемы USB, запаянные на системной плате или карте контроллера USB.

 

Таблица. Назначение выводов разъема USB

Цепь	Контакт стандартного разъема	Контакт миниразъема
VBus (+5 В)	1	1
D–	2	2
D+	3	3
GND	4	5
ID	–	4

perscom.ru