USB
Universal Serial Bus Specification
Универсальная последовательная шина

Автор: Яшкардин Владимир
www.softelectro.ru
2011
electron18@softelectro.ru

§1. Вступление: 1.1 Кратко о USB.; 1.2 Эволюция универсального последовательного порта ПК.
§2. Сведения по спецификациям USB: 2.1 Краткая историческая справка; 2.2 Разработчики и редакции спецификаций USB; 2.3 Расширение спецификаций USB; 2.4 Содержание спецификации USB
§3. Описание спецификации USB 1.1: 3.1 Общие технические характеристики USB 1.1; 3.2 Физический уровень интерфейса USB 1.1; 3.3 Топология сети USB 1.1; 3.4 Аппаратная реализация интерфейса USB 1.1. Микросхемы.; 3.5 Протокольный уровень USB1.1.; 3.6 Устройства; 3.7 Спецификация хаба

§1.Вступление

1.1 Кратко о USB

USB (Universal Serial Bus) - универсальная последовательная шина.
Универсальный порт для подключения различных устройств к ПК и организации обмена между ними.
Описание USB состоит из ряда спецификаций, которые разрабатываются группой компаний в рамках некоммерческой организации USB Implementers Forum .
Основной целью данной разработки было создания универсального порта ПК для подключения потоковых устройств.
Спецификация USB 2.0-3.0 является на сегодняшний день основным коммуникационным портом персональных компьютеров.
USB представляет открытый протокол связи (нет лицензионного сбора), что способствовало его распространению и популярности во всём мире.

1.2 Эволюция универсального последовательного порта ПК.

21 век - век программных уровней(протоколов) в последовательных интерфейсах.
Если посмотреть на стандарты последовательных интерфейсов прошлого века, то они в основном описывали физические уровни, программные уровни оставались на волю разработчика.
Сегодня ситуация изменилась, и описание программных уровней занимают почти весь стандарт.
Когда начинают сравнивать последовательные интерфейсы разных лет, то иногда делают ошибку:
сравнивая физический уровень одного интерфейса с программным уровнем другого интерфейса.
Аналогично можно сравнивать операционную систему с материнской платой компьютера, и при этом говорить, что из них лучше.

Рассмотрим, как эволюционировал последовательный порт ПК:

1962г. - разработан телекоммуникационный рекомендованный стандарт RS-232. Это довольно сложный и чрезвычайно универсальный стандарт обмена последовательными данными, который может работать практически в любом оборудовании и приложениях. Один только кабель в 26 проводов, говорит о его сложности и его возможностях. Краткая характеристика RS-232: Кабель: 26 проводов Каналы данных: 4 (полный двух кратный дуплекс) Количество сервисных сигналов: 16(независимых) Состояний линии связи: более 130000 Тип обмена: синхроный/асинхронный одноточечный Скорость обмена: до 0,02 Mb/s Длина пакета: 7...11 бит Дальность связи: 25 ft(7.6m)
1983г. - специалистами IBM и Intel был разработан универсальный порт для ПК. Была использована следующая конфигурация RS-232С: Кабель: 10 проводов Каналы данных: 2 (полный дуплекс) Количество сервисных сигналов: 6(независимых) Состояний линии связи: 128 Тип обмена: асинхронный одноточечный Скорость обмена: до 0,115 Mb/s Длина пакета: 7...11 бит Дальность связи: 25 ft(7.6m)
1983г. - разработан рекомендованный стандарт RS-485 Он позволил работать через СОМ порт на большие расстояния в многоточечной среде. Характеристики RS-485 Кабель: 4 провода Каналы данных: 1 (полудуплекс) Количество сервисных сигналов: 0 Состояний линии связи: 2 Тип обмена: асинхронный многоточечный Скорость обмена: до 10 Mb/s Длина пакета: нет Дальность связи: 1200 m
1991г. - увеличена кварцевая частота СОМ порта с 1,8432МГц до 24МГц Скорость обмена COM порта увеличилась до 1.5Mb/s, с учетом дуплекса до 3 Mb/s Структура СОМ порта имеет большой потенциал для увелечения скорости обмена. При небольших доработках выходных каскадов скорость может быть увеличена до нескольких Gb/s. Интерфейс COM порта имеет очень короткий пакет с уверенной старт/стопной синхронизацией. Кроме этого COM порт работает в режиме независимого дуплекса и не требует время на переключения направления передачи. Как вы видите, когда понадобилась большая скорость, просто взяли и поставили другой кварц, абсолютно не меняя при этом структуру и аппаратуру СОМ порта.
1996г. - разработана спецификация нового универсального порта ПК USB 1.0. Характиристики USB: Кабель: 5 проводов Каналы данных: 1 (полудуплекс) Количество сервисных сигналов: 9(зависимые) Состояний линии связи: 4 Тип обмена: асинхронный одноточечный Скорость обмена: до 12 Mb/s Длина пакета: 4...1030 байт Дальность связи: 5 m

USB создавался на основе 13 летнего опыта использования COM порта ПК и очень удачной связки физических уровней RS232-RS485.

§2. Сведения по спецификациям USB

2.1 Историческая справка.

В 1994 году несколько ведущих компаний в области производства персональных компьютеров и программного обеспечения решили разработать новый универсальный порт компьютера.
Новая операционная система Windows 95, разработанная Microsoft, была ориентирована на использования аудио и видео устройств.
Работа таких устройств с СОМ и LPT портом вызывала известные трудности.
Обычно для таких устройств изготовляли персональную ISA или PCI карту для подключения их к компьютеру.

Семь ведущих компаний вошли в первоначальный состав разработчиков спецификации нового компьютерного порта:
Compaq, Digital Equipment Corporation (DEC), IBM, Intel, Microsoft, NEC , Northern Telecom.

В январе 1996 года была выпущена спецификация USB v.1.0, и началась практическая реализация порта USB.

В 1996 году работа велась в трёх направлениях:
1.Фирма Intel взялась за разработку хоста (корневого хаба), который она решила встроить в микросхему i82371FB (акселератор шин PCI, ISA, IDE).
Данная микросхема входила в состав набора микросхем i430FX "Triton" (CipSet) для создания материнских плат на базе микропроцессора Pentium и поддерживала шину PCI/ISA.
Позже микросхемы этого типа (шинные акселераторы), входящие в состав набора ChipSet стали называть микросхемами ICH (Input/Output Chip Hub) или "южным мостом".
В мае 1996 года Intel выпустила микросхему i82371SB, которая была аналогом i82371FB и содержала в своем составе два корневых хаба usb.
Данная микросхема могла поддерживать два порта USB v.1.0. Микросхема i82371SB впервые вошла в набор i430VX "Triton".
Таким образом, у производителей материнских плат появилась возможность с мая 1996 года выпускать платы с usb портами.

2. Microsoft начал дорабатывать свою ОС Windows 95 и в октябре 1996 года выпустил ОС Windows 95b, в которой впервые появилась поддержка USB портов.

3. Фирмы производители микроэлектроники начали разрабатывать микросхемы для создания устройств USB.
Например, фирма Philips начала в 1996 году разработку серии микросхем с наименованием PDIUSB,
которая должна была включать в себя все необходимые компоненты для устройств и хабов USB.

1996...1999 гг можно назвать "тёмными годами" USB.
В это время уже выпускались ПК с портами USB, к которым нечего было подключать.
Поэтому специалисты по компьютерным технологиям прозвали эту шину: (Useless serial bus -бесполезная последовательная шина).
Выпускавшиеся в эти года USB манипуляторы типа мышь, клавиатура, джойстик проигрывали по качеству работы манипуляторам, работавшим по порту PS/2 и Game Port.
Кроме того эти манипуляторы не работали в MS-DOS.
Многие специалисты считали, что у этого порта нет перспектив.

Ситуация изменилась в 1999 году в связи с разработкой первого USB флеш-накопителя.
Израильская фирма M-Systems Ltd. в 1999 году выпустила первую usb-флешку объёмом 8Мб, которая называлась DiskOnKey.
Колоссальная популярность USB-накопителей дала огромный толчок к дальнейшему развитию шины USB.
В первую очередь нужна была скорость обмена информации с Flash носителями.

В 2000 году разрабатывается спецификация USB 2.0 с поддержкой скорости 480 Mb/s (в 40 раз больше чем в USB 1.0).
Спецификация USB 2.0 стала стандартом последовательной шины компьютеров и различных устройств.
В 2006 году фирму M-Systems купил крупнейший производитель карт памяти ScanDisk (из силиконовой долины, США).

Главное достижение USB шины, которое наверно останется в истории, это то, что она дала человеку флешку.

Кратко :
1995- Организован форум "USB Implementers Forum (USB-IF)", в состав которого вошли 340 компаний, заинтересованные в создании нового порта ПК.
1996- Выпуск спецификации USB 1.0.
Корпорация Intel выпустила первую микросхему USB .
Mirosoft выпустила патч к W95, который подерживал USB порт.
Появились первые устройства, поддерживающие USB шину.
1997- Состав форума "USB-IF" достиг 400 компаний,было выпущено более 500 продуктов с поддержкой USB.
1998- Выпуск спецификации USB 1.1. Фирма Apple начала выпускать свои ПК только с USB портом.
1999- Выпуск первого USB Flash Drive объёмом 8Mb. Фирмой M-Systems Ltd.
2000- Выпуск спецификации USB 2.0. USB приобретает репутацию основной технологической шины.
2001- Выпуск спецификации USB OTG 1.0.
2005- Выпуск спецификации Wireless USB 1.0.
2006- Выпуск спецификации USB OTG 1.3
2008- Выпуск спецификации USB 3.0
2010- Выпуск спецификации Wireless USB 1.1

2.2 Разработчики и редакции спецификаций USB

Обозначение: USB.
Название: Universal Serial Bus Specification (Спецификация универсальной последовательной шины)

Выпуски спецификаций:

USB 1.1
USB v.1.1 (сентябрь 1998)
Издатели: Compaq Computer Corporation, Intel Corporation, Microsoft Corporation, NEC Corporation
USB v.1.0 (январь 1996г.)
USB v.0.9 (апрель 1995г.)
USB v.0.8 (декабрь 1994г.)
USB v.0.7 (ноябрь 1994г. )

USB 2.0
USB v.2.0 (апрель 2000г.)
Издатели: Compaq Computer Corporation, Hewlett-Packard Company, Intel Corporation, Lucent Technologies Inc, Microsoft Corporation, NEC Corporation, Royal Philips Electronics

USB 3.0
USB v.3.0 (ноябрь 2008г.)
Издатели: Hewlett-Packard Company, Intel Corporation, Microsoft Corporation, NEC Corporation, ST-NXP Wireless, Texas Instrument

2.3 Расширение спецификаций USB

On-The-Go Supplement to the USB 2.0 Specification
USB OTG v.1.3 (декабрь 2006)
USB OTG v.1.0 (декабрь 2001)
Данная технология позволяет соединять USB устройства между собой без использования компьютера.
Например, по этой технологии сканер изображения можно напрямую подключить к принтеру минуя компьютер.

Wireless Universal Serial Bus Specification
Wireless USB v.1.1 (сентябрь 2010)
Wireless USB v.1.0 (май 2005)
Технология беспроводного соединения USB устройств с компьютером по выделенному радиоканалу.

2.4 Содержание спецификации USB

Только сами описания, без дополнительных документов и извещений содержат:: USB 1.0 - 268 стр.; USB 1.1 - 311 стр.; USB 2.0 - 622 стр.; USB 3.0 - 482 стр.

Поэтому полностью описать спецификации в рамках одной статьи невозможно.
Вам обязательно придется пользоваться первоисточниками документов.
Все спецификации USB одинаково структурированы и содержат 11 глав.
Исключение составляет спецификация 3.0, в которой количество глав осталось прежним,
но исключена глава 3(Предпосылки создания), добавлена глава 7 (Уровень соединения) и изменены содержания 10 и 11 глав.
Вы можете изучать только главы, которые относятся к вашим потребностям.

Глава 1. Introduction (Введение).: Данная глава дает общее представление для чего и для кого создана эта спецификация, мотивация её создания, структура документов, ссылки на связанные документы.
Не содержит технической информации.
Глава 2. Terms and Abbreviations (Термины и сокращения): Данная глава описывает термины используемые в спецификации.
Данная информация необходима для однозначного понимая дальнейшего технического описания.
Не содержит технической информации.
Глава 3. Background (Предпосылки создания): Описано причины создания спецификации USB , цели проекта, область применения , краткое описание существующих технологий, список поддерживаемых функций.
Не содержит технической информации.
Глава 4. Architectural Overview (Описание архитектуры).
Общее краткое описание шины USB:
-Топология шины
-физический интерфейс
-питание
-протокол
-помехоустойчивость
-конфигурация системы
-потоковые типы данных
-характеристики устройств USB
-хост USB: программное и аппаратное обеспечение.
-расширение архитектуры.
Глава 5. USB Data Flow Model (Модель потока данных USB).
Глава описывает модели потоков данных:
-упрощенный взгляд на модель потока хост-устройство
-подробная логическая топология шины
-каналы, точки, коммуникационный поток
-типы передач
-управление передачами
-изохронные передачи
-передачи по прерыванию
-передачи с большим объёмом данных
-расщепленные передачи
-определение параметров доступа к ресурсам шины
-рассмотрение специфических вопросов по изохронным передачам
Глава 6. Mechanical (Разъёмы и кабели).: Глава описывает конструкцию соединителей и кабелей для USB устройств.
Глава 7. Electrical (Электрические характеристики)
Глава описывает:
-электрические сигналы
-структуру приёмо-передатчика
-описание питания устройств
-подробно физический уровень интерфейса
Глава 8. Protocol Layer (Уровень протокол)
Подробное описание протокола USB:
-порядок следования данных
-синхронизация данных
-форматы полей пакета
-форматы самих пакетов
-форматы транзакций
-квитирование транзакций
-обнаружение ошибок и восстановление данных
Глава 9. USB Device Framework (Состояния и работа устройств USB)
Подробное описания состояний устройств USB их конфигурирование и работа устройств с хостом.
-состояния устройства
-операции с устройствами
-запросы устройства хостом
-дескрипторы конфигураций устройства
-модель связи устройства с хостом
Глава 10.USB Host: Hardware and Software (USB хост: аппаратура и программное обеспечение)
Эта глава описывает интерфейсы хоста для связи резидентных программ ПК с функциями устройства USB.
-описания хоста
-модель связи устройства с клиентским ПО
-требования к функциональным способностям хоста
-краткий обзор механизмов программного обеспечения.
-описание драйвера хост контроллера
-описание драйвера универсальной шины (USBD)
-требования к операционной системе
Глава 11.Hub Specification (Спецификация хаба)
Эта глава описывает архитектурные требования для хаба(концентратора) USB, его двух основных частей: повторителя и контроллера.
Глава также описывает операции с хабом.
Вторая половина главы определяет поведение хаба при запросе и дескрипторы конфигураций хаба.

-состояния хаба
-операции хаба
-требования к буферу ввода/вывода хаба
-механизмы устранения неисправностей хаба
-подвешивание (останов) и возобновление(запуск) хаба
-поведение хаба при сбросе
-требования по распределению питания между портами хаба
-организация конечной точки хаба
-конфигурация хаба (дескрипторы)

Содержания измененных и добавленных глав для USB 3.0:
Глава 7. Link Layer (Уровень связи)
Эта глава описывает связь, команды, состояния между двумя партнерами связи.
-порядок выставления байтов в пакетах связи
-управление потоков и менеджер связи
-правила обработки ошибок и восстановление связи
-процедуры общего сброса питания и внутриполосного сброса
-подготовка связи и механизм статусных сотояний
Глава 10. Hub, Host Downstream Port, and Device Upstream Port Specification (хаб, внизпередающий порт хоста, и спецификация верхпередающего порта устройства)
Данная глава объединила главы 10 и 11 (USB 1.0-2.0) в одну главу.
Здесь описаны свойства и поведения хаба и хоста.
-суммарная характеристика хаба
-управление питания хабом
-описания внизпередающих портов хаба
-описание вверхпередающих портов хаба
-заголовок транспортного пакета хаба и повторитель данных
-подвешивание и возобновление
-характеристики сброса вверх передающих портов хаба
-контроль питания портов хаба
-контроллер хаба
-конфигурация хаба
-дескрипторы конфигураций хаба
-запросы
-внизпередающие порты корневого хоста
-периферийные устройства вверхпередающих портов
-заглавные параметры хаба
Глава 11. Interoperability and Power Delivery (Взаимодействие и доставка питания)
Данная глава определяет взаимодействие и технические требования для USB 3.0.
Область покрытия USB 3.0 и взаимодействие хоста с устройствами поддерживающими USB 2.0 спецификацию.
-поддержка USB 2.0 хостом USB 3.0
-поддержка USB 2.0 хабом USB 3.0
-поддержка USB 2.0 устройствами USB 3.0
-распределение питания

§3.Описание спецификации USB 1.1 [1] [2]

Спецификация USB 1.1 это исправленная спецификация USB 1.0.
Поэтому описывать USB 1.0 нет смысла, она имеет сейчас только историческую ценность.

3.1 Общие технические характеристики USB 1.1.

Технические характеристики USB 1.1:

-метод модуляции сигнала: балансный (диференциальный)

-тип связи: полудуплекс асинхронный

-кодирование данных: NRZI (Non Return to Zero Invert)

-тип соединения: точка к точке

-тип сети: древовидная ниспадающая 4-х уровневая на базе хабов (концентраторов)

-количество точек max: 127

-состояний линии связи: 4

-сервисных сигналов линии связи: 9(зависимые)

-скорость, бит/сек: low-speed =1.5Mb/s ; full-speed =12 Mb/s

-дальность связи: low-speed = 3м; full-speed= 5м

-кабель: 5-ти проводной

-разъёмы: серия А (штырь/гнездо), серия B (штырь/гнездо)

-протокол: адресный пакетный с контрольной суммой и синхробитами

-питание: по отдельной линии напряжением:+5v, сила тока 500mA

3.2 Физический уровень интерфейса USB 1.1

Физический уровень USB разрабатывался от уровня RS232-RS485.
В 90-х годах большинство последовательных интерфейсов использовало физический уровень RS232-RS485.
Такие интерфейсы создавались добавлением программного (протокольного) уровня к физическому уровню RS232-RS485.
Интерфейсов построенных по такому принципу десятки, а может сотни.
Некоторые из них: ModBus, ProFibus, DCON, DH-485, BitBus, HART и многие др.
Все эти протоколы сегодня успешно работают во многих отраслях человеческой деятельности.
Естествено при разработке физического уровня USB использовались эти наработки.

На рис.1 показана структура физического уровня RS232-RS485

Описание структуры физического уровня RS232-RS485:

