Интерфейс USB. Введение.



В данном цикле статей будет рассмотрен под разными углами интерфейс 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 можно здесь.

Продолжение следует.
  • +11
  • 03 ноября 2011, 17:00
  • e_mc2

Комментарии (44)

RSS свернуть / развернуть
К слову, при разработке своего USB стека для stm8, мне помогал сайтик www.usbmadesimple.co.uk/ и пдфка www.beyondlogic.org/usbnutshell/usb-in-a-nutshell.pdf
Буду следить за вашим циклом статей :)
0
разработке своего USB стека для stm8,
О, подробности в студию!
+2
Хы, немного огорчу, стек не полный, а-ля V-USB. Реализация на MAX3420.
Это USB трансивер. Позволяет реализовать любой USB класс.
4 эндпоинта (control + out + 2 in).
SETUP данные попадают в отдельный регистр, так что реализация сводится к разбору этих данных. И ещё он NACK автоматом посылает, если МК отвлекается на другие задачи, так что нет постоянного висения в INT0 прерывании, как в V-USB
Кароче супер штука, позволяет подключить хоть tiny13 :) Лишь бы была реализация SPI протокола. Но микросхемка дорогая — 3.5$
0
Оно вроде бы ещё хост умеет?)
0
MAX3421 умеет, MAX3420 — нет :)
И наверно для реализации хоста в отсутствии ПЛИС, это самое лучшее решение.
0
Спасибо. Как я уже сказал, я постараюсь больше уделять внимание стандарту USB а он, не зависит от конкретного МК, хаба, ОС и т. д. (хотя, здесь, как и везде «есть нюансы»). Основная часть реализации «стека» (хотя понятие «стек» у меня больше ассоциируется с сетевыми протоколами) не зависит от МК.
0
Начало интригующие, будем ждать продолжения.
0
приплюсуюсь. Несмотря на то, что это была «теоретическая часть», написана очень живо и очень интересно. Просто у меня на платке с ПЛИС стоят разъемы USB и контроллеры, но как это все работает пока вообще ни бум-бум. Если статьи будут продолжаться в том же духе, думаю, что многим они будут полезны. Только по возможности не растягивайте сильно удовольствие, пожалуйста. :)
зы. хотел там плюсиков в комменты наставить, но не хватает рейтинга. Как с этим бороться?
0
хотел там плюсиков в комменты наставить, но не хватает рейтинга. Как с этим бороться?
Делить знаниями и опытом с народом! :)
0
было бы чем еще делиться ))))))))
0
А почему ты выбрал AT91SAMxx? Какие у них плюсы? Как с доступностью, ценой, отладочными средствами?
0
  • avatar
  • Vga
  • 03 ноября 2011, 18:20
Да я особо не выбирал — так исторически сложилось, что именно с этой линейкой у меня большой опыт работы и много наработок (ну, не считая AVR). Эту линейку очень любили в одной фирме, с которой мне довелось сотрудничать. Почему они выбрали именно эту линейку – не знаю. Ничем особо чип не выделяется: ARM7, «джентльменский» набор периферии, высокая цена.
Сам думаю о переходе на STM32, но никак не выкрою время – в данный момент я увлекся ПЛИСами :)
0
О-о-о! +100500! Я сейчас как раз USB раскуриваю, как раз на досуге прочитал USB in a nutshell и принялся за чтение стандарта USB 2.0.

Аффтар, пешы пожалуйсто!!!1111
0
  • avatar
  • _YS_
  • 03 ноября 2011, 18:41
Спасибо за поддержку, постараюсь Вас не разочаровать :)
0
Спасибо, буду с нетерпением ждать продолжения.

Сейчас у меня самая главная проблема — понять, какой уровень берет на себя USB-периферия МК. Т.е., я правильно понимаю, что, скажем, проверка CRC для Bulk-передач и повторный запрос в случае использования аппаратного USB происходит автоматически, и то же самое с низкоуровневыми пакетами? Т.е, в USB-буфер можно запихивать сразу, например, структуру дескриптора, не заботясь о, например, заголовке?
0
Совершенно верно, в данном случае Вам достаточно положить данные в буфер, указать размер данных в буфере и выставить флаг готовности данных к отправке. Когда хост в следующий раз опросит наше устройство (само устройство не инициирует передачу данных) МК отдаст данные из буфера хосту позаботившись о CRC и ретрансмитах. По крайней мере, так реализована аппаратная поддержка USB в тех МК, с которыми мне приходилось сталкиваться.
Также следует помнить, что для разных типов ключевых точек существует ограничения на мах. длину предаваемого за раз блока данных.
Но мы забегаем вперед…
0
Спасибо за ответ. Просто я уже подошел к экспериментам (вот-вот впаяю кварц в STM32L-Discovery и начну практиковаться) — ДШ раскурен, USB in a nutshell раскурена, осталось дочитать нужные главы стандарта и поковыряться. Но цикл статей на русском — это, конечно, подарок. Заранее спасибо!
0
Первая — вводная статья получилась слишком теоретической.

Да нет, после чтения стандарта USB Ваша статья выглядят кратким обзором. :D Так что, я думаю, не стоит беспокоиться об утомлении читателя. :)
0
  • avatar
  • _YS_
  • 03 ноября 2011, 19:05
