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

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

Этапы эволюции последовательного порта ПК:

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 Историческая справка.

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

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

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


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



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

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

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

Каждая спецификация USB с версии 1.0 до 3.0 содержит большое количество технической документации.

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

USB 1.0 - 268 стр.

USB 1.1 - 311 стр.

USB 2.0 - 622 стр.

USB 3.0 - 482 стр.

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

Содержание глав спецификаций USB 1.0-2.0:

Глава 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 в большей части коррелированы с версиями USB 1.0-2.0.

Содержания измененных и добавленных глав для 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]

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

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

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

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

3.5.1 Пакет (Packet).

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

3.5.3 Кадр (Frame).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.

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) связи.


Банк- это буфер памяти(массив), очередь 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 разъёму


МК имеет два отдельных выхода 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


Всего устройство 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 отображает в регистрах, в виде флагов.
Вам остаётся только загружать данные, которые затребовал хост в буфер контрольной точки и выставлять флаги готовности данных.



Основных регистров, которые нам предстоит использовать три: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; -значение по умолчанию



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;
Тип доступа: чтение/запись



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[] - тип конечной точки
Чтение/запись



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]
Тип доступа: чтение/запись



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

---

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