Структура состоит из двух драйверов(приёмопередачиков) и двух физических сред (кабель RS232 и кабель RS485).
Связь с программным уровнем осуществляется через системную шину ПК, к которой подключен контроллер RS232 (UART).
Кабель RS485 обеспечивает общую физическую многоточечную среду, к которой подключаются драйверы RS485 других устройств.
Драйверы RS232 и RS485 выполнены симметрично, то есть структура драйвера одинакова для DTE и DCE устройств RS232,
также одинакова структура драйверов для ведущего и ведомого драйвера RS485.
Стык RS232 работает в дуплексном режиме (драйверы имеют равные права).
Стыке RS485 в один момент времени может существовать только один ведущий драйвер (передающий), остальные драйвера ведомые (принимающие).
Ведущим становиться любой драйвер RS485, который получил право передавать информацию.
Алгоритм передачи маркера, который делает точку ведущей, определяет программный уровень интерфейса (протокол).
Драйвер RS485 имеет гальваническую развязку с сигналами RS232, что позволяет осуществлять "горячее" подключение и отключение точек сети.

На рис.2 показана структура физического уровня USB 1.1

Как видно из рис.2 физический уровень USB напоминает RS485, используется аналогичный полудуплексный балансый сигнал.
Для упрощения линии связи было решено отказаться от использования независимых сервисных сигналов, которые управляют обменом данных.
Сервисные сигналы RS232 были заменены сигналами и состояниями, которые передаются по балансной линии связи.
Тем самым стало возможным переместить физический уровень RS232 в программную область интерфейса.
Это придало интерфейсу дополнительную конфигурационную гибкость и упростило его физическую реализацию.
Но, при этом интерфейс лишился гальванической развязки, согласованности линии связи, симетричности и многоточечности.
Кроме того включение программного уровня в структуру интерфейса сделало его замкнутым, то есть не способным к модификационному размножению.
Несогласованность, асимметричность и увеличенная скорость передачи сократили растояние связи с 1200 метров (RS485) до 5 метров(USB).
В интерфейс USB была добавлена линия питания +5В, что очень увеличило его функциональность.

Рассмотрим структуру физического уровня USB 1.1:

3.2.1.Общая структура физического уровня.
Физический уровень USB 1.1. состоит из двух драйверов и физической среды (кабеля) между ними.
Драйверы физического уровня не симметричны, то есть имеют разную структуру.
Физическая среда одноточечная и односторонняя (полудуплекс).
Существует два типа драйвера:
Downstream (внизпередающий)- этот драйвер всегда ведущий, то есть только он определяет кто, когда и сколько будет передавать данных в линию связи.
Драйверы этого типа всегда генерируют информационный сигнал в направлении от хоста.
В сети эти драйверы установлены на хосте или внизпередающем порту хаба.

Upstream (вверхпередающий) - это драйвер всегда ведомый.
Он всегда генерирует информационный сигнал в направлении хоста.
Время и порядок его работы определяет ведущий драйвер (Downstream).
Эти драйвера устанавливаются в устройствах и верхпередающих портах хаба.

Драйвер Upstream может быть одного из двух видов:
Upstreeam Full Speed - для работы на скорости 12 Mb/s
Upstream Low Speed - для работы на скорости 1,5 Mb/s

Так как драйверы не симметричны, связь в физическом уровне USB 1.1 возможна только между драйверами разного типа, то есть только между Downstream и Upstreeam.
Соответственно не симметричен и кабель для подключения, со стороны Downstream он имеет разъём серии A, а со стороны Upstream разъём серии B.
Драйвера и кабели RS232 и RS485 симметричны, поэтому ПК можно соединять между собой через COM порты.
Соединить два ПК через USB порты не возможно.
Этот факт конечно, ухудшает универсальность порта, но позволяет упростить аппаратную часть, так как односторонние драйвера аппаратно более просты.
Кроме того односторонняя реализации упрощает программный уровень, так как параллельные процессы в ПК трудно реализуемы.

3.2.2.Устройство драйверов.
Как видно из рис.2 драйвера USB состоят из: контроллера, кодера, декодера, генератора, дифференциального и линейных приёмников, подтягивающих резисторов и источника питания.

3.2.2.1 Контроллер драйвера.
Контроллер соединяет генерирующую и приёмную часть драйвера через системную шину с программным уровнем хоста, концентратора или устройства.
Так как весь передаваемый пакет может быть сформирован программным уровнем , то аппаратная реализации контроллера не сложна.

3.2.2.2 Кодер NRZI.
Пакет кодируется методом NRZI с помощью JK-триггера.
Алгоритм NRZI кодирования довольно прост, при передачи нуля генератор должен изменить полярность сигнальной линии на противоположную,
при передачи единицы оставить полярность сигнала прежней (т.е. ничего не менять).
Кодеры для Full Speed и Low Speed отличаются выходным сигналом (противоположны).
NRZI кодирование позволяет сократить число синхробитов вставляемых в пакет данных.

3.2.2.3 Декодер.
Преобразует NRZI закодированные данные к начальному виду и выделяет синхросигнал из принимаемых данных.

3.2.2.4 Генератор.
Генератор устроен аналогично генератору RS485.
Генератор передает в линию связи дифференциальные нули и единицы.
Когда генератор не передает данные, он отключен от линии связи сигналом OE и не влияет на её работу.
Генератор может замыкать линию связи на общий провод сигналом SEO. Это используется для сброса шины.
Рис.3 Напряжения измеряемые на выходах генератора:

Vdi - дифференциальное напряжение, это напряжение между выводами D+ и D-
Vd+ - линейное напряжение, это напряжение между Выводом D+ и GND
Vd- - линейное напряжение, это напряжение между Выводом D- и GND

Параметры генератора:
ЭДС генератора: +3,6v
Внутреннее сопротивление: 56..88 Om Макс. допустимое прямое линейное напряжение: +4,6v
Макс. допустимое обратное линейное напряжение: -1,0v
Генератор должен статически держать параметры линейного напряжения на выходе:
V_OL= не более +0.3v при нагрузке 1,5kOm подключенной к +3,6v для низ. линейного сигнала (0);
V_OH= не менее +2.8v при нагрузке 15 kOm подключенной к GND для выс. линейного сигнала (1).

Нарастание фронта линейного сигнала, должно быть в пределах: 4ns..20ns (FS), 75ns..300ns (LS)
Длительность линейного сигнала высокого уровня при передачи бита должна быть не менее: 60ns
Пересечение линейных сигналов D+ и D-(Vd+=Vd-) должно быть в диапазоне:V_CRS= 1,3v...2,0v
Нагрузочная ёмкость выхода: C_L= 50pF (FS), 50pF..150pF(LS Upstream), 200pF..600pF (LS Downstream)

3.2.2.5 Дифференциальный приёмник.
Предназначен для приёма данных с линии связи D+D-.
Измеряет напряжение между линиями D+ D- (Vdi).
Определяет два состояния: дифференциальный "0" и дифференциальную "1".
Параметры диф. приемника:
Чуствительность приёмника должна быть не ниже V_DI= 200mV
Диф. "1": Vdi>+200mV (Vd+ > Vd- более чем на 200mv в диапазоне лин. напряжения V_CM= 0,8v..2,5v)
Диф. "0": Vdi<-200mV (Vd- > Vd+ более чем на 200mv в диапазоне лин. напряжения V_CM= 0,8v..2,5v)

3.2.2.6 Линейные приемники.
Измеряют линейные напряжения Vd+ и Vd- относительно GND.
Комбинация линейных напряжений и времени их удержания определяют состояние линии связи.
В результате применения линейных приемников, USB порт может определять несколько состояний линии связи,
без применения сервисных сигналов (например, как в RS232, 6 сервисных сигналов, задают 128 состояний линии связи)
Параметры:
напряжение Vd+ или Vd- низкого уровня (0), V_IL= не более +0.8v
напряжение Vd+ или Vd- высокого уровня (1), V_IH = не менее +2.0v

Напряжения Vd+ или Vd- могут опускаться ниже V_IL, без фиксирования состояния SE0, на время не более: T_FST= 14ns(для FS) и T_LST= 210ns(для LS)

3.2.2.7 Подтягивающие резисторы.
Служат для идентификации устройств USB при их подключении/отключении к порту Downstream.
Для Downstream Vd+ и Vd- подтягиваются к низкому уровню (GND) резисторами 15kOm.
Для Upstream Full Speed Vd+ подтягивают к высокому уровню (V_TERM=3.0V..3.6V) резистором 1.5kOm.
Для Upstream Low Speed Vd- подтягивают к высокому уровню (V_TERM=3.0V..3.6V) резистором 1.5kOm.

3.2.2.8 Источник питания.

Как видно из структуры физического уровня USB 1.1 драйвера Downstream имеют источники питания напряжением V_BUS=+5V для питания нисходящих устройств сети по шине USB. В спецификации введено понятие "модульная нагрузка", одна модульная нагрузка равна 100mA. Классификация устройств по питанию: Root port hubs (корневые порты хабов) Эти порты запитаны от источника питания хоста.
Например, если хост установлен в ПК, то источником питания является блок питания ПК.
Все порты этого хаба должны обеспечивать не менее 5-ти модульных нагрузок (500mA), такие порты называют High-Power port(сильный питающий порт).
Обратите внимание, что только High-Power port может обеспечить ток более 500mA, по сути дела вы напрямую подключаетесь к блоку питания ПК и ограничения по току связаны только с мощнотью блока питания компьютера.
Если питание хоста выполнено на батареях, то такие порты должны обеспечивать не менее одной модульной нагрузки(100mA) и такие порты называют Low-Power port (слабый питающий порт)

Bus-powered hubs (шинозапитанный хаб) Этот хаб имеет питание по шине USB и всю мощность он берет от вышестоящего downstream порта.
Такой хаб потребляет одну модульную нагрузку при включении и до 5-ти модульных нагрузок после конфигурации хаба.
В результате шинопитающийся хаб должен после конфигурации распределить имеющиеся в его распоряжении 500mA между всеми портами и функциями, входящими в его состав.

Self-powered hubs (Хаб с собственным питанием) Этот хаб имеет собственный внутренний источник питания и не использует питание передаваемое по шине USB.
Однако он может использовать до одной модульной нагрузки с шины USB, когда его собственное питание не включено.
После конфигурации этот хаб запитывается от своего источника питания и обеспечивает всем портам, входящим в его состав, до 5-ти модульных нагрузок.
Если внутренний источник хаба- батарея, то до одной модульной нагрузки на каждый порт входящий в состав хаба.

Low-power bus-powered functions (слабая шиннозапитанная функция)
Это устройство USB, которое берет от Downstream порта не более одной модульной нагрузки в любое время.

High-power bus-powered functions (сильная шиннозапитанная функция)
Это устройство USB, которое берет от Downstream порта не более одной модульной нагрузки во время подключения и до 5-ти модульных нагрузок после конфигурирования.

Self-powered functions (функция с собственным питанием)
Это устройство USB, которое имеет собственный источник питания, это устройство может брать с шины USB до одной модульной нагрузки при включении устройства.

Параметры питания:
High-Power Port(сильно питающий порт), V_BUS=4,75V..5,25V
Low-Power Port (слабый питающий порт), V_BUS=4,40V..5,25V
High-power Hub Port (out)(выход High порта хаба) , I_CCPRT= не менее 500mA
Low-power Hub Port (out) )(выход Low порта хаба), I_CCUPT= не менее 100mA
High-power Function (in) (потребление High устройства) ,I_CCHPF= не более 500mA
Low-power Function (in) (потребление Low устройства), I_CCLPF= не более 100mA
Unconfigured Function/Hub (in) (не сконфигурированное устр-во), I_CCINIT= не более 100mA
Suspended High-power Device (High устр-во в остановленном состоянии), I_CCSH= не более 2,5mA
Suspended Low-power Device (Low устр-во в остановленном состоянии), I_CCSL= не более 0,5mA

3.2.3 Кодирование и синхронизация.
Кодирование:
Бинарные данные передаваемые через интерфейс USB кодируются методом NRZI.
Метод NRZI(Non Return to Zero Invert)заключается в изменении полярности сигнала при кодировании "0".
При передаче "1" полярность сигнала остаётся прежней.
NRZI кодированные сигналы Low Speed устройств противоположны сигналам Full Speed устройств USB.
Рис.4 NRZI кодирование.
NRZI

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

Синхронизация:
Синхронизация данных осуществляется от каждого переходного фронта сигнала.
Так как каждый "0" бит данных изменяет полярность сигнала при NRZI кодировании на противоположный,
то каждый "0" бит создает переходной фронт сигнала, относительно которого синхронизируется приёмник данных.

Три метода синхронизации пакета данных в USB:
1.SOP(Start-of-Packet) Переход из сотяния Idle в состание K.
В начала каждого пакета вставляется байт 80h, который имеет 7 нулей и одну единицу.
Семь фронтов идущих подряд позволяют надежно синхронизовать приёмник с началом пакета данных.

2."0" бит данных.
Каждый "0" бит данных дополнительно синхронизует приёмник.
В результате NRZI кодирования, все данные содержащие "0" бит не нуждаются в дополнительном синхробитах.

3. Stuffed Bit -вставляемый синхробит.
Если в пакете данных появляются подряд шесть "1", то чтобы не потерять синхронизацию приёмника вставляют "0", который считается синхробитом.
То есть, "0" после шести "1" не является битом данных и программным уровнем игнорируется.
Счет единиц начинается с поля SYNC, т.е. с единицы имеющейся в этом поле.
Также учтите что синхробиты не привязанны к байтам, они считаются во всей битовой последовательности пакета.
Вставка бита осуществляется всегда, без исключения.
Если по правилам требуется вставка бита, нулевой бит будет вставлен, даже если это - последний бит, т.е. бит перед сигналом конец-пакета (EOP).

Рис.5 Синхронизация пакета данных USB
USB Sync

Из рис.5 видно, что начальное положение Idle для FS и LS имеют разный знак, поэтому первый бит синхробайта должен изменить начальное положение на противоположное, иначе мы бы потеряли значение первого бита.
Отсюда становится понятно, почему кодировка NRZI для FS и LS различаются.

Как видно из рис.5 синхронизация USB не хуже синхронизации RS232 (где синхронизируется каждый байт).
Причем затрат времени на синхронизацию в USB почти в четыре раза меньше, и соответственно мы можем передать больше информации за единицу времени.
Недостатки синхронизации с NRZI:
1.В пакете появляются байты длиною в 9 бит.
2.Каждый Stuff бит задерживает остаток пакета на время равное интервалу бита.
Поэтому разные пакеты передаются с разным временем задержки.
3.Пакеты становятся плавающей длины.

В RS232 таких проблем нет. Отсюда вывод, что за всё приходиться расплачиваться.

3.2.4 Состояния линии связи.
Как видно из структуры физического уровня USB 1.1 (рис.2), в ней отсутствует сервисные сигналы.
Это сильно ограничивает функциональность интерфейса, так как становиться трудно организовать процедуры: установки, обмена, повтора при ошибки, останова и разрыва связи.
Это являлось основным недостатком интерфейса RS-485, в котором можно обнаружить только два состояния: ведется передача или нет.
В результате применения связки RS232-RS485 терялись все преимущества COM порта по организации процесса связи.

Рассмотрим как, разработчики USB порта решили эту проблему:
1.В структуру добавлены два линейных приёмника.
Они могут определить четыре состояния линии связи D+D-:00, 01, 10, 11.
Эти состояния определяются, когда по линии связи нет обмена данными.
Причем четырех состояний для организации полноценного обмена будет недостаточно.

2.Добавлен анализ временных интервалов состояний линии связи
Использование анализа временых интервалов состояний линии связи, позволяет генерировать 9 сервисных сигналов.
Сервисные сигналы позволяют организовать управление обменом данных в линии связи.

Состояния линии связи USB 1.1 и генерируемые ими сигналы
D+D- = 00
SE0(Single-ended 0) - состояние линии "однополярный ноль".
Состояние определяется:
На разъеме источника: Vd+ и Vd- < V_OL
На разъёме приёмника:Vd+ и Vd- < V_IL (рекомендовано), Vd+ и Vd- < V_IH (допустимо)

Это состояние когда обе линии закорочены генератором драйвера по сигналу SE0 (см. рис.2) или когда к шине не подключен Upstream драйвер.
Это состояние использется для генерации сигналов: EOP, Disconnect, Reset

EOP(End-of-Packet)- сигнал конец пакета
Сигнал определяется:
На разъеме источника: SE0 в течении 2 бит с последующим J-сигналом в течений 1 бит
На разъёме приёмника:SE0 более 1 бит с последующим J-сигналом в течении 1 бит

Этот сигнал подаётся в линию связи в конце каждого пакета данных.
Он служит для разделения пакетов данных во времени (как стоп-бит в RS232).
После состояния SE0, которое длится на протяжении двух битовых интервалов 160нс..175нс(Full Speed) или 1,25мкс..1,50мкс(Low Speed) передаётся сигнал J в течении 1 бита.
После чего может быть передан новый пакет или шина перейти в состояния Idle.

Disconnect-сигнал отсоединение Upstream от Downstream порта, определяется на Downstream
Сигнал определяется:
На разъеме источника: не измеряют.
На разъёме приёмника: SE0 более 2,5мкс.

Этот сигнал фиксируется на Downstream порту, когда Upstream драйвер подал сигнал SE0 или был физически отсоединён от шины USB.
При физическом отсоединении низкий уровень линейных сигналов обеспечивают подтягивающие резисторы драйвера Downstream R_PD=15kOm.

Reset -сигнал сброс шины
Сигнал определяется:
На разъеме источника: SE0 более 10мс.
На разъёме приёмника: SE0 более 10мс (рекомендовано),более 2,5мкс (допустимо)

Это сигнал генерируется после сигнала Disconnect, оно инициализирует перезапуск опроса устройств USB.

D+D- = 01/10
Idle - свободное (незанятое) состояние линии связи .
Состояние определяется:
На разъеме источника: не измеряют
На разъёме приёмника (Low Speed):Vd+ < V_IL и Vd- > V_IH
На разъёме приёмника (Full Speed):Vd+ > V_IH и Vd- < V_IL

Это состояние когда к порту Downstream подключено устройство и обмена данными не производится.
С помощью этого состояния генерируются сигналы: Connect, Suspend

Connect - сигнал соединения устройства с Downstream портом
Сигнал определяется на Dowmstream порту:
На разъеме источника: не измеряют
На разъёме приёмника: Idle более 2мс (рекомендовано),более 2,5мкс (допустимо)

Этот сигнал сообщает Downstream порту, что к нему подлючилось устройство.