немножко оффтоп…
может и глупый вопрос, но он меня всегда интересовал: почему те же prolific (ныне часть arm) и ftdi не реализуют в своих микросхемах cdc (чтобы преобразователи прикидывались устройствами с cdc), а заставляют пользователей мучатся с драйверами.
0
Ну, насколько я понимаю, АРМ занимается разработкой ядер. Потом, ядро у них покупает, например ATMEL, добавляет своей периферии и выпускает МК.
А что касается аппаратной поддержки CDC – а зачем аппаратно привязывать МК к одному из классов USB устройств? Почему CDC а не HID или MSD? Производитель предоставляет универсальное решение, на базе которого можно построить любое (относительно) USB устройство.
Или я Вас не так понял?
0
Правильно не реализуют. CDC — это класс не для виртуального компорта, а для модема.
Собсна под виндой оно само не поднимается (драйвер есть, но подхватывается тока с дополнительной инишкой), и не работает на скоростях овер 115200. А линух при CDC-девайса подключении начинает посылать ему AT-команды.
мучатся с драйверами
Вот как раз драйвер поставить — вполне естественное действие, и занимает пару минут.
А с misused-классами приходится именно мучаться.
0
А как же 3G момеды, которые вроде именно CDC и представляются и имеют скорость порта 7200000?
0
Со стандартным драйвером чтоле?)
0
А вот хз. Я этот момед на чужом компе видел.
0
ну про ини«шку я в курсе, про то, что это „коммуникейшн девайс“ я тоже в курсе.
но ком»овские модемы во времена вин9х так и жили: имелся отлаженый драйвер от мс и ини«шка с описанием всех конфигураций от производителя, но которая прекрасно автоматически скачивалась с мс апдейт.
про скорости и особенности на *никсе — не знал, спасибо про разъяснение.
0
Вот именно данного курса статей давно не хватало. Начало уже очень интригующее, так держать! Надеюсь, доведёте начатое до логического конца. :)
0
Увы, но опять будет много теории, запаситесь терпением
… имхо, те кто изучают USB, будут читать все статьи с удовольствием
0
про USB это интересно. Автор, если возможно, побольше графических материалов и примеров
0
Спасибо. Я от этой темы далёк пока, но почитать все равно интересно.
0
Спасибо Автору. С большим интересом буду читать, как раз ко времени для меня будут статьи, хочу научиться прикручивать USB к своим поделкам.
0
можно затрагивать спец. особенности линейки AT91SAM7S поглубже. из-за её непопулярности материала толкового практически нет. заодно популяризировать данное семейство.
0
В чем разница между USB и V-USB? То ли не аккуратно применяют эти аббревиатуры, то ли у меня в голове каша, которую надо расхлебывать.
0
  • avatar
  • DVF
  • 05 ноября 2011, 15:23
USB (англ. Universal Serial Bus — «универсальная последовательная шина», произносится «ю-эс-би») — последовательный интерфейс передачи данных для среднескоростных и низкоскоростных периферийных устройств в вычислительной технике.

V-USB — название программной библиотеки, позволяющей получить поддержку протокола USB на микроконтроллерах AVR (семейств Classic, Tiny и Mega компании Atmel), которые не имеют аппаратной поддержки USB.
0
На практике, за сокращением CDC-ACM стоит «обыкновенный» виртуальный СОМ-порт.
Так на практике в диспетчере устройств появиться COM-порт или USB?
0
COM-порт
0
Это свойство класса CDC-ACM?
0
Это свойство класса CDC-ACM?
Да.
В Windows устройство будет «выглядеть» как обыкновенный COM-порт. Иметь имя (например СОМ5), и соответствующие настройки (Baudrate и т. д.). Все приложения, которые рассчитаны на работу с СОМ-портом смогут работать и с нашим устройством. Управлять устройством со стороны ОС будет драйвер usbser.sys.
Возможно, я сбил Вас с току назвав COM-порт виртуальным. Просто в Windows под COM портом изначально подразумевался интерфейс RS-232. В данном случае, CDC устройство хоть и выглядит на вернем уровне как COM-порт — на физическом уровне к RS-232 прямого отношения не имеет. Иногда такие порты называют виртуальными.
0
Кто-либо пользовался снифферами на usb? я тут еllisуs ковыряю.
0
Я в процессе изучения USB использую USBlyzer. Триальный период закончился, но для старых версий существуют кряки, так что буду продолжать пользование. Как по мне штука хорошая, сама разбирает принятые пакеты и указывает на явные ошибки. Когда учишься отвечать на запросы хоста и формировать дескрипторы — самое то. Рекомендую.
Вопрос к людям: есть МК SiLabC8051F340 у него есть USB транссивер. Нужна ли статья о том как с ним работать?
0
Нужна ли статья о том как с ним работать?
Ответ стандартный — «да».
0
Напишите.
Народ заходит разный, Может кому понадобится…
0
Имхо каждого здесь интересует своя группа процев и ес-но тексты для быстрой разработки именно для этих камней. А эти тексты лучше взять из CMSIS производителя, и жевать именно их, во избежание…

Лучше бы статью как дергать USB аппаратно, на уровне физических линий, обзор тех же снифферов очень был бы кстати. Со стороны хоста, как конечная точка, етс. На ближайшие 10 лет — USB1/2/3 будет стандартом де-факто.

зы: а как у Cилабса, и вообще у C51х — возможности с пошаговой отладкой ?
0
Пошаговая отладка присутствует, можно воткнуть до 5 точек останова. Но при использовании USB гораздо удобней сделать программную пересылку интересующих данных в терминал через СОМ порт. Я так все запросы USB к контроллеру наблюдаю.
0
Автору — спасибо за статьи, с нетерпением жду продолжения
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.