Suspend - сигнал приостановки обмена данных по шине
Сигнал определяется на Upstream порту:
На разъеме источника: не измеряют
На разъёме приёмника: Idle более 3мс

Этот сигнал сообщает устройству, что обмен данных с ним приостановлен.
Возобновление работы осуществляется выставлением сигнала Resume.

Дифференциальный "1" - состояние высокого уровня сигнала на линии связи.
Состояние определяется:
На разъеме источника: Vd+ > VOH и Vd- < VOL
На разъёме приёмника: Vdi >+0.2v и Vd+>VIH(рекомендовано), Vdi >+0.2v (допустимо)

Дифференциальный "0" -состояние низкого уровня сигнала на линии связи.
Состояние определяется:
На разъеме источника: Vd- > VOH и Vd+ < VOL
На разъёме приёмника: Vdi <-0.2v и Vd->VIH(рекомендовано), Vdi <-0.2v (допустимо)
С помощью этих состояний генерируются сигналы: J, K, Resume, SOP

J - сигнал J(Jump), возврат линии связи к уровню исходного состояния (Idle)
Синал определяется:
Low Speed: состояние дифференциальный "0"
Full Speed: состояние дифференциальный "1"

K - сигнал K(Kill), сброс исходного(Idle) уровня состояния линии связи.
Сигнал определяется:
Low Speed: состояние дифференциальный "1"
Full Speed: состояние дифференциальный "0"

Resume - сигнал возобновление работы после останова.
Состояние определяется:
На разъеме источника и приёмника: K сигнал не менее 20мс с последующим сигналом EOP
Устройство может находиться в режиме приостановленного обмена данными (Suspend),
выход из этого режима осуществляется подачей сигнала Resume, после которого обмен данными возобновляется.

SOP - сигнал (Start of Packet) начала пакета.
Состояние определяется:
На разъеме источника и приёмника: переход из состояния Idle к сигналу K

D+D- = 11
Данная комбинация линейных сигналов технически не реализована в структуре USB 1.1

На рис.6 показаны сигналы и состояния линии связи USB 1.1

3.2.5 Кабели и соединители интерфейса USB 1.1.

В качестве разъёмов интерфейса USB 1.1 используют:
Для Downstream: разъёмы серии A
Для Upstream: разъёмы серии B

На кабель устанавливают разъёмы типа штыри (Plugs)
На приборы устанавливают разъёмы типа гнезда (Receptacles)
Рис.7 Кабель и разъёмы интерфейса USB 1.1
cabel usb 1.1

Кабель с разными разъёмами не позволяет соединять драйвера Upstream с Upstream и Downstream с Downstream.
Это обусловлено несимметричностью интерфейса USB 1.1

Максимальная длина кабеля для режима LS(LowSpeed) равна 3 м.
Максимальная длина кабеля для режима FS(FullSpeed) равна 5 м.

Сигналы D- и D+ в кабеле (FS) передаются по витой паре с волновым сопротивлением 90 Ом.
В кабеле (LS) витая пара не применяется.

Использование витой пары в USB кабеле не имеет большого смысла, скорее всего это дань витой паре.
Шедевром применения витой пары является интерфейс RS485, который позволил передавать немодулированный сигнал на 1200 метров по двум проводам.
Иногда мне кажется, что интерфейс RS485 был специально создан для демонстрации возможностей проводной линии типа витая пара.
В USB кабеле витая пара не согласована из-за невозможности использования 90-Омных терминаторов.
Кроме того длина кабеля всего 5м и взаимоиндукция проводов мала, если учесть и малую мощность сигнала, то эффект подавления синфазных помех практически отсутствует.

3.3 Топология сети USB 1.1.

Топология сети USB v.1.1 на физическом уровне представляет топологию многоярусной звезды.
Максимальное количество ярусов, предусмотренное спецификацией USB v.1.1 , равно четырем.
Отсюда, максимальный радиус сети равен 20 метрам.
Максимальное количество устройств сети (хабов и функций) равно 127.

Рис.8 Топология сети USB v.1.1 на физическом уровне
topology net usb 1.1

Сеть состоит:
-Контроллера хоста(Host) с корневым хабом(RootHub). Контроллер в сети всегда ведущий.
-Устройств сети(Device), всегда ведомые

Устройства сети бывают двух глобальных классов:
-Концентраторы(Hub)-для разветвления сети
-Функциями(Function)-источники информации

Каждое устройство имеет адрес из 7 бит, который оно получает от хоста при подключении к сети (1..127).
Адрес устройства расширяется адресом конечной точки (4 бита), который задаётся разработчиком(0..15).
Конечная точка с адресом 0 обязательна для всех устройств сети и содержит информацию необходимую для инициализации и подключения устройства к сети.
В процессе инициализации устройства все используемые конечные точки настраиваются на различные параметры канала связи с хостом.
То есть при обращении по заданному адресу к конечной точке устройства хост должен выставить тип передачи данных, который определяет:
-формат данных
-направление потока связи
-размер пакета данных
-ограничения на доступ к шине
-требуемая последовательность данных

По сути дела конечные точки представляют набор заранее сконфигурированных каналов обмена данными(Pipe) между устройством и хостом.

Кроме 0 конечной точки, устройства могут поддерживать дополнительно:
-Концентратор: до l доп.точки
-Низкоскоростное устройство: до 2 доп. точек
-Высокоскоростное устройство: до 15 доп. точек

С точки зрения хоста, логическая топология сети выглядит как звезда. То есть хост может обратиться к любому устройству напрямую по адресу устройства.
Рис.9 Топология сети USB v.1.1 на логическом уровне
topology net usb 1.1

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

3.4 Аппаратная реализация интерфейса USB 1.1. Микросхемы.

Аппаратная реализация USB состоит из двух основных классов микросхем:
-микросхем для корневых хабов (хостов)
-микросхем для концентраторов (хабов) и устройств.

Микросхемы корневого хаба (хоста).
Корневые хабы USB встраиваются в микросхемы входящие в состав "южного моста" ChipSet.
Первоначально эти микросхемы назывались акселераторами шин PCI ISA IDE (PII), потом их начали называть концентраторами ввода/вывода ICH (I/O Chip Hub).

Перечень м/с Intel USB 1.0...USB 1.1:
Intel i82371SB(PIIX3) -акселератор шин PCI ISA IDE (05.1996 первая микросхема с USB)
Поддерживает два USB 1.0 порта.
Входит в состав ChipSet: i430VX, i430HX, i440FX

Intel i82371AB (PIIX4) -акселератор шин PCI ISA IDE (09.1996)
Поддерживает два USB 1.0 порта с поддержкой UHCI v.1.1
Входит в состав ChipSet: i430TX

Intel i82371EB(PIIX4E) i82371EB(PIIX4E), i82371MB(PIIX4M) -акселератор шин PCI ISA IDE (10.1997)
Поддерживает два USB 1.0 порта
Входит в состав ChipSet: i440LX, i440EX, i440BX, i440GX, i440ZX

Intel i82801AA(ICH), i82801AB(ICH0) - I/O Chip Hub(06.1999)
Поддерживает два USB 1.1 порта
Входит в состав ChipSet: i810, i815, i820, i840

Intel i82801BA(ICH2) - I/O Chip Hub(10.2000)
Поддерживает два хоста, четыре USB 1.1 порта
Входит в состав ChipSet: i815, i820, i845, i850, i860

Intel i82801CA(ICH3) - I/O Chip Hub(02.2002)
Поддерживает три хоста, шесть USB 1.1 порта
Входит в состав ChipSet:

Начиная с ICH4 используется спецификация USB 2.0
Intel i82801DB(ICH4) - I/O Chip Hub(05.2002)
Поддерживает два хоста, шесть USB 2.0 порта

Микросхемы устройств USB.
Микросхемы для устройств USB выпускаются многими производителями электроники.
Например фирма Phillis одна из первых выпустила серию микросхем PDIUSB в которую вошли все необходимые элементы для построения USB устройств.
PDIUSB11 USB устройство с последовательным интерфейсом
PDIUSBH11 USB хаб на 4 порта
PDIUSBP11 USB трансивер
PDIUSB12 USB хаб на 2 порта
PDIUSBD12 USB устройство с параллельным интерфейсом.

3.5 Протокольный уровень USB1.1.

Обмен данных происходит пакетами,которые образуют транзакции.
Транзакция обычно состоит из трех пакетов:маркерного, данных, квитирования.
Транзакция обеспечивает однократный обмен данными между хостом и конечной точкой устройства.
В свою очередь транзакции включены в кадр(Frame).
Начала кадра и номер кадра передаются специальным пакетом(SOF) каждую 1 ms.

3.5.1 Пакет (Packet).

Передача данных осуществляется пакетами.
Начало пакета определяется по сигналу SOP(Start of Packet), это переход из состояния Idle в состояние K.
Далее следует байт синхронизации SYNC (80hex), которой после NRZI кодирования имеет вид KJKJKJKK.
Последних два бита SYNC- KK являются маркерам начала блока данных.
Блок данных состоит из полей разной длины, суммарная длина блока данных должна быть кратна 8 битам.
Байты передаются в порядке очереди начиная с младшего бита и заканчивая старшим битом.

Рис.9 Пакет Low Speed USB1.1(1,5 Mb/s)

Рис.10 Пакет Full Speed USB1.1(12 Mb/s)

Заканчивается пакет сигналом EOP(End of Packet) длительностью 3 бита, который является временным разделителем пакетов.

Типы пакетов:
Token Packets(TP) - Маркерный пакет.
Этот пакет всегда посылается хостом и является заголовком транзакции, т.е. определяет кому и как будет передаваться информация в следующем пакете.
Рис.11 Структура маркерного пакета.

Таблица1. Описание полей:

PID	PID NAME	Описание
0xE1(1110 0001)	OUT	передача данных от хоста к конечной точке
0x69(0110 1001)	IN	передача данных от конечной точки к хосту
0x2D(0010 1101)	SETUP	передача от хоста к конечной точке по каналу управления

ADDR число 1..127 -адрес устройства с которым будет работать хост в текущей транзакции.
ENDP число 0..15 -адрес конечной точки с которой будет работать хост в текущей транзакции
CRC5 контрольная сумма полей ADDR,ENDP
-вычисляется без учёта дополнительных синхробитов Stuffed Bit (см. п.3.2.3)
-вычисляется побитовой сверткой данных с полиномом 0x25(100101)

Start-of-Frame Packets(SOF) пакет определяющий начала кадра.
Этот пакет посылается хостом каждую миллисекунду(1000Гц) и обозначает начало нового кадра.
Этот пакет могут принимать все устройства сети, он без адресный.
Это единственный пакет имеющий синхронизацию с часами реального времени.
В пакете присутствует счетчик кадров, который по сути является счетчиком миллисекунд.
Устройства могут синхронизировать свою работу с реальным временем считывая это пакет.
Рис.12 Структура пакета начала кадра.

Таблица 2. Описание полей:

PID	PID NAME	Описание
0xA5(1010 0101)	SOF	(Start-of-Frame) маркер начала кадра

Frame Number число 0..2047 -номер кадра(количество миллисекунд). Этот счетчик имеет полный цикл в 2.048 сек.
CRC5 контрольная сумма поля Frame Number
-вычисляется без учёта дополнительных синхробитов Stuffed Bit (см. п.3.2.3)
-вычисляется побитовой сверткой данных с полиномом 0x25(100101)

Data Packets(DP) пакет данных.
Это пакет с данными, которыми обмениваются хост и конечная точка устройства. В транзакции он следует за маркерным пакетом.
Рис.13 Структура пакета данных.

Таблица 3. Описание полей:

PID	PID NAME	Описание
0xС3(1100 0011)	DATA0	пакет данных с четным PID
0x4B(0100 1011)	DATA1	пакет данных с нечетным PID

DATA данные для обмена между хостом и конечной точкой в байтах.Число байтов данных называют полезной нагрузкой пакета(Payload).
CRC16 контрольная сумма поля DATA
-вычисляется без учёта дополнительных синхробитов Stuffed Bit (см. п.3.2.3)
-вычисляется побитовой сверткой данных с полиномом 0x18005(11000000000000101)

Handshake Packets(HP) -пакет квитирования.
Этим пакетом обычно заканчивается транзакция между хостом и конечной точкой. В нем сообщается о результатах приёма пакета данных.
Рис.14 Структура пакета квитирования.

Таблица 4. Описание полей:

PID	PID NAME	Описание
0xС3(1101 0010)	ACK	Выставляется хостом(IN-транзакция) или функцией(OUT) и потверждает, что обмен данными между ними прошел без ошибок
0x5A(0101 1010)	NAK	Выставляется только функцией, потверждает что данные OUT-транзакции приняты от хоста с ошибкой
0x1E(0001 1110)	STALL	Выставляется только функцией, подтверждает что функция остановлена и не готова к обмену в IN/OUT транзакциях.

Preambule Packets(HP) - преамбула низкоскоростного пакета.
Этот пакет предписывает хабу работающему на полной скорости передать следующий за преамбулой пакет на низкой скорости.
После получения сигнала EOP в конце низкоскоростного пакета хаб должен вернуться на полную скорость
Рис.15 Структура пакета преамбулы.

Таблица 5. Описание полей:

PID	PID NAME	Описание
0xС3(0011 1100)	PRE	Выставляется хостом. Предписывает хабу передать пакет за преамбулой на LS.

3.5.2 Транзакция (Transaction).

Транзакция это однократный обмен данными между хостом и конечной точкой.

Обычно она состоит из трёх стадий(пакетов):
-хост выбирает с кем он будет общаться(маркерный пакет)
-посылка данных (пакет данных)
-подтверждение приёма данных(пакет квитирования)

Транзакции включаются в состав кадров, которые передаются каждую 1 ms.

Транзакции связаны с типом передачи, на который настраивается конечная точка в процессе инициализации устройства(см.п.3.3)

Типы передачи:
Control Transfers - передача управление (команды)
Хост посылает команды, функция принимает с подтверждением.
Рис.15 Структура транзакции при передаче управления.

Bulk Data Transfers - передача важных данных(ошибки не допустимы: файл)
Этот тип передачи гарантирует доставку пакета без ошибок, но не гарантирует время доставки.
Хост и функция подтверждают приём данных.
Рис.16 Структура транзакции при передаче важных данных.

Interrupt Data Transfers - передача данных по прерыванию (ввод координат: клавиатура, мышь)
Структура транзакции одинакова с Bulk Transactions (рис.16)

Isochronous Data Transfers - передача изохронных данных (потоковая передача с возможными ошибками: микрофон, видео)
Этот тип передачи гарантирует время доставки данных, но не гарантирует их правильность.
В этих транзакциях не используется пакет подтверждения.
Рис.17 Структура транзакции при передаче изохронных данных.

TimeOut время ожидания в транзакциях:
Устройство должно ожидать квитирования не менее 16 битовых интервалов и приостанавливаться через 18 битовых интервалов.
Хост может послать следующий маркер, если устройство не ответило, не ранее чем через 18 битовых интервалов

Ограничения для LowSpeed транзакций:
Максимальное количество байт данных в транзакции не более 8.
Поддерживаются только передачи прерывания и управления
Пакет SOF не получается низко скоростными устройствами.

3.5.3 Кадр (Frame).

Кадр это набор транзакций, который начинается пакетом SOF(Start-of-Frame).
Кадры генерируются 1000 раз в секунду (1ms). Пакет SOF содержит в себе счетчик кадров.
Пакет SOF принимается одновременно всеми устройствами сети, он позволяет синхронизоваться устройствами относительно часов хоста.
Передача всех данных с устройств должны быть закончены до начала следующего кадра.
Устройства не выполнившие эти требования автоматически отключаются от сети.

3.6 Устройства(Devices)

Устройства USB представлены двумя глобальными классами: хабы и функции (см.п.3.3).
Устройство(хаб или функция) состоит их набора конечных точек (от 1 до 16 шт.).
Каждая точка является отдельным каналом связи между хостом и устройством, осуществляющим определённый тип передачи Control/Bulk/Interrupt/Isochronus (см.п.3.5.2).
В каждом устройстве всегда есть нулевая конечная точка, которая формирует канал с типом передачи Control(Канал по умолчанию).
Через канал по умолчанию хост получает информацию о устройстве(дескриптор устройства),
присваивает устройству индивидуальный адрес в сети (1..127) и записывает байт конфигурации устройства (после удачной конфигурации всех конечных точек устройства).
Определённый набор сконфигурированных конечных точек используемых совместно называется интерфейсом.
Устройство может иметь несколько альтернативных интерфейсов, которые описываются в конфигураций.
Устройство имеет одну и более конфигураций.
Каждая конфигурация имеет один и более интерфейсов.
Каждый интерфейс имеет одну и более конечных точек.
Для описания атрибутов устройства используют дескрипторы(описатели), которые сообщаются по запросу хоста(Device Requests).
Дескрипторы устройства и запросы хоста группируются в протоколы, подклассы, классы образуя реляционные базы данных.
Это существенно уменьшает количество дескрипторов и запросов для вновь создаваемых устройств USB.
Таким образом система дескрипторов(описателей свойств) и запросов(методов действий) формирует иерархическую реляционную структуру данных,
в которой можно проследить наследственную нить , представленную как:
Глобальный класс-Класс-Подкласс-Протокол-Конфигурация-Интерфейс-Конечная точка.

3.6.1 Инициализация устройств. Видимые состояния устройста

Устройство должно быть инициализировано при добавлении его в сеть.
Хост различает шесть состояний устройства:

Attached(Присоединённое)-Downstream хаб обнаружил сигнал CONNECT (состояние IDLE более 2ms) на шине.
Хаб изменяет данные в битовом поле изменений состояний (PSCB-Port Status Change Bitmap).
При периодическом опросе устройств, хост обнаруживает эти изменения.
Хост запрашивает более подробную информацию у хаба и изучает её.
После этого хост реконфигурирует хаб и дает ему команду подключить устройство к сети.

Powered(Запитаное)-хаб запитывает присоединённое устройство одной модульной нагрузкой(100ма),
и изменяет своё статусное состояния (чтобы хост обнаружил, что устройство запитано через хаб).
В этом состоянии устройство не должно отвечать на запросы хоста.
Хост обнаружив(по изменению статусного состояния хаба), что устройство запитано, подает сигнал RESET, который хаб передает на устройство в течении 10мс.

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

Adress(Адресовано)- Хост по каналу созданному по умолчанию назначает устройству индивидуальный адрес в сети (1..127).
Устройство изменяет свои конфигурационный байт из состояния "по умолчанию" на "адресованное".
Теперь оно может откликаться на свой адрес, при этом канал по умолчанию продолжает действовать.

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

Suspended(Подвешенное)- Устройство может переходить в подвешенное состояние, при котором оно не отвечает на запросы хоста.
Хаб определяет это состояние по сигналу SUSPEND (состояние IDLE более 3ms) и изменением статуса информирует хост.
Выход из этого состояния осуществляется подачей сигнала RESUME.

Рис.18 Видимые состояния устройства.

Так как после инициализации устройства изменяется топология сети, то эту операцию называют перенумерация шины (Bus Enumeration)

3.6.2 Запросы устройства (Device Requests)

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

С помощью запросов выполняются основные операции над устройствами определенные спецификацией:

1.Dynamic Attachment and Removal(Динамическое присоединение и удаление устройств)

2.Address Assignment(Назначение адреса устройству)

3.Configuration(Конфигурация устройства)

4.Data Transfer(Передача данных)

5.Power Management(Управление питанием)
-Power Budgeting(Планирование мощности потребления)
-Remote Wakeup(Пробуждение устройства по команде хоста)

6.Request Processing(Выполнение запросов)
-Request Processing Timing(Контроль времени обработки запросов)
-Reset/Resume Recovery Time(Возобновление работы по сигналам Reset/Resume)
-Set Address Processing(Установка адреса устройства)
-Standard Device Requests(Стандартные запросы устройства)
-Class-specific Requests(Специфичные запросы класса устройств)

7.Request Error(Запрос об ошибке)

Запросы передаются по нулевому каналу транзакциями SETUP (рис.15) и могут сопровождаться, если необходимо, передачей транзакций DATA (фаза данных).
Длина пакета DATA0 всегда равна 8 байтам (в транзакции SETUP)

Таблица 11. Формат данных при запросе (8 байт).
bmRequestType	bRequest	wValue		wIndex		wLength
Byte00	Byte01	Byte02	Byte03	Byte04	Byte05	Byte06	Byte07

byte00(bmRequestType) -битовое поле, тип запроса
D0..D4 -Получатель 0=Устройство; 1=Интерфейс; 2=Конечная точка; 3=Другой; 4..31=резерв
D5..D6 -Тип 0=Стандарт; 1=Класс ;2=Производитель 3=резерв
D7 -Направление 0=от хоста к устройству; 1=от устройства к хосту
byte01(bRequest) -код запроса, данные зависят от типа запроса .
byte02..03(wValue) -значение передаваемого параметра (word, где byte03-старшая часть слова, byte02-младшая)
byte04..05(wIndex) -значение индекса или смещения для передаваемого параметра(word, где byte05-старшая часть слова, byte04-младшая)
byte06..07(wLength) -число, длина блока данных в байтах передаваемая в фазе данных, т.е. после транзакции SETUP.(word, где byte07-старшая часть слова, byte06-младшая)
Если =0, то фаза передачи данных отсутствует и запрос представлен только транзакцией SETUP.
Запрос передается в шину USB последовательно начиная с Byte00.
Каждый бит байта передается последовательно начиная с бита-0.

Стандартные запросы(Standard Device Requests) устройства определённые спецификацией USB 1.1:

Таблица 12. **CLEAR_FEATURE**(Очистить возможности)
bmRequestType	bRequest	wValue	wIndex	wLength
0x00(к устройству)	0x01(код запроса)	Feature Selector	0x0000	0x0000
0x01(к интерфейсу)	0x01(код запроса)	Feature Selector	Interface	0x0000
0x02(к конечной точке)	0x01(код запроса)	Feature Selector	Endpoint	0x0000

Этот запрос хоста блокирует специальные возможности устройства, интерфейса или конечной точки указанные в поле wValue.

Таблица 13. **GET_CONFIGURATION**(Получить конфигурацию)
bmRequestType	bRequest	wValue	wIndex	wLength
0x80(от устройства)	0x08(код запроса)	0x0000	0x0000	0x0001

Этот запрос возвращает хосту текущую конфигурацию устройства. Если ответ 0, то устройство не сконфигурировано

Таблица 14.GET_DESCRIPTOR(Получить дескриптор)
bmRequestType	bRequest	wValue	wIndex	wLength
0x80(от устройства)	0x06(код запроса)	Descriptor Type and Index	ID Language	Descriptor Length

Этот запрос возвращает определённый полем wValue дескриптор, если он существует.
Старший байт(byte03) поля wValue указывает тип дескриптора:1=Device; 2=Configuration; 3-String; 4=Inteface; 5=Endpoint.
Младший байт(byte02) поля wValue указывает индекс дескриптора.
Для строковых дескипторов поле wIndex содержит идентификатор языка по кодировке UNICODE.
Поле wLength указывает общую длину дескриптора в байтах.

Таблица 15. **GET_INTERFACE**(Получить интерфейс)
bmRequestType	bRequest	wValue	wIndex	wLength
0x81(от интерфейса)	0x0A(код запроса)	0x0000	Interface	0x0001

Это запрос возвращает альтернативную установку для интерфейса, номер которого указан в поле wIndex.
В фазе данных хост принимает 1 байт с номером алтернативного интерфейса.

Таблица 16.GET_STATUS(Получить статус)
bmRequestType	bRequest	wValue	wIndex	wLength
0x80(от устройства)	0x00(код запроса)	0x0000	0x0000	0x0002
0x81(от интерфейса)	0x00(код запроса)	0x0000	Interface	0x0002
0x82(от конечной точки)	0x00(код запроса)	0x0000	Endpoint	0x0002

Этот запрос возвращает в фазе данных 2 байта статуса устройства или интерфейса или конечной точки, указанных в поле wIndex

Таблица 17. **SET_ADRESS**(Установить адрес)
bmRequestType	bRequest	wValue	wIndex	wLength
0x00(к устройству)	0x05(код запроса)	Device Adress	0x0000	0x0000

Это запрос устанавливает число, указанное в поле wValue, как адрес прибора в сети.

Таблица 18. **SET_CONFIGURATION**(Установить конфигурацию)
bmRequestType	bRequest	wValue	wIndex	wLength
0x00(к устройству)	0x09(код запроса)	Configuration Value	0x0000	0x0000

Этот запрос устанавливает число, записанное в поле wValue как конфигурацию устройства.
Если число 0, то устройство будет не сконфигурированным

Таблица 18. **SET_DESCRIPTOR**(Установить дескриптор)
bmRequestType	bRequest	wValue	wIndex	wLength
0x00(к устройству)	0x07(код запроса)	Descriptor Type and Index	ID Language	Descriptor Length

Это необязательный запрос.
Если устройство поддерживает его, то существующие дескрипторы устройства указанные в поле wValue, заменяются дескрипторами , которые хост передаст в фазе данных.

Таблица 19. **SET_FEATURE**(Установить возможности)
bmRequestType	bRequest	wValue	wIndex	wLength
0x00(к устройству)	0x03(код запроса)	Feature Selector	0x0000	0x0000
0x01(к интерфейсу)	0x03(код запроса)	Feature Selector	Interface	0x0000
0x02(к конечной точке)	0x03(код запроса)	Feature Selector	Endpoint	0x0000

Этот запрос включает дополнительные возможности устройства, интерфейса, конечной точки указазанные в поле wValue.

Таблица 20. **SET_INTERFACE**(Установить интерфейс)
bmRequestType	bRequest	wValue	wIndex	wLength
0x01(к интерфейсу)	0x0B(код запроса)	Alternate Setting	Interface	0x0000

Этот запрос позволяет интерфейсу номер которого указан в поле wIndex использовать альтернативные установки с номером указанным вwValue.

Таблица 21. SYNC_FRAME(Синхронизовать кадр)
bmRequestType	bRequest	wValue	wIndex	wLength
0x82(от конечной точки)	0x0C(код запроса)	0x0000	Endpoint	0x0002

Этот запрос используется, чтобы установить и затем сообщить кадр синхронизации конечной точке.

параметры запросов:
Descriptor Types(Тип дескриптора):1=Device; 2=Configuration; 3-String; 4=Inteface; 5=Endpoint
Feature Selectors(Выбор возможностей):1=Device_Remote_Wakeup; 0=Endpoint_Halt
Interface(номер интерфейса): целое число
Endpoint(адрес конечной точки):целое число 0..15 Alternate Setting(номер альтернативного интерфейса):целое число
ID Language(Идентификатор языка):целое число, идентификатор языка в UNICODE

3.6.3 Дескрипторы устройств.

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

В USB определены следующие стандартные дескрипторы: устройств, конфигурации, интерфейса, конечной точки, строки.

Дескриптор устройства (Device Descriptor)
Дескриптор устройства описывает общую информацию относительно устройства USB.
Она включает информацию, которая применяется устройством глобально и во всех его конфигурациях.
Устройство USB имеет только один дескриптор устройства.

Таблица 22. Дескриптор устройства (18 байт).
bLength	bDescriptorType	bcdUSB		bDeviceClass	bDeviceSubClass	bDeviceProtocol	bMaxPacketSize0	idVendor		idProductd		bcdDevice		iManufacturer	iProduct	iSerialNumber	bNumConfigurations
Byte00	Byte01	Byte02	Byte03	Byte04	Byte05	Byte06	Byte07	Byte08	Byte09	Byte10	Byte11	Byte12	Byte13	Byte14	Byte15	Byte16	Byte17

byte00(bLength) -число, длина дескриптора в байтах
byte01(bDescriptorType) -константа, тип дескриптора =1 (Device Descriptor)
byte02..03(bcdUSB) -число (BCD-формат), номер спецификации USB поддерживаемой устройством
byte04(bDeviceClass) -число, код класса устройства.
bDeviceClass=0 интерфейс сам определяет информацию о классе, различные интерфейсы функционируют независимо.
bDeviceClass=0x01..0xFE интерфейсы определены классом устройств заданым фондом USB.
bDeviceClass=0xFF класс устройства для данных интерфейсов определен производителем.
byte05(bDeviceSubClass) -число, код подкласса устройства.Заданы фондом USB(за исключением класса 0xFF)
byte06(bDeviceProtocol) -число, код протокола устройства
bDeviceClass=0 устройство не использует протоколы определённые классом
bDeviceClass=0x01..0xFE протоколы определены классом. Заданы фондом USB.
bDeviceClass=0xFF протокол определён производителем.
byte07(bMaxPacketSize0) -число, максимальный размер пакета данных для нулевой точки в байтах
byte08..09(idVendor) -идентификатор, производителя. Задан фондом USB.
byte10..11(idProduct) -идентификатор, продукта.Задан производителем устройства.
byte12..13(bcdDevice) -число (BCD-формат), версия устройства
byte14(iManufacturer) -индекс, индекс строкового дескриптора производителя
byte15(iProduct) -индекс, индекс строкового дескриптора продукта
byte16(iSerialNumber) -индекс, индекс строкового дескриптора серийного номера устройства
byte17(bNumConfigurations) -число, количество возможных конфигураций

Дескриптор конфигурации (Configuration Descriptor)
Дескриптор конфигурации описывает информацию о конфигурации устройства.
Дескриптор содержит поле bConfigurationValue значение которого используется как параметр в запросе Set Configuration, который заставляет устройство переходить в описанную конфигурацию.
Устройства могут иметь несколько дескрипторов конфигураций.

Таблица 23. Дескриптор конфигурации (9 байт).
bLength	bDescriptorType	wTotalLength		bNumInterfaces	bConfigurationValue	iConfiguration	bmAttributes	MaxPower
Byte00	Byte01	Byte02	Byte03	Byte04	Byte05	Byte06	Byte07	Byte08

byte00(bLength) -число, длина дескриптора в байтах
byte01(bDescriptorType) -константа, тип дескриптора =2 (Configuration Descriptor)
byte02..3(wTotalLength) -число, Общая длина данных в байтах, возвращаемых для этой конфигурации.
Включает объединенную длину всех дескрипторов (конфигурации, интерфейса, конечной точки, и класса или определений продавца) возвращенных для этой конфигурации.
byte04(bNumInterfaces) -число, интерфейсов поддерживаемых этой конфигурацией
byte05(bConfigurationValue) -число, номер конфигурации, используемый в запросе SetConfiguration, для выбора этой конфигурации.
byte06(iConfiguration) -индекс, строкового дескриптора описывающего эту конфигурацию
byte07(bmAttributes) -битовое поле, определяет свойства устройства
D7=1 устроство питается от шины USB
D6=1 устройство имеет независимое питание
D5=1 устройство имеет функцию удалённого пробуждения
D4..D0 резерв (всегда 0)

byte08(MaxPower) -число, максимальный ток потребления в х2мА (т.е. 50=100мА)

Дескриптор интерфейса (Interface Descriptor)
Дескриптор интерфейса описывает набор конечных точек включенных в интерфейс для заданной конфигурации.
Дескриптор интерфейса всегда возвращается как часть дескриптора конфигурации. К нему нельзя непосредственно обращаться запросом Get или Set Descriptor.
Дескриптор интерфейса никогда не включает нулевую конечную точку в число конечных точек.

Таблица 24. Дескриптор интерфейса (9 байт).
bLength	bDescriptorType	bInterfaceNumber	bAlternateSetting	bNumEndpoints	bInterfaceClass	bInterfaceSubClass	bInterfaceProtocol	iInterface
Byte00	Byte01	Byte02	Byte03	Byte04	Byte05	Byte06	Byte07	Byte08

byte00(bLength) -число, длина дескриптора в байтах
byte01(bDescriptorType) -константа, тип дескриптора =4 (Interface Descriptor)
byte02(bInterfaceNumber) -число, номер интерфейса в массиве параллельных интерфейсов поддерживаемых данной конфигурацией.
byte03(bAlternateSetting) -число, номер альтернативного интерфейса для интерфейса указанного в bInterfaceNumber
byte04(bNumEndpoints) -число, количество конечных точек используемых этим интерфейсом (без нулевой точки)
byte05(bInterfaceClass) -число, код класса интерфейса.
bInterfaceClass=0 -зарезервирован для будущей стандартизации
bInterfaceClass=0xFF -класс интерфейса определенный производителем
bInterfaceClass=0x1..0xFE -класс интерфейса задан фондом USB
byte06(bInterfaceSubClass) -число, код подкласса интерфейса
byte07(bInterfaceProtocol) -число, код протокола.
Эти коды определяются значением полей bInterfaceClass и bInterfaceSubClass.
Если интерфейс поддерживает запросы определяемые классом, этот код определяет протоколы, которые устройство использует как определено спецификацией класса устройства.
Если это поле сброшено в 0, устройство не использует протокол определяемый классом на этом интерфейсе.
Если это поле установлено к 0xFF, устройство использует для этого интерфейса протокол определенный производителем.
byte08(iInterface) -индекс, строкового дескриптора интерфейса

Дескриптор конечной точки (Endpoint Descriptor)
Каждая конечная точка, используемая для интерфейса имеет собственный дескриптор.
Этот дескриптор содержит информацию, требуемую хостом, чтобы определить требования по пропускной способности каждой конечной точки.
Дескриптор конечной точки всегда возвращается как часть дескриптора конфигурации.
К нему нельзя непосредственно обращаться запросом Get или Set Descriptor.
Нулевая точка не имеет дескриптора.

Таблица 25. Дескриптор конечной точки (7 байт).
bLength	bDescriptorType	bEndpointAddress	bmAttributes	wMaxPacketSize		bInterval
Byte00	Byte01	Byte02	Byte03	Byte04	Byte05	Byte06

byte00(bLength) -число, длина дескриптора в байтах
byte01(bDescriptorType) -константа, тип дескриптора =5 (Endpoint Descriptor)
byte02(bEndpointAddress) -число, адрес конечной точки
Bit0..3 -адрес конечной точки (0..15)
Bit4..6 -резерв
Bit7 -направление передачи 0=OUT; 1=IN
byte03(bmAttributes) -битовое поле атрибутов
Bit0..1 - тип передачи 00=Control; 01=Isochronous; 10=Bulk; 11=Interrupt
Bit2..7 - резерв
byte04..05(wMaxPacketSize) -число, максимальная длина пакета данных используемая конечной точкой.
Для изохронных конечных точек, это значение используется, чтобы резервировать время шины в кадре.
byte06(bInterval) -число,Интервал при опросе конечной точки в миллисекундах.
Это поле игнорируется для конечных точек Bulk и Control.
Для изохронных конечных точек это поле должно быть установлено в 1.
Для конечных точек прерывания, это поле может иметь значение от 1 до 255.

Дескриптор строки (String Descriptor)
Дескрипторы строк являются необязательными.
Строковые дескрипторы описывают характеристики устройства текстовыми строками, что удобно для человека.
Если устройство не поддерживает строковые дескрипторы, все ссылки к строковым дескрипторам внутри устройства, конфигурации, и дескрипторах интерфейса должны быть сброшены в нуль.
При запросе строкового дескриптора, запросчик определяет требуемый язык, используя ID (LANGID) определенный Microsoft Windows UNICODE.
В отличии от Windows строка не обязана заканчиваться NULL символом
Таблица 26. Дескриптор строки (более 2 байт).

bLength	bDescriptorType	String
Byte00	Byte01	Byte02..N

byte00(bLength) -число, длина дескриптора в байтах
byte01(bDescriptorType) -константа, тип дескриптора =3 (String Descriptor)
byte02..N(bLength) -строка в UNICODE

3.7 Спецификация хаба(Hub Specificftion)

Хаб -это устройство USB и всё сказанное в п.3.6 относится и к нему.

Тем не менее в спецификации USB 1.1 добавлена глава11, которая дополнительно описывает хабы.

3.7.1 Функционирование хаба.

Хаб является разветвителем сети, который предоставляет порты для устройств USB.

Хаб состоит из одного верхпередающего порта(Upstream) и нескольких внизпередающих портов(Downstream).

Рис.19 Архитектура хаба..

Хаб устроен из повторителя(Repeater) и управляющего им контроллера(Controler).

Устройства-функции могут подключатся только к Downstream портам хаба.

В свободном состоянии(Idle) все порты хаба работают только на приём, они ожидают сигнала SOP-начала пакета.

Рис.20 Хаб в состоянии ожидания пакета данных (Idle).

Хаб транслирует данные полученные с Upstream во все Downstream порты.

Таким образом, пакет посланный хостом попадает ко всем сконфигурированым устройствам сети одновременно.

Устройство само решает обрабатывать этот пакет или нет.

Рис.21 Хаб в состоянии передачи пакета от Хоста.

Данные поступающие из Downstream порта передаются только в Upstream порт, при этом остальные Downstream порты блокируются.

Таким образом хост принимает пакет только от одного устройства сети, остальные устройства в этот момент блокированы хабами и вести обмен данными не могут.

Устройство может послать пакет только по запросу хоста.

Рис.22 Хаб в состоянии передачи пакета от Устройства.

Таким образом сигнал SOP включает повторитель, а сигнал EOP выключает (переводит в Idle).

Хост управляет поведением хаба считывая его дескрипторы(состояния) и посылая ему запросы(команды).

3.7.2 Синхронизация хаба с кадрами.

Одна из основных проблем интерфейса USB , это необходимость синхронизации работы сети с частотой подачи кадров(1000Гц).

Хост и устройства должны заранее спланировать свою работу так, чтобы уместить целое число пакетов в период кадра.

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

Устройства сами должны вычислять конец кадра отсчитывая время от сигнала SOF.

Контроллер хаба имеет таймер кадра, который запускается сигналом SOF.

Этот таймер вырабатывает два флага конца кадра EOF1 и EOF2(End of Frame).

Флаг EOF1 выставляется за 32 битовых интервала до начала следующего кадра.

Любой сигнал EOP(конец пакета) полученный после EOF1 и до EOF2 считается концом кадра.

Флаг EOF2 выставляется за 10 битовых интервалов до начала следующего кадра.

Если после флага EOF2 на порт Downstream продолжает поступать данные или сигнал EOP не был получен, то хаб отключает этот порт от сети.

Перед началом нового кадра по шине не должны передаваться данные, это время используется хабами для анализа линейных сигналов D+/D-

Это позволяет определить подключение/отключение устройств к портам хаба.

Чтобы хаб синхронизовал свою работы с хостом, необходимо чтобы он принял два последовательных сигнала SOF.

Хаб сообщает о своей синхронизации с хостом установкой флага в своём статусе.

Спецификация допускает работу не синхронизированного хаба не более 3 кадров подряд.

3.7.3 Состояние хаба и его инициализация.

В отличие от функции хаб различает большее количество состояний:

-состояния по Downstream порту

-состояния по Upstream порту

-состояния по внутреннему порту

-состояния повторителя

Эти состояния описаны в спецификации USB 1.1 в пунктах 11.4-11.13 .

В пункте 11.14 описана конфигурация хаба.

Здесь мы не будем описывать эти состояния и конфигурацию.

Поясним только, что конфигурирования и состояния хаба зависят от запросов хоста и дескрипторов хаба.

3.7.4 Дескрипторы хаба.

Хаб является устройством, поэтому он поддерживает стандартные дескрипторы устройств описанные в п.3.6.3

Для класса устройств типа хаб спецификация определила код HUB_CLASSCODE=0х09H

Кроме стандартных дескрипторов устройств спецификация определяет класс-специфицированные дескрипторы для класса хабов.

Дескриптор хаба (Hub Descriptor)

Таблица 27. Дескриптор хаба (8 байт или более).
bDescLength	bDescriptorType	bNbrPorts	wHubCharacteristics		bPwrOn2PwrGood	bHubContrCurrent	DeviceRemovable	PortPwrCtrlMask
Byte00	Byte01	Byte02	Byte03	Byte04	Byte05	Byte06	Byte7..39	Byte08..

byte00(bDescLength) -число, длина дескриптора в байтах

byte01(bDescriptorType) -константа, тип дескриптора =0x29h (Hub Descriptor)

byte02(bNbrPorts) -число , количество Downstream портов поддерживаемых хабом

byte03..04(wHubCharacteristics) -битовое поле:

D1..D0= 00-все порты запитаны к одному; 01-каждый порт включается отдельно; 1Х-неопределено

D2= 0-хаб не входит в составное устройство; 1- хаб является частью составного устройства;

D4..D3= 00-глобальная защита от перегрузки, суммированием тока всех портов; 01-защита каждого порта; 1Х-нет защиты от перегрузки

D15..D5=резерв

byte05(bPwrOn2PwrGood) -число, в 2мс единицах, показывает время необходимое для запитки порта

byte06(bHubContrCurrent) -максимальный ток в мА потребляемый контроллером хаба

byte07..39(DeviceRemovable) -битовое поле, которое показывает является устройство съёмным, значение бита 0-съёмное ; 1-не съёмное. Всего 256 бит(bit0-неиспользуется, bit1-порт1 ит.д. до 255)

byte40(bNumConfigurations) -битовое поле, которое нужно для согласования с версией USB 1.0 количество бит равно числу портов плюс битов кратности 8. Все биты должны быть установлены в 1.

3.7.5 Запросы хаба хостом.

Хаб как устройство поддерживает запросы стандартных устройств описанные в пункте 3.6.2

Для хаба определенны класс-специфицированные запросы.

Таблица 28. класс-специфицированные запросы Хаба
Request	bRequestType	bRequest	wValue	wIndex	wLenght	Data
Name	Byte00	Byte01	Byte02..03	Byte04..05	Byte06..07	N*Byte
ClearHubFeature	00100000B	CLEAR_ FEATURE	Feature Selector	Zero	Zero	None
ClearPortFeature	00100011B	CLEAR_ FEATURE	Feature Selector	Port	Zero	None
GetBusState	10100011B	GET_ STATE	Zero	Port	One	Per-Port Bus State
GetHubDescriptor	10100000B	GET_DESCRIPTOR	Descriptor Type and Descriptor Index	Zero or Language ID	Descriptor Length	Descriptor
GetHubStatus	10100000B	GET_ STATUS	Zero	Zero	4	Hub Status and Hub Change Indicators
GetPortStatus	10100011B	GET_ STATUS	Zero	Zero	4	Port Status and Port Change Indicators
SetHubDescriptor	00100000B	SET_DESCRIPTOR	Descriptor Type and Descriptor Index	Zero or Language ID	Descriptor Length	Descriptor
SetHubFeature	00100000B	SET_ FEATURE	Feature Selector	Zero	Zero	None
SetPortFeature	00100011B	SET_ FEATURE	Feature Selector	Port	Zero	None

где:

bRequest -код запроса.

GET_STATUS=0;

CLEAR_FEATURE=1;

GET_STATE=2;

SET_FEATURE=3;

Reserved=4-5

GET_DESCRIPTOR=6;

SET_DESCRIPTOR=7

Feature Selectors - выбор возможностей

C_HUB_LOCAL_POWER =0 (Получатель Hub)-возможность изменения локального питания;

C_HUB_OVER_CURRENT =1 (Получатель Hub)-возможность изменения контроля перегрузки по току для хаба;

PORT_CONNECTION =0 (Получатель Port)-возможность подсоединения порта;

PORT_ENABLE=1(Получатель Port)-возможность разрешения порта;

PORT_SUSPEND=2 (Получатель Port)-возможность приостановки порта;

PORT_OVER_CURRENT=3 (Получатель Port)-возможность контроля перегрузки по току для порта;

PORT_RESET=4(Получатель Port)-возможность сброса порта;

PORT_POWER=8 (Получатель Port)-возможность контроля питания порта;

PORT_LOW_SPEED=9 (Получатель Port)-возможность работы на низкой скорости;

C_PORT_CONNECTION=16 (Получатель Port)-возможность изменения подключения порта;

C_PORT_ENABLE =17 (Получатель Port)-возможность изменения разрешения порта;

C_PORT_SUSPEND =18 (Получатель Port)-возможность изменения приостановки порта;

C_PORT_OVER_CURRENT=19 (Получатель Port)-возможность изменения контроля перегрузки;

C_PORT_RESET =20 (Получатель Port)-возможность изменения сброса порта;

Hub Status -битовое поле (16 бит), состояние хаба

Bit0 -Источник локального питания(Local Power Source) 0-локальное питание включено; 1-локальное питание выключено;

Bit1 -Индикатор перегрузки(Over-current Indicator) 0-перегрузка по току; 1-нет перегрузки по току;

Bit15..2 - резерв

Hub Change Indicators - битовое поле (16 бит), изменение индикаторов

Bit0 -Изменения состояния локального питания(Local Power Status Change) 0-нет изменения локального питания; 1-было изменение локального питания;

Bit1 -Изменение индикатора перегрузки(Over-current Indicator Change) 0-изменение индикатора перегрузки по току; 1-нет было изменение индикатора;

Bit15..2 - резерв

Per-Port Bus State -битовое поле(8 бит), состояние линий D+,D-;

Bit0 -значение на линии D-;

Bit1 -значение на линии D+;

Bit7..Bit2 -резерв.

Port Status -битовое поле (16 бит), состояние порта;

Bit0 -Состояние текущего соединения (Current Connect Status) 0-нет подсоединённого устройства; 1-к порту присоединено устройство;

Bit1 -Вкл/Выкл порта (Port Enabled/Disabled) 0-порт выключен; 1-порт включен;

Bit2 -Приостановлено(Susped) 0-нет приостановки; 1-приостановка или возобновление;

Bit3 -Индикатор перегрузки (Over-current Indicftor) 0-нет перегрузки; 1-есть перегрузка;

Bit4 -Сброс (Reset) 0-сброса не было; 1-сброс был;

Bit7..5 -резерв;

Bit8 -Питание порта (Port Power) 0-питание порта выключено; 1-питание порта включено;

Bit9 -Присоединение низкоскоростного устройства (Low Speed Device Attached) 0-к порту подключено FS устройство; 1-к порту подключено LS устройство;

Bit15..10 -Резерв.

Port Change Indicators - битовое поле (16 бит), изменение индикаторов порта

Bit0 -Изменения состояния соединения(Connect Status Change) 0-нет изменения текущего соединения; 1-было изменение соединения;

Bit1 -Изменение состояния порта Вкл/Выкл(Port Enable/Disable Change) 0-было изменение вкл/выкл; 1-нет было изменение;

Bit2 -Изменение состояния приостановки (Suspend Change) 0-нет изменений; 1-Восстановлено (Resume complete);

Bit3 -Изменение индикатора перегрузки (Over-Current Indicator Change) 0-нет изменений; 1-есть изменения;

Bit4 -Изменение состояния сброса (Reset Change) 0-нет изменений; 1-был сброс;

Bit15..5 -Резерв.

3.8 Спецификация хоста.

3.8.1 Логическая структура хоста.

Хост является единственным и основным ведущим устройством сети.

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

Устройство не может самостоятельно вызывать хост, оно ожидает обращение хоста к устройству.

Поэтому хост должен спланировать всю работу в сети.

Логически связь хоста с устройством разбита на три уровня.

Рис.23 Логическая структура Хост - Устройство.

Три логических уровня:

1.Клиенский уровень (Client-Function).

Организует логическую связь программы пользователя с функцией устройсва.

Обеспечивает передачу и приём пользовательских данных между ПК и устройством.

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

Использует каналы точек 1..15.

2.Системный уровень (USB System).

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

Обеспечивает конфигурацию и настройку устройства.

Делает невидимым для драйвера работу физического уровня.

Использует канал по умолчанию (0-точка)

3.Физический уровень (USB Interface).

Обеспечивает физическую передачу данным между контроллерами хоста и устройства.

Рис.24 Структура хоста.

Client Soft- клиенское программное обеспечение.

Клиентское программное обеспечение общается с устройством через интерфейс.

Интерфейс это набор логических каналов связи с конечными точками.

В интерфейсе каждый канал может быть настроен на передачу, или на приём.

Интерфейсов может быть несколько и ПО клиента выбирает номер интерфейса по которому оно будет общаться с устройством.

Физически связь клиентского ПО с USB драйвер осуществляется с помощью пакетов содержащих команды ввода/вывода (IRP).

IRPs(I/O Request Packets) -протокол обмена ПО клиента с драйвером USB.

Пакет содержащий запрос к драйверу USB о вводе или выводе информации через указанный логический канал.

В этом пакете определён тип передачи, адрес буфера памяти и размер данных для обмена по заданному каналу.

USB драйвер сам забирает или помещает даные в этот буфер, клиент только указывает размер и адрес буфера.

Host Software- программное обеспечение хоста.

Это не обязательный элемент хоста.

Если он присутствует, то его конфигурацию должно выполнять ПО клиента.

Обычно применяется если система не использует стандартный USB драйвер.

USB Driver(USBD)- драйвер USB.

Этот драйвер организует базисный интерфейс хоста(USBDI), который обеспечивает взаимодействие клиентов с устройствами USB.

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

Назначает адрес каждому физическому устройству сети.

Распределяет полосу пропускания шины между устройствами.

Планирует все транзакции.

Связь между USBD и HCD(HC Driver) известна как HCDI-интерфейс(Host Controller Driver Interface)

Этот интерфейс никогда не доступен непосредственно клиентам и таким образом не определяется спецификацией USB.

Однако особенности HCDI, определены каждой операционной системой, которая поддерживает различные реализации хост контроллеров.

USBD получает пакеты запросов ввода/вывода от клиентского ПО и формирует задание для HC драйвера.

HC Driver(HCD-Host Conttroller Driver )-драйвер хост контроллера.

Этот драйвер отвечает за подключение USB драйвера к различным хост контроллерам.

Принимает от USBD перечень текущих транзакций.

Планирует выполнения транзакций выстраивая их в очередь на исполнение

Сообщает в USBD о выполнении транзакции.

HW-Defined(Hard Ware Defined) -интерфейс между HC Driver и Host Controller.

Этот интерфейс описывается (definition) в драйвере HCD аппаратной частью контроллера .

Host Controller -контроллер хоста.

Физическое устройство, которое формирует и физически выполняет транзакции из очереди установленной драйвером HCD.

Контроллер формирует кадры, выставляя каждую 1мс пакет начала кадра.

Кодирует данные в NRZI.

Вставляет синхробиты.

Контроллер подает текущую транзакцию в схему последовательной передачи данных SIE(Serial Interface Engine) в сигнальные линии USB.

Serial Interface Engine (SIE) -физический последовательный интерфейс.

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

4. Приложение. Инициализации устройства на базе микроконтроллера AT91SAM7S64..512 через виртуальный СОМ порт.

4.1.Описание устройства USB(UDP) входящего в состав МК.

Характеристики UDP:
-поддерживает только полноскоростной режим(FS-Full Speed,12МГц) USB 2.0
-поддерживает 4 контрольные точки,т.е. возможно 4 канала(pipe) связи.
AT91SAM7S64

Банк- это буфер памяти(массив), очередь FIFO, которая устроена по принципу первым пришёл -первым вышел, как мы видим для 1 и 2 точки он равен 64 байтам.
Когда точка работает с двумя FIFO, банки работают по очереди.
То есть UDP может обмениваться с хостом USB данными из одного банка, а программа МК в это время работать с другим банком(готовить новые данные).

Особенности UDP:

-Запись в буфер только побайтно(8 бит), хотя МК имеет разрядность 32 бит.
При записи переменной int32 в буфер записывается только младший байт.

-Для работы UDP используют главный синхронизирующий сигнал МСК=48МГц, из которого вырабатывается 12МГц сигнал синхронизации UDP.

Поэтому для МК используют кварц с частотой 18.432МГц(MAINCK).
Получают сигнал МСК=48МГц следующим образом:
-Из MAINCK с помощью генератора с ФАПЧ(PLL) получают частоту генератора ФАПЧ PLLCK=MAINCK*125/48=18.432*125/24=96МГц умножаю частоту кварца на 125 и деля на 24.
Далее получаем сигнал MCK=PLLCK/2=48МГц и сигнал USBCLK=PLLCK=96/2=48МГц из сигнала генератора ФАПЧ.

Таким образом, и МК(MCK) и UDP(USBCLK) работают у нас на одной частоте 48МГц.
12МГц на котором работает USB интерфейс в режиме FS вырабатывается автоматически в UDP из сигнала USBCLK=48МГц.

4.2.Схема подключения.

Рис.25 Схема подключения к USB разъёму
AT91SAM7S64

МК имеет два отдельных выхода DDM и DDP -это линейные выходы USB +D и -D
Они подключаются к USB интерфейсу через резисторы номиналом 27Ом (R15, R16) и нагружаются емкостями С30, С31=15пФ.

По стандарту USB 2.0 режим FS задаётся подтягиванием линии -D резистором 1,5кОм к плюсовой шине.
То есть хост USB обнаруживает подключённое устройство по наличию этого резистора на линии -D.
Мы подключили этот резистор R12 через транзистор VT1, которым будем подключать его к плюсу питания сигналом PA02=1.
Резистор R12 можно отключать от плюса питания подачей 0 на диоды VD4(сигнал RESET) и VD6 (сигнал PA02), если на диоды сигнал 0 не подаётся, то транзистор будет открыт за счёт сопротивления R9, которое подаёт напряжения открытия на базу транзистора VT1.
Таким образом, при отсутствии питания или сигнале сброса резистор не будет подключен к линии -D и хост на обнаружит подключённое устройство.
Этот резистор мы будем подключать, когда нам нужно, то есть после того как настроим МК на работу с USB.
Мы должны использовать одну линию МК настроенную на выход для управления этим резистором. На схеме это линия PA02.
При РА02=0 резистор не подключён, РА02=1 резистор подключён.
По сути манипуляция этим резистором имитирует вставку/вынимание устройства в разъём хаба USB, таким образом мы можем вставлять и удалять устройство не вынимая его из разъёма(т.е. программно).

Резисторы R17,R18 образуют делитель с 5В до 3,3В, который подключен к входу РА03.
Мы используем ещё один вывод МК настроенный на вход.
По сигналу РА03 мы сможем обнаружить, что наше устройство вставлено в разъём USB хоста.
РА03=1 есть напряжения +5В, значит кабель вставлен в разъём хаба.
РА03=0 устройство не подключено к хабу.
Этот сигнал мы будем анализировать после настройки МК для работы с USB, и если он будет равен 1, то мы подключим резистор R12 сигналом РА02 и начнём инициализацию USB устройства.

4.3. Состояния устройства USB 2.0

Рис.2 Диаграмма возможных состояний устройства USB
AT91SAM7S64

Всего устройство USB может находиться в 6 состояниях:
Attached(Подключенное)-хост обнаружил резистор на линии -D подтянутый к плюсу

Powered(Запитаное)-хаб запитывает присоединённое устройство одной модульной нагрузкой(100ма),и изменяет своё статусное состояния (чтобы хост обнаружил, что устройство запитано через хаб).
В этом состоянии устройство не должно отвечать на запросы хоста.
Хост обнаружив(по изменению статусного состояния хаба), что устройство запитано, подает сигнал RESET, который хаб передает на устройство в течении 10мс.

Default(Исходное)-После того как запитанное устройство получит от хаба сигнал RESET (сброс шины), оно сбрасывает регистры в исходное состояние и может отвечать на запросы хоста по адресу нулевой конечной точки.
В этом состоянии хост читает дескриптор устройства и определяет максимальный размер буфера , которую может поддерживать канал точки 0 (это FIFO= 8 байт).

Adress(Адресовано)- Хост по каналу 0(адрес=0) созданному по умолчанию назначает устройству индивидуальный адрес в сети (1..127).
Устройство изменяет свои конфигурационный байт из состояния "по умолчанию" на "адресованное". Теперь оно может откликаться на свой адрес, при этом канал по умолчанию (адрес=0) продолжает действовать.

Configured(Сконфигурированное)-После того как устройство получило свой адрес, хост конфигурирует все функции устройства(конечные точки).
Определяя тип передачи, ширину канала для каждой точки и количество модульных нагрузок(1 мод. нагрузка=100мА, максимально можно до 5 нагрузок).
Данные о настройке устройства записываются в байт конфигурации устройства. После этого устройство считается подключенным к сети.
Оно уже не будет отвечать на адрес=0, который используется только при подключении устройства, а будет отвечать только на присвоенный ему адрес.
Если по каким-либо причинам хост не сможет сконфигурировать устройство, то он даёт команду хабу отключить данный порт от сети.

Suspended(Приостановленное)- Устройство может переходить в подвешенное состояние, при котором оно не отвечает на запросы хоста.
Хаб определяет это состояние по сигналу SUSPEND и изменением статуса информирует хост.
Выход из этого состояния осуществляется подачей сигнала RESUME.

На рис.2 вы видите все состояния устройства и как они могут переходить друг в друга по различным событиям.

Основное состояние Configured(Сконфигурированное), только в этом состоянии мы можем вести пользовательский обмен данными

4.4.Взаимодействие устройства с хостом.

Интерфейс USB устроен как сеть типа ЗВЕЗДА, где только хост может опрашивать устройства и получать от них ответы. Сами устройства не могут запрашивать хост, они всегда ждут, когда он к ним обратиться хост.
Поэтому хост всегда должен узнавать, что и в каком количестве устройство хочет передать хосту.
Хост циклически опрашивает все устройства с периодом заданным в конфигурации устройства, но не чаще 1мс.

Обращения хоста к устройству происходит транзакциями (набором пакетов).
Каждая транзакция это обращение хоста к конкретному адресу устройства и к конкретной конечной точке.

Транзакция состоит из пакетов управления и данных.
Вначале транзакции всегда передают Token Packets(TP) - Маркерный пакет.
Маркерный пакет содержит адрес устройства, адрес конечной точки, и тип данных DATA_OUT, DATA_IN, SETUP.
Далее идут пакеты с входными(DATA_IN) или выходными(DATA_OUT) данными или командами управления устройством(SETUP).
Заканчивают транзакцию пакетом Handshake Packets(HP) -пакет квитирования.

Транзакции встраиваются в кадры, которые передаются по шине каждую 1 мс.
Начало кадра помечается собственным пакетом.
Start-of-Frame Packets(SOF) пакет определяющий начала кадра.
Этот пакет посылается хостом каждую миллисекунду(1кГц), он обозначает начало нового кадра.
Этот пакет могут принимать все устройства сети, он без адресный.
Это единственный пакет имеющий синхронизацию с часами реального времени.
В пакете присутствует счетчик кадров, который является счетчиком миллисекунд.
Устройства могут синхронизировать свою работу с реальным временем, считывая это пакет.

4.5.Регистры UDP МК AT91SAM7S64

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

AT91SAM7S64

Основных регистров, которые нам предстоит использовать три:ISR, CSRx, FDRx
UDP_ ISR - регистр статуса прерывания. Этот основной регистр, который показывает нам , какая получена транзакция от хоста.
Контроллер автоматически выставляет флаги в 1 в этом регистре,эти единицы вызывают прерывание контроллера, если вы их используете.
Если прерывания не используете, то программа должна анализировать состояние флагов этого регистра и делать нужные действия.
После обработки событий программа должна сбросить эти флаги в 0, контроллер UDP самостоятельно не сбрасывает флаги, он их только выставляет в 1.

Анализ этого регистра мы вставляем в главный цикл нашей программы.
Он позволяет нам понять, что хост обратился к нашему устройству к конкретной конечной точке.
После этого мы должны проанализировать чего от нас хочет хост, прочитав регистр состояния заданной конечной точки х UDP_CSRх.
Далее мы принимаем или отсылаем нужные данные через буферные регистры конечной точки UDP_FDRх.
Остальные регистры UDP используются редко.

4.5.1 UDP_ ISR -регистр статуса прерывания UDP

Наименование регистра: UDP_ ISR
*AT91C_UDP_ISR =0xFFFB001C; -указатель на регистр в Си
AT91C_BASE_UDP->UDP_ISR=0х0000**00; -значение по умолчанию

AT91SAM7S64

EP0INT - статус прерывания конечной точки 0
EP1INT - статус прерывания конечной точки 1
EP2INT - статус прерывания конечной точки 2
EP3INT - статус прерывания конечной точки 3
0 - прерывание не возникало. 1 - возникло прерывание.

Данное прерывание могут генерировать несколько сигналов.
Причину,определяем по битам UDP_ CSR.
Прерывание генерируется битами RXSETUP, RX_DATA_BK0, RX_DATA_BK1, TXCOMP,STALLSENT, если какие-либо биты из них имеют единичное значение.
Прерывание сбрасывается записью 0 в эти биты.

RXSUSP - статуса прерывания по приостановке UDP (SUSPEND)
0 - не возникало. 1 - возникло прерывание по приостановке UDP.

USB -устанавливает этот флаг, если в течение 3 мс нет активности.
После этого USB-устройство вводит режим приостановки.
После сброса состояние данного бита необходимо сбросить UDP_ ICR.

RXRSM - статус прерывания по возобновлению UDP (RESUME)
0 - не возникало. 1 - возникло прерывание по возобновлению UDP.

USB-устройство устанавливает данный бит, если обнаруживается сигнал возобновления работы . После сброса состояние данного бита необходимо сбросить UDP_ ICR.

EXTRSM - статус прерывания по внешнему возобновлению (EXTERNAL RESUME)
0 - прерывание не возникало. 1 - возникло прерывание по внешнему возобновлению.

Данное прерывание возникает, когда, находясь в режиме приостановки, определяется асинхронный нарастающий фронт на линии "send_resume", если RMWUPE = 1.
После сброса состояние данного бита необходимо сбросить UDP_ ICR.

SOFINT - статус прерывания по началу кадра(SOF)
0 - прерывание не возникало. 1 - возникло прерывание по началу кадра.

Данное прерывание возникает при каждом определении SOF (сигнал начала кадра).
Оно может использоваться в качестве сигнала синхронизации изохронных конечных точек.
После сброса состояние данного бита необходимо сбросить UDP_ ICR.

ENDBUSRES - статус прерывания по окончанию сброса шины
0 - прерывание не возникало. 1 - возникло прерывание по окончанию сброса шины.

Данное прерывание возникает в конце последовательности сброса UDP.
USB-устройство должно подготовиться к приему запросов для конечной точки 0.
Хост инициирует перечисление, а затем выполняет конфигурацию.
После сброса состояние данного бита необходимо сбросить UDP_ ICR.

WAKEUP - статус прерывания по активизации(пробуждению) UDP
0 - прерывание не возникало. 1 - возникло прерывание по активизации шины (USB-хост отправил RESUME или RESET) произошедщего после последней очистки.
После сброса состояние данного бита необходимо сбросить UDP_ ICR.

4.5.2 UDP_ CSRx [x = 0..3] - Регистр управления и статуса конечной точки UDP
*AT91C_UDP_CSR =0xFFFB0030;
AT91C_BASE_UDP->UDP_ CSR[0]=0х0;
Тип доступа: чтение/запись

AT91SAM7S64

TXCOMP - генерация пакета DATA_IN с данными ранее записанными в DPR
Запись (сбрасывается программно):
0 - сброс флага, отмена прерывания. 1 - не оказывает влияния.
Чтение (устанавливается модулем USB):
0 - транзакция DATA_IN не подтверждена хостом.
1 - транзакция DATA_IN достигла хоста, на что получено подтверждение.

После установки данного флага в единичное состояние генерируется прерывание.
После инициации транзакции DATA_IN путем установки TXPKTRDY=1 программа ожидает подтверждение транзакции хостом, опрашивая состояние TXCOMP.
Если хост принял пакет, то выставляется TXCOMP=1, который программа должна сбросить.

RX_DATA_BK0 - прием банка данных 0
Запись (сбрасывается программно):
0 - уведомляет модуль USB, что данные считаны из банка 0 буфера FIFO. 1 - не оказывает влияния.
Чтение (устанавливается модулем USB):
0 - нет принятого пакета данных в банк 0 FIFO. 1 - пакет данных принят и сохранен в банке 0 FIFO.

Данный флаг генерирует прерывание до тех пор, пока он имеет единичное значение.
После программного опроса данного бита или генерации прерывания с его стороны необходимо выполнить передачу данных из буфера FIFO в память микроконтроллера.
Количество принятых байт отображается в поле RXBYTCENT.
Значения банка 0 FIFO считываются через регистр UDP_ FDRx.
Сразу по завершении передачи необходимо освободить банк 0 для использования модулем USB-устройства путем сброса бита RX_DATA_BK0.

RXSETUP - прием установочного пакета (SETUP)
Данный флаг генерирует прерывание до тех пор, пока он имеет единичное значение.
Чтение:
0 - нет данных. 1 - установочный пакет данных отправлен хостом и доступен в буфере FIFO.
Запись:
0 - данные считаны из буфера FIFO. 1 - не оказывает влияния.

Данный флаг используется для уведомления программы USB-устройства о том, что пакет SETUP был отправлен хостом и успешно принят устройством.
Программа USB-устройства может считать установочные данные из FIFO путем копирования регистра UDP_ FDRx в память микроконтроллера.
По завершении копирования RXSETUP необходимо сбросить программно.
Очередная транзакция не воспринимается до тех пор, пока установлен RXSETUP=1.

STALLSENT -прием подтверждения останова (конечные точки "Управление", "Поток, "Прерывание")/ ISOERROR (изохронные конечные точки)
Установкой STALLSENT завершается квитирование останова.
Чтение:
0 - хост не подтвердил останов. 1 - хост подтвердил останов.
Запись:
0 - сбрасывает флаг STALLSENT, сбрасывает прерывание. 1 - не оказывает влияния.

Данный флаг генерирует прерывание до тех пор, пока он имеет единичное значение.
Программный сброс данного флага является обязательным.
В противном случае, будет постоянно генерироваться прерывание.
В случае изохронной передачи данный бит имеет функцию ISOERROR и устанавливается, если обнаружена ошибка CRC.
Чтение:
0 - изохронной передаче не было ошибок. 1 - обнаружена CRC-ошибка; данные в FIF повреждены.
Запись:
0 - сбрасывает флаг ISOERROR, сбрасывает прерывание. 1 - не оказывает никакого влияния.

TXPKTRDY - готовность пакета для передачи
Чтение:
0 - данные могут быть помещены в FIFO. 1 - данные не могут быть помещены в FIFO.
Запись:
0 - не оказывает влияния. 1 - данные записаны в FIFO и готовы к отправке.

Данный флаг сбрасывается USB, а устанавливается программной.
Данный флаг используется для генерации транзакции DATA_IN (в направлении устройство-хост).
Программа проверяет возможность записи данных в FIFO оценивая состояния TXPKTRDY=0.
Передача в FIFO выполняется путем записи данных в регистр UDP_ FDRx.
Сразу после передачи данных в FIFO программа должна установить TXPKTRDY=1.
После этого можно начинать транзакцию USB.
TXCOMP =1 устанавливается сразу после приема данных хостом.

FORCESTALL - принудительный останов (used by Control, Bulk and Isochronous Endpoints)
Только запись:
0 - не оказывает никакого влияния. 1 - отправляет останов хосту. Конечные точки: на этапах "Данные" и "Статус" он индицирует о невозможности завершить запрос микроконтроллером.
Конечные точки: "Поток" и "Прерывание": уведомляет хост о том, что конечная точка остановлена.
После подтверждения хостом останова микроконтроллер уведомляется об этом через флаг STALLSENT=1 прерыванием.

RX_DATA_BK1 - прием банка DATA_1
(используется только с конечными точками, поддерживающие переключение банков памяти)
Запись (сбрасывается программно):
0 - данные считаны из банка 1 буфера FIFO. 1 - не оказывает влияния.
Чтение (устанавливается модулем USB):
0 - нет принятого . 1 - DATA_1 принят и сохранен в банке 1 буфера FIFO.

Данный флаг генерирует прерывание до тех пор, пока он имеет единичное значение.
После программного опроса данного бита или генерации прерывания с его стороны необходимо выполнить передачу данных из буфера FIFO в память микроконтроллера.
Количество принятых байт отображается в поле RXBYTCENT.
Значения банка 1 FIFO считываются через регистр UDP_ FDRx.
Сразу по завершении передачи необходимо освободить банк 1 RX_DATA_BK1=0.

DIR - направление передачи
(поддерживается только для конечных точек управления)
Чтение/запись
0 - разрешает транзакции DATA_OUT. 1 - разрешает транзакции DATA_IN.

Данный бит должен быть установлен до сброса UDP_ CSRx/RXSETUP по окончании этапа SETUP.
В соответствии с отправленных запросом в пакете установочных данных выполняется передача данных в направлении устройство-хост (DIR = 1) или хост-устройство (DIR = 0).
Нет необходимости проверять данный бит для реверсирования направления этапа "Статус".

EPTYPE[] - тип конечной точки
Чтение/запись

AT91SAM7S64

DTGLE - переключатель данных
Только чтение
0 - идентифицирует пакет данных 0 (DATA0).
1 - идентифицирует пакет данных 1 (DATA1).
См. раздел 8 "Universal Serial Bus Specification, Rev. 2.0", где приведена более детальная информация по определениям пакетов данных DATA0 и DATA1.
EPEDS - включение/отключение конечной точки
Чтение:
0 - конечная точка отключена.
1 - конечная точка включена.
Запись:
0 - отключение конечной точки.
1 - включение конечной точки.
RXBYTECNT[10:0] - количество байт, доступных в буфере FIFO
Только чтение.
После отправки хостом пакета данных USB-устройство сохраняет данные в буфере FIFO и уведомляет об этом микроконтроллер.
Микроконтроллер может считать данные из буфера FIFO путем чтения байт RXBYTECENT в регистре UDP_ FDRx.

4.5.3 Регистр данных FIFO модуля UDP

Наименование регистра: UDP_ FDRx [x = 0..3]
Тип доступа: чтение/запись

AT91SAM7S64

FIFO_DATA[7:0] - значение данных FIFO
Через данный регистр микроконтроллер может помешать или извлекать данные из буфера FIFO.
RXBYTECNT в соответствующем регистре UDP_CSRx - количество байт для чтения из FIFO (отправляется хостом).
Максимальное количество байт для записи зафиксировано максимальным размером пакета в дескрипторе стандартной конечной точки.
Оно не может быть больше размера физической памяти, выделенной для конечной точки.
Более детальная информация приведена в технических требованиях к шине USB версии 2.0.

4.6 Инициализация устройства USB. Нумерации шины.

Инициализация устройства USB или как говорят нумерация шины USB хостом, это процесс конфигурации устройства хостом при подключение его к шине USB.
Инициализация является линейным процессом, в котором устройство последовательно должно пройти через 5 своих состояний(см.п.3 рис.2):
Attached>> Powered>> Default>> Adress>> Configured

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

Запросы и дескрипторы стандартны, их структура и состав определены спецификацией USB.
Поэтому процедура инициализации одинакова для любых устройств.

Процесс инициализации устройства AT91SAM7S64 по состояниям:

Attached(Подключенное)
Мы обнаруживаем запитанное состояние по сигналу РА03=1, так как питание +5В всегда подано на 1 ножку порта USB.
После чего, мы включаем сигнал РА03=1, который подсоединяет нагрузочный резистор.

Хост обнаружил резистор на линии -D подтянутый к плюсу.
Поэтому он знает, что к порту подсоединилось устройство в режиме FS(12МГц).
Хаб разрешает подать на порт одну модульную нагрузку(100мА) для питания устройства при его конфигурации.
После чего устройство считается запитанным.

Powered(Запитаное)
Хаб запитывает присоединённое устройство одной модульной нагрузкой(100ма),и изменяет своё статусное состояния (чтобы хост обнаружил, что устройство запитано через хаб).
В этом состоянии устройство не должно отвечать на запросы хоста.
Хост обнаружив(по изменению статусного состояния хаба), что устройство запитано, подает сигнал RESET, который хаб передает на устройство в течении 10мс.
Получив сигнал сброса шины контроллер сбрасывает регистры и устанавливает флаг UDP_ISR_ENDBURSES=1 ,который говорит , что произошёл сброс шины.

Мы обнаружив флаг регистра UDP_ISR_ENDBURSES=1 делаем:
-сбросить конечные точки записав 1, а затем 0, в регистр UDP_RSTEP
-разрешаем работу точки 0 UDP_CSR0_EPEDS=1
-сбрасываем флаг прерывания UDP_ISR_ENDBURSES=1 в ноль.
Если мы будем использовать прерывание, то его нужно будет сбросить, через регистр сброса прерываний UDP_ICR_ENDBURSES=1.
При работе в цикле(без прерываний) этого делать ненужно.

После сброса прерывания устройство переходит в следующее состояние.

Default(Исходное) Теперь конечная точка 0 устройства может отвечать хосту по адресу=0.
Адрес=0 хост всегда использует для работы с подключаемым устройством, после успешного подключения устройства, ему будет присвоен свой адрес от 1..127 и оно не будет откликаться на адрес=0.
В этом состоянии хост читает дескриптор устройства и определяет максимальный размер буфера, который может поддерживать канал точки 0 (это FIFO= 8 байт).
После чего хост сможет послать команду установить адрес устройства.

Хост посылает устройству стандартный запрос GET_DESCRIPTOR (8 байт):
GET_DESCRIPTOR:
80 06 00 01 00 00 40 00
80 -тип запроса: стандартный, от устройства к хосту, получатель устройство
06 -код запроса: GET_DESCRIPTOR
00 -индекс дескриптора: 0
01 -тип дескриптора: дескриптор устройства
0000 -ID UNICODE языка, для строковых дескрипторов
4000 -длина макс. ответа в байтах: 0х0040=64 байта

В ответ устройство должно передать хосту 16 первых байт своего дескриптора устройства DEVIСE_DESCRIPTOR, двумя пакетами по 8 байт.
Хост изначально не знает длину дескриптора и макс. размер данных в точке 0, поэтому он всегда вначале читает только 2 пакета по 8 байт из DEVIСE_DESCRIPTOR.

DEVIСE_DESCRIPTOR(16 байт):
12 01 00 02 02 00 00 08
EB 03 19 61 00 01 00 01
12 -общая длина дескриптора(bLength): 0х12=18 байт
01 -тип дескриптора(bDescriptorType): дескриптор устройства
0002-номер спецификации USB в формате BCD(bcdUSB): 2.0
02 -код класса устройства(bDeviceClass):0х02- CDC устройство (виртуальный СОМ порт)
00 -код подкласса устройства(bDeviceSubClass):0
00 -код протокола устройства(bDeviceProtocol):0
08 -максимальный размер пакета данных для точки 0(bMaxPacketSize0): 8 байт
EB03 -ID производителя(idVendor): 0х03EB=1003(задан фондом USB)
1961 -ID продукта(idProduct): 0х6119 (Задан производителем)
0001 -Версия продукта в BCD формате(bcdDevice): 0х0001=1.0 (задан производителем)
00 - индекс строкового дескриптора производителя(iManufacturer):0
01 - индекс строкового дескриптора производителя(iProduct): 1

Как принять запрос:
Мы обнаруживаем этот запрос к нулевой точке по флагу UDP_ISR_EP0INT=1
Далее по анализу у регистра статуса нулевой точки UDP_CSR[0] определяем:
UDP_CSR[0]_RX_SETUP=1, что это запрос управления(SETUP)
UDP_CSR[0]_RXBYTECNT=8 видим, что получено 8 байт(DATA)
UDP_CSR[0]_DIR=0 видим, что байты получены от хоста.(DATA_OUT)

Мы читаем эти 8 байт последовательно из регистра UDP_FDR[0] в массив.
Сбрасываем прерывание SETUP UDP_CSR[0]_RX_SETUP=0.
Анализируем принятые 8 байтов и если они равны GET_DESCRIPTOR, то передаем два пакета DATA_IN по 8 байт, которые содержат дескриптор устройства.

Как передать пакеты DATA_IN:
Выставляем направление от устройства к хосту UDP_CSR[0]_DIR=1. (IN)
Ждем готовности хоста принять данные UDP_CSR[0]_TXPKTRDY=0.
Последовательно записываем в регистр UDP_FDR[0] 8 байт 12 01 00 02 02 00 00 08.
Выставляем флаг UDP_CSR[0]_TXPKTRDY=1, что данные в буфере FIFO.
Ждем, что хост прочитал данные UDP_CSR[0]_TXCOMP=1.
Сбрасываем UDP_CSR[0]_TXCOMP=0,мы поняли, что данные хостом получены.

Опять ждем готовности хоста принять данные UDP_CSR[0]_TXPKTRDY=0
Последовательно записываем в регистр UDP_FDR[0] 8 байт EB 03 19 61 00 01 00 01
Выставляем флаг UDP_CSR[0]_TXPKTRDY=1, что данные в буфере
Ждем, что хост прочитал данные UDP_CSR[0]_TXCOMP=1
Сбрасываем UDP_CSR[0]_TXCOMP=0, мы поняли что данные хостом получены.

Теперь хост получив начало дескриптора устройства посылает ему стандартный запрос SET_ADRESS установить адрес:

SET_ADRESS:
00 05 04 00 00 00 00 00
00 -тип запроса: стандартный, от хосту к устройству, получатель устройство
05 -код запроса: SET_ADRESS
0400 -адрес устройства: 0х0004=4
0000 -индекс: 0
0000 -макс.длина данных в ответе: 0

В третьем байте этого запроса содержится адрес, который присвоен устройству.
В данном случае адрес равен 4.

Как принять запрос:
Мы обнаруживаем этот запрос к нулевой точке по флагу UDP_ISR_EP0INT=1
Далее по анализу у регистра статуса UDP_CSR[0] определяем:
UDP_CSR[0]_RX_SETUP=1, что это запрос управления(SETUP)
UDP_CSR[0]_RXBYTECNT=8 видим, что получено 8 байт (DATA)
UDP_CSR[0]_DIR=0 видим, что байты получены от хоста.(DATA_OUT)

Мы читаем эти 8 байт последовательно из регистра UDP_FDR[0] в массив.
Сбрасываем прерывание SETUP UDP_CSR[0]_RX_SETUP=0.
Анализируем эти 8 байтов и если они равны SET_ADRESS, то мы должны подтвердить, что запрос получен, посылкой пустого пакета DATA_IN.

Как послать пустой пакет DATA_IN:
Выставляем направление от устройства к хосту UDP_CSR[0]_DIR=1 (IN)
Ждем готовности хоста принять данные UDP_CSR[0]_TXPKTRDY=0
Ничего не пишем в регистр UDP_FDR[0]
Выставляем флаг UDP_CSR[0]_TXPKTRDY=1, что данные в буфере
Ждем, что хост прочитал данные UDP_CSR[0]_TXCOMP=1.
Сбрасываем UDP_CSR[0]_TXCOMP=0, мы поняли, что данные хостом получены.

Теперь мы устанавливаем полученный адрес устройства в регистр адреса:
UDP_FADDR_FEN=1-разрешаем функционирование конечных точек.
UDP_FADDR_FADD=4 -текущий адрес устройства.

После этого мы выставляем в глобальном регистре состояния UDP:
UDP_GLB_STAT_FADDEN=1 -устройство адресовано.

Теперь наше устройство находиться в состоянии ADRESS и к нему можно обратиться по адресу 4.

Address(Адресовано)
Устройство имеет свой адрес, это видно по его регистрам:
UDP_FADDR_FADD=4 -текущий адрес устройства.
UDP_GLB_STAT_FADDEN=1 -устройство адресовано.

Теперь оно может откликаться на свой адрес, при этом канал по умолчанию (адрес=0) продолжает действовать.

Далее хост запрашивает ряд стандартных запросов:

Запрос GET_DESCRIPTOR_DEVICE получить дескриптор устройства в 18 байт.

GET_DESCRIPTOR_DEVICE:
80 06 00 01 00 00 12 00
80 -тип запроса: стандартный, от устройства к хосту, получатель устройство
06 -код запроса: GET_DESCRIPTOR
00 -индекс дескриптора: 0
01 -тип дескриптора: дескриптор устройства
0000 -ID UNICODE языка, для строковых дескрипторов
1200 -длина данных в ответе: 0х0012=18 байт

Теперь хост знает полную длину дескриптора устройства.
Длину дескриптора он узнал ранее, при первом запросе дескриптора устройств.
Поэтому теперь он запросил весь дескриптор устройства (18 байт).

DEVICE_DESCRIPTOR(18 байт)
12 01 00 02 02 00 00 08
EB 03 19 61 00 01 00 01
00 01
12 -общая длина дескриптора(bLength): 0х12=18 байт
01 -тип дескриптора(bDescriptorType): дескриптор устройства
0002-номер спецификации USB в формате BCD(bcdUSB): 2.0
02 -код класса устройства(bDeviceClass):0х02- CDC устройство (виртуальный СОМ порт)
00 -код подкласса устройства(bDeviceSubClass):0 -зарезервирован
00 -код протокола устройства(bDeviceProtocol):0
08 -максимальный размер пакета данных для точки 0(bMaxPacketSize0): 8 байт
EB03 -ID производителя(idVendor): 0х03EB=1003(задан фондом USB)
1961 -ID продукта(idProduct): 0х6119 (Задан производителем)
0001 -Версия продукта в BCD формате(bcdDevice): 0х0001=1.0 (задан производителем)
00 - индекс строкового дескриптора производителя(iManufacturer):0
01 - индекс строкового дескриптора производителя(iProduct): 0
00 - индекс строк. дескр. серийного номера устройства(iSerialNumber): 0
01 - количество возможных конфигураций (bNumConfiguration): 1

В ответе полный дескриптор устройства , который равен 18 байтам
Передаётся всё аналогично как описано в п.3

Далее хост запрашивает начало дескриптора конфигурации 9 байт, чтобы узнать полную длину всех дескрипторов входящих в конфигурацию данного устройства.

GET_DESCRIPTOR_CONFIGURATION:
80 06 00 02 00 00 09 00
80 -тип запроса: стандартный, от устройства к хосту, получатель устройство
06 -код запроса: GET_DESCRIPTOR
00 -индекс дескриптора: 0
02 -тип дескриптора: дескриптор конфигурации
0000 -ID UNICODE языка, для строковых дескрипторов
0900 -длина данных в ответе: 0х0009=9 байт

В ответ посылаем 9 начальных байт дескриптора конфигурации, которые содержат информацию об общей длине конфигурации устройства.

CONFIGURATION_DESCRIPTOR (9 байт):
09 02 43 00 02 01 00 C0
32
09 -общая длина дескриптора(bLength): 0х09=9 байт
02 -тип дескриптора(bDescriptorType): дескриптор конфигурации
4300 -размер полной конфигурации усройства (wTotalLength): 0х0043=67 байт
02 -число интерфейсов поддерживаемых этой конфигурацией(bNumInterfaces): 2
01 -номер конфигурации при запросе SE_CONFIGURATION(bConfigurationValue): 1
00 -индекс строкового дескриптора этой конфигурации(iConfiguration): 0
C0 -битовое поле свойств(bmAttributes): D7=1 устройство питается от шины USB; D6=1 устройство имеет независимое питание
32 -макс. ток потребления(bMaxPower): 0х32=50 (50*2мА=100мА)

Прочитав стандартный дескриптор конфигурации CONFIGURATION_DESCRIPTOR(9 байт), хост запрашивает полную конфигурацию устройства 67 байт.
Которая для данного устройства включает в себя набор дескрипторов:

CONFIGURATION_DESCRIPTOR0 -дескриптор конфигурации 0 (9 байт).
INTERFACE_DESCRIPTOR0 -дескриптор интерфейса 0 (9 байт)
FUNCTIONAL_DESCRIPTOR0 -дескриптор функции 0 (5 байт)
FUNCTIONAL_DESCRIPTOR1 -дескриптор функции 1 (5 байт)
FUNCTIONAL_DESCRIPTOR2 -дескриптор функции 2 (4 байта)
FUNCTIONAL_DESCRIPTOR3 -дескриптор функции 3 (5 байт)
ENDPOINT_DESCRIPTOR0 -дескриптор конечной точки_0 (7 байт)
INTERFACE_DESCRIPTOR1 -дескриптор интерфейса 1 (9 байт)
ENDPOINT_DESCRIPTOR1 -дескриптор конечной точки 1 (7 байт)
ENDPOINT_DESCRIPTOR2 -дескриптор конечной точки 2 (7 байт)

GET_DESCRIPTOR_CONFIGURATION:
80 06 00 02 00 00 FF 00
80 -тип запроса: стандартный, от устройства к хосту, получатель устройство
06 -код запроса: GET_DESCRIPTOR
00 -индекс дескриптора: 0
02 -тип дескриптора: дескриптор конфигурации
0000 -ID UNICODE языка, для строковых дескрипторов
FF00 - длина данных в ответе: 0х00FF=255 байт

В ответ надо послать 67 байт, которые включают в себя 10 дескрипторов.
Эти дескрипторы передаются общим массивом данных, которое устройство должно выдать на запрос полной конфигурации (это когда длина ответа в запросе 0хFF).
То есть максимальная длина конфигурации не может превышать 255 байт.

CONFIGURATION_DESCRIPTOR(67 байт):
09 02 43 00 02 01 00 C0
32 09 04 00 00 01 02 02
00 00 05 24 00 10 01 05
24 01 01 00 04 24 02 02
05 24 06 00 01 07 05 83
03 40 00 0A 09 04 01 00
02 0A 00 00 00 07 05 01
02 40 00 00 07 05 82 02
40 00 00

CONFIGURATION_DESCRIPTOR0:
09 -общая длина дескриптора(bLength): 0х09=9 байт
02 -тип дескриптора(bDescriptorType): дескриптор конфигурации
4300 -размер полной конфигурации усройства (wTotalLength): 0х0043=67 байт
02 -число интерфейсов поддерживаемых этой конфигурацией(bNumInterfaces): 2
01 -номер конфигурации при запросе SET_CONFIGURATION(bConfigurationValue): 1
00 -индекс строкового дескриптора этой конфигурации(iConfiguration): 0
C0 -битовое поле свойств(bmAttributes): D7=1 устройство питается от шины USB<; D6=1 устройство имеет независимое питание
32 -макс. ток потребления(bMaxPower): 0х32=50 (50*2мА=100мА)

INTERFACE_DESCRIPTOR0:
09 -общая длина дескриптора(bLength): 0х09=9 байт
04 -тип дескриптора(bDescriptorType):4 - дескриптор интерфейса
00 -номер интерфейса(bInterfaceNumber):0 -интерфейс0
00 -номер альтернативного интерфейса(bAlternateSetting): 0 -интерфейс0
01 -количество конечных точек интерфейса(bNumEndPoints): 1
02 -класс интерфейса(bInterfaceClass): 2 -CDC Control
02 -подкласс интерфейса(bInterfaceSubClass):2 -Abstract Control Model interface
00 -протокол интерфейса(bInterfaceProtocol): 0 -номер протокола интерфейса0
00 -индекс строкового дескриптора интерфеса(iInterface):0

FUNCTIONAL_DESCRIPTOR0:
05 -общая длина дескриптора(bLength): 0х05=5 байт
24 -тип дескриптора(bDescriptorType):0x24 - дескриптор интерфейса функции
00 -подтип дескриптора(bDescriptorSubtype):0 -описание заголовка функции
1001 -версия релиза функции в BCD формате(bcdCDC): -0x0110=1.10

FUNCTIONAL_DESCRIPTOR1:
05 -общая длина дескриптора(bLength): 0х05=5 байт
24 -тип дескриптора(bDescriptorType):0x24 - дескриптор интерфейса функции
01 -подтип дескриптора(bDescriptorSubtype):1 - вызов функции
01 -номер последовательного вызова: 1
00 -не ассоциирован с интерфейсом.

FUNCTIONAL_DESCRIPTOR2:
04 -общая длина дескриптора(bLength): 0х04=4 байт
24 -тип дескриптора(bDescriptorType):0x24 - дескриптор интерфейса функции
02 -подтип дескриптора(bDescriptorSubtype):2 -абстрактное управление функцией
02 -линия управления контролем: 2

FUNCTIONAL_DESCRIPTOR3:
05 -общая длина дескриптора(bLength): 0х05=5 байт
24 -тип дескриптора(bDescriptorType):0x24 - дескриптор интерфейса функции
06 -подтип дескриптора(bDescriptorSubtype):1 - совместная работа функции
00 -номер ведущего интерфейса: 0
01 -номер ведомого итерфейса:1

ENDPOINT_DESCRIPTOR0:
07 - общая длина дескриптора(bLength): 0х07=7 байт
05 -тип дескриптора(bDescriptorType):5 - дескриптор конечной точки
83 -адрес и направление(bmEndpointAddress): адрес=3 направление=IN
03 -тип передачи(bmAttributes): 03 -прерывание
4000 -макс. размер пакета(wMaxPacketSize): 0x0040=64 байта
0A -интервал опроса в мс(bInterval):0x0A=10ms

INTERFACE_DESCRIPTOR1:
09 -общая длина дескриптора(bLength): 0х09=9 байт
04 -тип дескриптора(bDescriptorType):4 - дескриптор интерфейса
01 -номер интерфейса(bInterfaceNumber):0 -интерфейс1
00 -номер альтернативного интерфейса(bAlternateSetting): 0 -интерфейс0
02 -количество конечных точек интерфейса(bNumEndPoints): 2
0A -класс интерфейса(bInterfaceClass): 2 -CDC Data
00 -подкласс интерфейса(bInterfaceSubClass):0
00 -протокол интерфейса(bInterfaceProtocol): 0
00 -индекс строкового дескриптора интерфеса(iInterface):0

ENDPOINT_DESCRIPTOR1:
07 - общая длина дескриптора(bLength): 0х07=7 байт
05 -тип дескриптора(bDescriptorType):5 - дескриптор конечной точки
01 -адрес и направление(bmEndpointAddress): адрес=1 направление=OUT
02 -тип передачи(bmAttributes): 02 -Bulk (передача данных)
4000 -макс. размер пакета(wMaxPacketSize): 0x0040=64 байта
00 -интервал опроса в мс(bInterval):0 -неопределено

ENDPOINT_DESCRIPTOR2:
07 - общая длина дескриптора(bLength): 0х07=7 байт
05 -тип дескриптора(bDescriptorType):5 - дескриптор конечной точки
82 -адрес и направление(bmEndpointAddress): адрес=2 направление=IN
02 -тип передачи(bmAttributes): 02 -Bulk (передача данных)
4000 -макс. размер пакета(wMaxPacketSize): 0x0040=64 байта
00 -интервал опроса в мс(bInterval):0 -неопределено

Хост получил полную конфигурацию устройства.
Опишем эту конфигурацию:
Устройство имеет два интерфейса 0 и 1.
Первый интерфейс имеет 4 функции для управления CDC драйвером.
Этот интерфейс работает через конечную точку 3 по прерыванию.
Конечная точка 3 настроена на приём данных хостом(IN).
Второй интерфейс работает через две конечные точки.
Конечная точка 1 настроена на приём данных от хоста(OUT).
Конечная точка 2 настроена на передачу данных к хосту(IN).
Макс. размер пакетов для конечных точек 64 байта.

После получения всех дескрипторов конфигурации хост начинает запрашивать строковые дескрипторы.
Строковые дескрипторы предназначены для людей.
То есть это текстовая информация, которая будет выводиться в ОС.

Запрос GET_DESCRIPTOR_STRING0 стандартного строкового дескриптора 0.

GET_DESCRIPTOR_STRING0:
80 06 00 03 00 00 FF 00
80 -тип запроса: стандартный, от устройства к хосту, получатель устройство
06 -код запроса: GET_DESCRIPTOR
00 -индекс дескриптора: 0
03 -тип дескриптора:строковый дескриптор
0000 -ID UNICODE языка, для строковых дескрипторов
FF00 - длина данных в ответе: 0х00FF=255 байт

В ответ передаём STRING_DESCRIPTOR0, который содержик код языка используемый в строковых дескрипторах.

STRING_DESCRIPTOR0:
04 03 09 04
В ответе:
04 -общая длина дескриптора(bLength): 0х09=9 байт
03 -тип дескриптора(bDescriptorType): строковый дескриптор
0904 -ID языка в UNOCODE: 0х0409=1033

Далее хост запрашивает строковый дескриптор 1, содержащий название устройства данное производителем.

GET_DESCRIPTOR_STRING1:
80 06 01 03 09 04 FF 00
80 -тип запроса: стандартный, от устройства к хосту, получатель устройство
06 -код запроса: GET_DESCRIPTOR
01 -индекс дескриптора: 1
03 -тип дескриптора:строковый дескриптор
0904 -ID UNICODE языка: 0х0409
FF00 -стандартный(начальный) запрос

В ответ мы послылаем строковый дескриптор1, который содержит название устройства.

STRING_DESCRIPTOR1:
1C 03 41 00 54 00 39 00
31 00 55 00 53 00 42 00
53 00 65 00 72 00 69 00
61 00 6C 00
1С -общая длина дескриптора(bLength): 0х1С=28 байт
03 -тип дескриптора(bDescriptorType): 03 -строковый дескриптор
41..00 -надпись в UNICODE: "AT91USBSerial"

Далее хост начинает повторно запрашивать ранее полученные дескрипторы.

GET_DESCRIPTOR_STRING0:
80 06 00 03 00 00 FF 00
04 03 09 04

GET_DESCRIPTOR_STRING1:
80 06 01 03 09 04 FF 00
1C 03 41 00 54 00 39 00
31 00 55 00 53 00 42 00
53 00 65 00 72 00 69 00
61 00 6C 00

GET_DESCRIPTOR_DEVICE:
80 06 00 01 00 00 12 00
12 01 00 02 02 00 00 08
EB 03 19 61 00 01 00 01
00 01

GET_DESCRIPTOR_CONFIGURATION:
80 06 00 02 00 00 09 01
09 02 43 00 02 01 00 C0
32 09 04 00 00 01 02 02
00 00 05 24 00 10 01 05
24 01 01 00 04 24 02 02
05 24 06 00 01 07 05 83
03 40 00 0A 09 04 01 00
02 0A 00 00 00 07 05 01
02 40 00 00 07 05 82 02
40 00 00

В запросе GET_DESCRIPTOR_CONFIGURATION длина ответа 0х0109=265 байт.
Наверно существуют устройства, у которых конфигурация более 255 байт.
И повторение запросов сделали для поиска таких устройств.

После успешного чтения дескрипторов хост посылает запрос SET_CONFIGURATION.
По этой команде устройство должно перейти в состояние Configured.

SET_CONFIGURATION
00 09 01 00 00 00 00 00
00 -тип запроса: стандартный, от хосту к устройству, получатель устройство
09 -код запроса: SET_CONFIGURATION
0100 -флаг конфигурации: 0х0001 -устройство сконфигурировано
0000 -индекс: 0
0000 -длина ответа: 0 байт

Как принять запрос:
Мы обнаруживаем этот запрос к нулевой точке по флагу UDP_ISR_EP0INT=1
Далее по анализу у регистра статуса UDP_CSR[0] определяем:
UDP_CSR[0]_RX_SETUP=1, что это запрос управления(SETUP)
UDP_CSR[0]_RXBYTECNT=8 видим, что получено 8 байт (DATA)
UDP_CSR[0]_DIR=0 видим, что байты получены от хоста.(DATA_OUT)

Мы читаем эти 8 байт последовательно из регистра UDP_FDR[0] в массив.
UDP_CSR[0]_RX_SETUP=0, сбрасываем прерывание SETUP
Анализируем эти 8 байтов и если они равны SET_CONFIGURATION, то мы должны подтвердить, что запрос получен, посылкой пустого пакета DATAIN.

Как послать подтверждение(квитирование) пустым DATAIN:
Выставляем направление от устройства к хосту UDP_CSR[0]_DIR=1.(IN)
Ждем готовности хоста принять данные UDP_CSR[0]_TXPKTRDY=0
Ничего не пишем в регистр UDP_FDR[0]
Выставляем флаг UDP_CSR[0]_TXPKTRDY=1, что данные в буфере

Теперь мы должны выставить конфигурацию конечных точек и разрешить их работу:

Конечная точка 1 -разрешена, тип передачи BULK :
UDP_CSR[1]=0x00008200

Конечная точка 2 -разрешена, тип передачи BULK
UDP_CSR[2]=0x00008600

Конечная точка 2 -разрешена, тип передачи Interrupt
UDP_CSR[3]=0x00008700

Далее указываем состояние нашего устройства как сконфигурированное:

UDP_GLB_STAT_CONFIG=1 -флаг, что устройство сконфигурированно

Ждем, что хост прочитал данные UDP_CSR[0]_TXCOMP=1.
Сбрасываем UDP_CSR[0]_TXCOMP=0, мы поняли, что данные хостом получены.

После этого устройство переходит в состояние сконфигурированное.

Configured(Сконфигурированное)
После того как устройство получило свой адрес, хост конфигурирует все функции устройства(конечные точки).
Определяя тип передачи, ширину канала для каждой точки и количество модульных нагрузок(1 мод. нагрузка=100мА, максимально можно до 5 нагрузок).
Данные о настройке устройства записываются в байт конфигурации устройства. После этого устройство считается подключенным к сети.
Оно уже не будет отвечать на адрес=0, который используется только при подключении устройства, а будет отвечать только на присвоенный ему адрес.
Если по каким-либо причинам хост не сможет сконфигурировать устройство, то он даёт команду хабу отключить данный порт от сети.

После того, как устройство сконфигурировано, хост присылает запрос на настройку параметров виртуального порта (CDC драйвера).

GET_LINE_CODING:
A1 21 00 00 00 00 07 00
A1 -тип запроса: класс, от устройства к хосту, получатель интерфейс
21 -код запроса: GET_LINE_CODING
0000 -всегда 0
0000 -номер интерфейса: 0
0700 -длина ответа: 0х0007=7 байт

В ответ мы должны послать хосту данные о настройках порта 115200,n,8,1

DATA_IN:
00 C2 01 00 00 00 08
00С20100 -скорость обмена(dwDTERate): 0х0001С200=115200 бит/сек
00 -интервал стоп-бита(bCharFormat): 0x00 - 1 STOP bit (1=1.5;2=2)
00 - паритет(bParityType): 0х00 -None (1=Odd;2=Even;3=Mark;4=Space)
08 -длина символа(bDataBits): 0x08=8 байт (5;6;7;8;16)

После получения данных о настройке виртуального(CDC) порта хост
посылает запрос SET_CONTROL_LINE_STATE, устанавливающий сигналы RTS и DTR

SET_CONTROL_LINE_STATE:
21 22 00 00 00 00 00 00
21 -тип запроса: стандарт, от хоста к устройству, получатель интерфейс
22 -код запроса: SET_CONTROL_LINE_STATE
0000 -битовое поле управление сигналом:D0=0 сигнал DTR=0; D1=0 сигнал RTS=0 ;D2..D15 =0 резерв
0000 -номер интерфейса: 0
0000 -длина ответа: всегда 0

Как принять запрос:
Мы обнаруживаем этот запрос к нулевой точке по флагу UDP_ISR_EP0INT=1
Далее по анализу у регистра статуса UDP_CSR[0] определяем:
UDP_CSR[0]_RX_SETUP=1, что это запрос управления(SETUP)
UDP_CSR[0]_RXBYTECNT=8 видим, что получено 8 байт
UDP_CSR[0]_DIR=0 видим, что байты получены от хоста

Мы читаем эти 8 байт последовательно из регистра UDP_FDR[0] в массив.
UDP_CSR[0]_RX_SETUP=0, сбрасываем прерывание SETUP.
Анализируем эти 8 байтов и если они равны SET_CONTROL_LINE_STATE, то мы должны подтвердить, что запрос получен, посылкой пустого пакета DATAIN.

Как послать подтверждение(квитирование) пустым DATAIN:
Выставляем направление от устройства к хосту UDP_CSR[0]_DIR=1.
Ждем готовности хоста принять данные UDP_CSR[0]_TXPKTRDY=0
Ничего не пишем в регистр UDP_FDR[0]
Выставляем флаг UDP_CSR[0]_TXPKTRDY=1, что данные в буфере
Ждем, что хост прочитал данные UDP_CSR[0]_TXCOMP=1.
Сбрасываем UDP_CSR[0]_TXCOMP=0, мы поняли, что данные хостом получены.

После этого в диспетчере устройств мы увидим виртуальный СОМ порт с названием:
"AT91 USB to Serial Converter (COMx)"

Если драйвер устройства не установлен, то нужно подсунуть ОС файл 6119.inf
Вот текст этого файла, его можно написать в блокноте:

-----------------------------------------------------------------------------------
; $Id: 6119.inf,v 1.1.2.1 2006/12/05 08:33:25 danielru Exp $

[Version]                                                       ; Version section
Signature="$Chicago$"                                           ; All Windows versions
Class=Ports                                                     ; This is a serial port driver
ClassGuid={4D36E978-E325-11CE-BFC1-08002BE10318}                ; Associated GUID
Provider=%ATMEL%                                                ; Driver is provided by ATMEL
DriverVer=09/12/2006,1.1.1.5                                    ; Driver version 1.1.1.5 published on 23 February 2007

[DestinationDirs]                                               ; DestinationDirs section
DefaultDestDir=12                                               ; Default install directory is \drivers or \IOSubSys

[Manufacturer]                                                  ; Manufacturer section
%ATMEL%=AtmelMfg                                                ; Only one manufacturer (ATMEL), models section is named
          		                                                      	; AtmelMfg

[AtmelMfg]                                                      ; Models section corresponding to ATMEL
%USBtoSerialConverter%=USBtoSer.Install,USB\VID_03EB&PID_6119   ; Identifies a device with ATMEL Vendor ID (03EBh) and
                                                                		; Product ID equal to 6119h. Corresponding Install section
                                                                		; is named USBtoSer.Install

[USBtoSer.Install]                                              ; Install section
include=mdmcpq.inf
CopyFiles=FakeModemCopyFileSection
AddReg=USBtoSer.AddReg                                          ; Registry keys to add are listed in USBtoSer.AddReg

[USBtoSer.AddReg]                                               ; AddReg section
HKR,,DevLoader,,*ntkern                                         ;
HKR,,NTMPDriver,,usbser.sys
HKR,,EnumPropPages32,,"MsPorts.dll,SerialPortPropPageProvider"

[USBtoSer.Install.Services]                                     ; Services section
AddService=usbser,0x00000002,USBtoSer.AddService                ; Assign usbser as the PnP driver for the device

[USBtoSer.AddService]                                           ; Service install section
DisplayName=%USBSer%                                            ; Name of the serial driver
ServiceType=1                                                   ; Service kernel driver
StartType=3                                                     ; Driver is started by the PnP manager
ErrorControl=1                                                  ; Warn about errors
ServiceBinary=%12%\usbser.sys                                   ; Driver filename

[Strings]                                                       ; Strings section
ATMEL="ATMEL Corp."                                             ; String value for the ATMEL symbol
USBtoSerialConverter="AT91 USB to Serial Converter"             ; String value for the USBtoSerialConverter symbol
USBSer="USB Serial Driver"                                      ; String value for the USBSer symbol
--------------------------------------------------------------------------------------

OC имеет стандартный драйвер CDC, поэтому загружать его не надо, достаточно просто загрузить настройки этого драйвера.

Например, если вы хотите изменить имя , которое будет отражаться в диспетчере оборудования, то можете заменить параметр этого файла:
USBtoSerialConverter="AT91 USB to Serial Converter" на имя своего прибора.

4.6. Инициализация драйвера CDC.

После того как была проведена инициализация устройства и оно было сконфигурировано,вы можете присоединится к виртуальному СОМ порту с помощью любой программы.
При этом хост выдаст несколько запросов для инициализации драйвера CDC.

Драйвер CDC запрашивает четыре раза подряд настройки порта, которые у нас установлены в устройстве.
Обработку этого запроса мы уже рассмотрели выше.
В ответ мы посылаем настройки виртуального СОМ порта 115200,n,8,1

GET_LINE_CODING:
A1 21 00 00 00 00 07 00
00 C2 01 00 00 00 08

GET_LINE_CODING:
A1 21 00 00 00 00 07 00
00 C2 01 00 00 00 08

GET_LINE_CODING:
A1 21 00 00 00 00 07 00
00 C2 01 00 00 00 08

GET_LINE_CODING:
A1 21 00 00 00 00 07 00
00 C2 01 00 00 00 08

Далее драйвер CDC посылает запрос установить параметры порта в устройстве.
И следом посылает пакет DATA_OUT с настройками порта.

SET_LINE_CODING:
21 20 00 00 00 00 07 00
21 -тип запроса: класс, от хоста к устройству, получатель интерфейс
20 -код запроса: SET_LINE_CODING
0000 -всегда 0
0000 -номер интерфейса: 0
0700 -длина ответа: 0х0007=7 байт

DATA_OUT:
00 C2 01 00 00 00 08

Как принять запрос:
Мы обнаруживаем этот запрос к нулевой точке по флагу UDP_ISR_EP0INT=1
Далее по анализу у регистра статуса UDP_CSR[0] определяем:
UDP_CSR[0]_RX_SETUP=1, что это запрос управления(SETUP)
UDP_CSR[0]_RXBYTECNT=8 видим, что получено 8 байт
UDP_CSR[0]_DIR=1 видим, что байты получены от хоста.

Мы читаем эти 8 байт последовательно из регистра UDP_FDR[0] в массив.
UDP_CSR[0]_RX_SETUP=0, сбрасываем прерывание SETUP
Анализируем эти 8 байтов и если они равны SET_LINE_CODING, то мы должны подтвердить, что запрос получен, посылкой пустого пакета DATAIN.

Как послать подтверждение(квитирование) пустым DATAIN:
Выставляем направление от устройства к хосту UDP_CSR[0]_DIR=1(IN).
Ждем готовности хоста принять данные UDP_CSR[0]_TXPKTRDY=0
Ничего не пишем в регистр UDP_FDR[0]
Выставляем флаг UDP_CSR[0]_TXPKTRDY=1, что данные в буфере
Ждем, что хост прочитал данные UDP_CSR[0]_TXCOMP=1.
Сбрасываем UDP_CSR[0]_TXCOMP=0, мы поняли, что данные хостом получены.

Как принять от хоста данные DATA_OUT:
Мы обнаруживаем этот запрос к нулевой точке по флагу UDP_ISR_EP0INT=1
Далее по анализу у регистра статуса UDP_CSR[0] определяем:
UDP_CSR[0]_RX_DATA_BK0=1, в буфере есть данные от хоста (DATA_OUT)
UDP_CSR[0]_RXBYTECNT=7 видим, что получено 7 байт.
Сбрасываем прерывание UDP_CSR[0]_RX_DATA_BK0=0.

Далее читаем эти 7 байт последовательно из регистра UDP_FDR[0] в массив.
Меняем настройки порта в устройстве если нужно.
Далее надо подтвердить, что данные получены, посылкой пустого пакета DATA_OUT.

Как послать подтверждение(квитирование) пустым DATA_OUT:
Выставляем направление от устройства к хосту UDP_CSR[0]_DIR=0(OUT).
Ждем готовности хоста принять данные UDP_CSR[0]_TXPKTRDY=0
Ничего не пишем в регистр UDP_FDR[0]
Выставляем флаг UDP_CSR[0]_TXPKTRDY=1, что данные в буфере
Ждем, что хост прочитал данные UDP_CSR[0]_TXCOMP=1.
Сбрасываем UDP_CSR[0]_TXCOMP=0, мы поняли, что данные хостом получены.

Далее CDC проверяет, что данные установлены правильно, посылая запрос прочитать данные порта.

GET_LINE_CODING:
A1 21 00 00 00 00 07 00
00 C2 01 00 00 00 08

Далее CDC посылает запрос установить испольпользование сигналов управления обменом.
Устанавливает сигналы RTS=0 DTR=1.

SET_CONTROL_LINE_STATE:
21 22 01 00 00 00 00 00

Далее драйвер CDC ещё раз посылает запрос установить параметры порта в устройстве.

SET_LINE_CODING:
21 20 00 00 00 00 07 00
00 C2 01 00 00 00 08

И снова проверяет их правильную установку.

GET_LINE_CODING:
A1 21 00 00 00 00 07 00
00 C2 01 00 00 00 08

После этих манипуляций можно начинать передавать и принимать данные через виртуальный порт.

4.8 Передача данных через виртуальный СОМ порт.

Настройка порта происходила по интерфейсу 0, через конечную точку 0.
Передача пользовательских данных происходит по интерфейсу 1, через конечные точки 1 и 2.

Конечная точка 1 настроена на приём данных от хоста, тип данных BULK.
То есть через эту точку мы будем получать данные от программы на ПК.

Конечная точка 2 настроена на передачу данных к хосту, тип BULK.
То есть через эту точку мы будем передавать данные для программы на ПК.

Как принять данные DATA_OUT от ПК:
Ждём флага в регистре прерывания для конечной точки 1 UDP_ISR[1]_EP1INT=1.
Считываем регистр UDP_CSR[1], чтобы определить причину прерывания.
Если UDP_CSR[1]_RX_DATA_BK0=1 или UDP_CSR[1]_RX_DATA_BK1=1, говорит о том, что хост прислал данные и их можно считывать из буфера точки 1.
Определяем количество принятых байт прочитав регистр UDP_CSR[1]_RXBYTECNT
Последовательно считываем это количество байтов в массив из буферного регистра первой точки UDP_FDR[1].
После этого подтверждаем принятие байтов от хоста посылкой ему пустого пакета DATA_OUT.

Как послать подтверждение(квитирование) пустым DATA_OUT:
Выставляем направление от устройства к хосту UDP_CSR[0]_DIR=0(OUT).
Ждем готовности хоста принять данные UDP_CSR[0]_TXPKTRDY=0
Ничего не пишем в регистр UDP_FDR[0]
Выставляем флаг UDP_CSR[0]_TXPKTRDY=1, что данные в буфере
Ждем, что хост прочитал данные UDP_CSR[0]_TXCOMP=1.
Сбрасываем UDP_CSR[0]_TXCOMP=0, мы поняли, что данные хостом получены.

Как отослать данные DATA_IN на ПК:
Выставляем направление к хосту UDP_CSR[2]_DIR=1
Ждем сигнала готовности хоста принять данные UDP_CSR[2]_TXPKTRDY=0.
Записываем данные в буфер UDP_FDR[2] не более 64 байт.
Выставляем флаг, что данные загружены в буфер UDP_CSR[2]_TXPKTRDY=1.
Ждем, что хост прочитал данные UDP_CSR[0]_TXCOMP=1.
Сбрасываем UDP_CSR[0]_TXCOMP=0, мы поняли, что данные хостом получены.

4.9 Закрытие виртуального СОМ порта.
После того как программа на ПК освободит виртуальный СОМ порт, хост посылает запрос на установку состояний линий управления обменом.
Запрещает использовать сигнал DTR и RTS.

SET_CONTROL_LINE_STATE:
21 22 00 00 00 00 00 00

SET_CONTROL_LINE_STATE:
21 22 00 00 00 00 00 00

Источники информации:

1. Universal Serial Bus. Specification. Revision 1.0 January 15, 1996

Compaq, Digital Equipment Corporation, IBM PC Company, Intel, Microsoft, NEC, Northern Telecom

2.Universal Serial Bus. Specification. Revision 1.1 September 23, 1998

Compaq, Intel, Microsoft, NEC

Назад Главная

USBUniversal Serial Bus SpecificationУниверсальная последовательная шина