Желание создать свое USB-устройство рано или поздно овладевает умами многих радиолюбителей, увлекающихся программированием микроконтроллеров. Обычно USB-устройство это микроконтроллер (далее МК) с записанной в него программой (firmware), и с ней обычно взаимодействует программа на компьютере (ПО хоста), хотя иногда с устройством напрямую работает операционная система, если это USB HID мышь или клавиатура.

Примечание: расшифровку многих непонятных сокращений и терминов USB см. в статье [7], также обращайтесь к разделу "Словарик" в конце статьи. Для некоторых терминов оставлены их английские обозначения – для упрощения описания.

[Общие замечания по аппаратуре и программному обеспечению]

Разработанное устройство относится к классу USB HID. Это популярный класс у начинающих разработчиков, потому что позволяет быстро получить работоспособное решение без необходимости написания драйвера (для данного класса устройств в WINDOWS уже имеется стандартный набор драйверов, может потребоваться – и то не всегда – только файл описания *.inf устройства).

ПО хоста, написанное для этого USB HID устройства, просто демонстрирует сам процесс обмена данными через конечные точки USB. В целях упрощения описания устройство не выполняет каких-либо сложных функций. Таким образом, проект легче приспособить для обмена любыми данными, в зависимости от конкретной задачи. Например, можно получать данные от различных датчиков и отправлять их в компьютер для обработки – получится устройство ввода (так работают клавиатура или мышь USB, и другие USB-устройства ввода). Можно принимать команды от компьютера, чтобы управлять каким-либо другим устройством или процессом – получится устройство вывода. В общем, описанный в статье проект можно взять за основу при разработке своих функциональных устройств, способных обмениваться нужной информацией, для чего проект должен быть дополнен соответствующим прикладным кодом.

Прерывания и опрос флагов событий. Как обрабатывать события USB – с помощью опроса значений флагов в регистрах или по прерываниям? Как известно, МК может реализовывать свои алгоритмы работы с внешними устройствами одним из двух способов: периодический, достаточно частый опрос периферийного устройства на предмет готовности к обмену, либо по прерываниям, когда периферийное устройство само является инициатором обмена и формирует запрос на прерывание. Здесь под "периферийным устройством" подразумевается внутренняя периферия самого МК: таймеры, модуль UART, АЦП, модуль USB и т. д., а не устройства, присоединенные к нему проводками (хотя в определенных случаях они также могут генерировать прерывания по перепаду уровня на выводе порта GPIO).

Моя программа написана по классической методике обработки прерываний - тело программы представляет собой пустой цикл, содержащий всего две команды: sleep и rjmp SLP, а вся работа возложена на обработку двух прерываний от модуля USB. ИМХО, этот способ предпочтительнее, поскольку позволяет рационально распределять процессорное время, не тратить его на бесконечный опрос регистров периферии на предмет готовности к обмену. Обмен данными с хостом производится только в подпрограмме-обработчике прерывания USB_ENDPOINT от соответствующей конечной точки. Все остальное время, а это 99.9%, МК пребывает в состоянии idle (состояние сна), т. е. бездействует. Возьмем, к примеру, цикл передачи данных хосту в рабочем режиме (после прохождения процедуры энумерации). Здесь подпрограмма-обработчик USB_ENDPOINT для точки EP1 вызывается всякий раз при приходе запроса IN от хоста (с интервалом, прописанным в дескрипторе конечной точки EP1). На обработку этого прерывания МК затрачивает всего 3.3 мкс (при тактовой частоте 16 МГц). Если интервал опроса задать, к примеру, 30 мс, то получается, что МК бездействует мс в каждом цикле почти на 99% процессорного времени! Это свободное время можно использовать под какие-нибудь прикладные цели и задачи, если добавить соответствующий код. Код этот может работать как с периферией МК, так и с внешними устройствами. Добавив, например, сюда подпрограмму обмена по интерфейсу SPI (I2C/TWI, UART и т. д.), мы сможем получать данные от всевозможных датчиков или АЦП, для последующей передачи этих данных хосту.

[Описание firmware микроконтроллера]

Блок векторов прерываний. Начало программы типично для большинства ассемблерных программ для AVR-микроконтроллеров. Это прежде всего директива .INCLUDE, указывающая транслятору на необходимость вставить в наш программный код файл usb162def.inc. Файл содержит описание констант, рабочих регистров, векторов прерываний нашего микроконтроллера. Это своего рода база данных, посредством которой транслятор отождествляет наш код с конкретной моделью МК.

Директива .CSEG задает начало сегмента кода нашей программы или просто – начало программы. Директива .ORG $000 присваивает счетчику команд значение $000. По этому адресу выбирается команда rjmp RESET, и происходит переход на подпрограмму обработки сброса - метка RESET. RESET это главная подпрограмма, цель которой – установка и настройка периферийных устройств, регистров, портов, режимов энергопотребления МК под выполнение нашей конкретной программы (задачи). Помимо RESET, эта секция программы содержит еще два вектора:

;------------------------------------------------

;Вектора сброса и обработчиков прерываний:

;------------------------------------------------

.ORG $000
   rjmp RESET

.ORG $016
   rjmp USB_GENERAL     ;обработка общих событий

.ORG $018
   rjmp USB_ENDPOINT    ;обработка прерывания конечной точки

Каждому вектору прерывания соответствует физический адрес в памяти программ, который заносится в счетчик команд при поступлении запроса на прерывание от USB-модуля (при условии, что прерывания разрешены). По этому адресу находится команда перехода на подпрограмму обработки прерывания или просто на обработчик.

Стек. Первое, что нужно сделать сразу после сброса – организовать стек программы. В стек процессор записывает адреса возврата из подпрограмм и обработчиков прерываний. В указатель стека SP помещается адрес последней ячейки ОЗУ – константа RAMEND, определенная в файле usb162def.inc. Обнуляются регистры R1, R2, R25 и R26 для дальнейшего использования. Так как МК получает питание 5V от шины , то очисткой бита REGDIS регистра REGCR включается внутренний регулятор напряжения модуля USB 3.3V, чтобы обеспечить необходимый уровень на выводах D+ и D- интерфейса USB.

Примечание: в случае, когда схема питается стабилизированным напряжением 3.3V, внутренний регулятор может быть отключен установкой бита REGDIS. Это можно и не делать, поскольку бит REGDIS по умолчанию всегда сброшен, и его сброс здесь показан просто для примера.

Регистр REGCR относится к дополнительным регистрам ввода/вывода, которые занимают адресное пространство памяти данных, начиная с адреса 0х0060, до адреса 0х00FF. Однобайтные команды IN и OUT к таким регистрам не применимы, поскольку команды IN и OUT способны адресовать только первые 64 регистра из пространства ввода/вывода. Соответственно обращение к этим дополнительным регистрам производится как к ячейкам памяти, с помощью команд STS (непосредственная запись в память данных) и LDS (непосредственное чтение памяти данных). В нашей программе командой sts REGCR, R16 мы записываем значение R16 с предварительно сброшенным битом REGDIS в регистр REGCR (имя регистра REGCR, как и все мнемонические имена регистров и битов процессора, автоматически подставляются из подключаемого файла usb162def.inc).

WDT. Следующий блок команд выключает сторожевой таймер (WatchDog Timer, WDT). Этот код целиком взят из оригинального даташита на МК AT90USB162 стр.55 []. Сторожевой таймер в данной версии программы не используется. Будет задействован сторожевой таймер или нет – решает разработчик, однако в любом случае упомянутый блок команд обязательно должен быть включен в процедуру инициализации МК при запуске, поскольку взведенный по умолчанию таймер WDT, не будучи своевременно сброшенным, сам периодически сбрасывает МК, не давая ему приступить к обмену данными с хостом.

Примечание: включен по умолчанию таймер WDT после сброса, или нет, можно настроить фюзами МК AT90USB162.

GPIO (порты ввода/вывода). Далее производится настройка порта D, к выводам PD4..PD0 которого подключены пять индикаторных светодиодов (рис. 1). Разряды DDRD4..DDRD0 регистра DDRD конфигурируются как выходы в состоянии ноль (PORTD=0). Светодиоды были задействованы на этапе написания и отладки программы для индикации стадий обмена пакетами между устройством и хостом, состояния отдельных битов в управляющих регистрах модуля USB и т. д. Каждый из светодиодов разработчик может использовать по своему усмотрению для сигнализации о каких-нибудь событиях в программе. Если такой необходимости нет, то светодиоды можно не устанавливать, а эти четыре команды настройки порта исключить из программы.

Рис. 1. Подключение индикационных светодиодов (для отладки программы).

Тактовый генератор. Для работы интерфейса USB требуется частота 48 МГц, которая вырабатывается генератором с ФАПЧ (PLL), см. схему 6-6 на стр. 37 даташита []. Эта частота получается с помощью деления и умножения частоты кварцевого резонатора, подключенного к МК. В нашем случае используется кварц на 16 МГц. Чтобы запустить генератор, необходимо обеспечить на его входе частоту 8 МГц и разрешить его работу. 8 МГц получаются делением тактовой частоты МК на 2. Для этого в разряды предделителя частоты PLLP2, PLLP1, PLLP0 регистра PLLCSR записывается значение 001b. Если у Вас используется кварцевый резонатор на 8 МГц, то делить частоту не нужно.

Работу генератора разрешаем установкой в единицу разряда PLLE того же регистра (команды ldi R16,(0 << PLLP2)+(0 << PLLP1)+(1 << PLLP0)+(1 << PLLE) и out PLLCSR, R16). Регистр PLLCSR имеет также разряд PLOCK, в котором мы ожидаем появление единицы (цикл bit_lock), свидетельствующей о захвате частоты в петле ФАПЧ. Захват частоты это событие, после которого начинается процесс устойчивой генерации.

USB. Затем идут стандартные процедуры включения модуля USB (команды lds R16, USBCON, sbr R16, 1 << USBE и sts USBCON, R16), разрешение тактирования (команды cbr R16, 1 << FRZCLK и sts USBCON, R16) и подключения (команды lds R16, UDCON, cbr R16, 1 << DETACH и sts UDCON, R16).

После обнаружения нового устройства на шине, перед началом обмена, хост производит сброс шины переводом линий D+ и D- в состояние однополярного нуля (Single-ended 0) на время не менее 10 мс. Чтобы идти дальше, нам необходимо отследить момент окончания этого события, для чего организован цикл r_bus, в котором непрерывно опрашивается состояние бита EORSTI регистра UDINT. Установка в единицу этого бита производится аппаратно по окончании сброса на шине и служит условием выхода из цикла. Подтверждаем выход из состояния сброса записью нуля в разряд EORSTI двумя последующими командами cbr R16, 1 << EORSTI и sts UDINT, R16.

По возвращению на стадию инициализации в разряд RSTCPU регистра UDCON запитсывается 1 (команды lds R16, UDCON, sbr R16, 1 << RSTCPU и sts UDCON, R16), разрешая сброс ядра МК при возникновении сброса на шине. В ходе отладки программы выяснилось, что если этого не сделать, то устройство USB, оставленное присоединенным к компьютеру при перезагрузке операционной системы, не будет опознано. Далее разрешается обработка прерывания по событиям приостановки и сброса, для чего записываются единицы в соответствующие разряды регистра UDIEN (команды ldi R24, (1 << SUSPE)+(1 << EORSTE) и sts UDIEN, R24). Аналогично, установкой в единицу разряда RXSTPE регистра UEIENX, разрешается прерывание по приходу пакета SETUP от хоста (команды ldi R24, 1 << RXSTPE и sts UEIENX, R24).

Поскольку работа программы организована по прерываниям и делать больше ничего не требуется, то имеет смысл переводить МК в режим пониженного энергопотребления - всякий раз при выходе из обработчика прерывания. Перевод в режим Idle разрешается записью единицы в разряд SE регистра SMCR (командами ldi R16, 1 << SE и out SMCR, R16). Теперь на выходе из подпрограммы обработки прерывания процессор встречает в основном цикле программы команду sleep, и переходит в режим пониженного энергопотребления (Idle) - до появления следующего запроса на прерывание. В режиме Idle любой запрос на прерывание пробуждает МК для выполнения своей подпрограммы обработки прерывания.

Завершается стадия инициализации командой sei, которая глобально разрешает прерывания. После инициализации процессор начинает выполнять тело бесконечного цикла, который содержит только две команды - sleep и rjmp SLP.

Теперь рассмотрим код обработчиков прерываний USB_GENERAL и USB_ENDPOINT.

USB_GENERAL. Эта подпрограмма является общим обработчиком прерываний модуля USB, и призвана обрабатывать события, возникающие на шине. Каждое событие на шине характеризуется определенным ее состоянием. Модуль USB различает шесть состояний на шине, по которым делается вывод о наступлении того или иного события. Например, отсутствие в течение 3 мс пакетов SOF (Start Of Frame, начало фрейма) свидетельствует о переводе шины хостом в неактивное состояние (т. е. обмен данными прекращается, и устройство в целях энергосбережения должно перейти в режим сна), это так называемое событие приостановки. Желая возобновить работу, хост устанавливает между линиями D+ и D- уровень напряжения -3.0V (дифференциальный ноль) на время не менее 20 мс, с последующим сигналом конца пакета EOP (End Of Packet) - событие возобновления работы, и т. д.

Для идентификации возникшего события и формирования запроса на прерывание предназначен регистр UDINT. В этом регистре каждому внешнему событию ставится в соответствие определенный разряд, который принимает единичное значение при наступлении определенного события. В нашей программе обработчик USB_GENERAL вызывается при возникновении одного из трех событий - окончание сброса (END_OF_RESET), приостановка (SUSPEND), пробуждение (WAKE_UP). Работа обработчика сводится к тому, чтобы по наличию единицы в проверяемом разряде регистра UDINT определить, какое событие произошло, и выполнить соответствующие событию действия.

Обработка сброса по шине USB. Начинается подпрограмма с выявления события окончания сброса на шине. Для этого командами lds R24, UDINT и sbrs R24, 3 проверяется разряд EORSTI, единица в котором свидетельствует о наступлении определенного события. После этого очищается разряд EORSTI, и происходит выход из подпрограммы (rjmp vihod_ug). Если же EORSTI равен нулю, то сброса на шине не было, и обработчик USB_GENERAL был вызван другим событием.

Обработка события приостановки. Продолжается проверка других условий возникновения прерывания - происходит переход на метку next_ev_1, где командой sbrs R24, 0 проверяется наличие единицы в разряде SUSPI, тем самым определяется следующее возможное событие - приостановка. Хост инициирует состояние приостановку всякий раз, когда компьютер (с присоединенным к нему нашим устройством) переходит в энергосберегающий режим (PowerDown). Если событие приостановки произошло (SUSPI = 1), то необходимо выполнить последовательность операций по переводу модуля USB в режим SUSPEND, пользуясь методикой, описанной в даташите [] (пункт 19.10, стр. 195). Сначала очищается бит приостановки командами cbr R24, 1 << SUSPI и sts UDINT, R24. Затем останавливается тактирование периферийного устройства USB командами lds R24, USBCON, sbr R24, 1 << FRZCLK, sts USBCON, R24, и запрещается работа внутреннего генератора блока USB с системой ФАПЧ (PLL) командами in R16,PLLCSR, cbr R16, 1 << PLLE и out PLLCSR, R16. Для того, чтобы возобновить работу устройства при выходе компьютера из состояния "Выключено" (или режима сна), разрешается прерывание по событию пробуждения (команды lds R24, UDIEN, sbr R24, 1 << WAKEUPE и sts UDIEN, R24). Обратие внимание, что прерывание по событию WAKE_UP (пробуждение) разрешается, только если устройство USB находится в состоянии SUSPEND (приостановка). После этого происходит выход из обработчика прерывания в основной цикл (rjmp vihod_ug), который переводит устройство в режим сна. Теперь наше устройство остановлено и пребывает в режиме с низким энергопотреблением (sleep), ожидая событие пробуждения (WAKE_UP). Хост инициирует состояние пробуждения на шине всегда, когда компьютер переходит из энергосберегающего режима (Power Down) в рабочий.

Обработка события пробуждения. Предположим, что устройство USB находится в состоянии SUSPEND. Тогда, обнаружив на шине состояние WAKE_UP, модуль USB генерирует запрос на прерывание. В этом случае проверка разрядов регистра UDINT приведет к переходу по метке next_ev_2, где будет найдера единица в разряде WAKEUPI (команда sbrs R24, 4), т. е. имеет место событие пробуждения с последующим возобновлением работы. Для пробуждения выполняется ряд действий, так же определенных в даташите [] (пункт 19.10, стр. 195). Разрешается работу генератора с системой ФАПЧ (PLL) - команды in R16, PLLCSR, sbr R16, 1 << PLLE, out PLLCSR, R16. Ожидается захват в петле ФАПЧ в цикле lock_bit. Разрешается тактирование модуля USB командами cbr R24, 1 << FRZCLK и sts USBCON, R24. Сбрасывается разряд WAKEUPI, вызвавший прерывание - команды lds R24, UDINT, cbr R24, 1 << WAKEUPI, sts UDINT, R24. Запрещается прерывание по событию пробуждения - команды lds R24, UDIEN, cbr R24, 1 << WAKEUPE и sts UDIEN, R24. Выбирается (активируется) нулевая конечная точка командой sts UENUM, R1. Это делается в связи с тем, что до входа в состояние приостановки (SUSPEND) весь обмен с устройством происходил через конечные точки EP1 и EP2, а конечная точка EP0 была деактивирована. Возобновив работу устройства USB по событию пробуждения (WAKE_UP), хост будет пытаться организовать канал через конечную точку EP0, чтобы отправить новый запрос. Если EP0 не будет выбрана, то хост не сможет получить к ней доступ, что приводит к ошибке и зависанию ПО хоста. Запрос, который посылает хост сразу после пробуждения, называется SET_IDLE (он будет описан далее при рассмотрении обработчика прерывания USB_ENDPOINT). Завершается процедура пробуждения записью единицы в регистр R2 командой inc R2. Эта единица выполняет роль флага, и будет анализироваться впоследствии, при обработке запроса SET_IDLE. Давайте перейдем к рассмотрению к самой основной части программы, определяющей функционирование всего устройства USB - обработчику прерывания USB_ENDPOINT.

USB_ENDPOINT. ЭНУМЕРАЦИЯ. Обмен информацией между хостом и устройством USB осуществляется через конечные точки. Конечная точка, готовая к обмену, генерирует запрос на прерывание, вызывая тем самым обработчик USB_ENDPOINT, в котором и происходит обмен данными. Прежде чем приступить к обработке запроса, нужно вначале узнать, от какой конечной точки он поступил. Для этой цели служит регистр UEINT, где котором в порядке возрастания определены биты прерываний конечных точек. Если запрос вызван конечной точкой EP0, то будет установлен нулевой бит этого регистра, если конечной точкой EP1 - первый, и т. д.

Если прерывание инициировано конечной точкой EP0 (две первые команды - lds R24, UEINT и cpi R24, 1), то происходит передача управления ep_0. В нашей программе ЕР0 может генерировать запрос в одном единственном случае - принят пакет SETUP от хоста (разряд RXSTPI регистра UEINTX равен единице), и содержимое этого пакета уже находится в ее буфере (банке).

Любые запросы от хоста выполняются при помощи контрольных транзакций (подробнее можно почитать в [1], это великолепная серия статей, посвященных программированию USB устройств и опубликованных в журнале "Современная электроника" с октября 2004 г.). Транзакция представляет из себя сеанс обмена данными, и в зависимости от запроса она может содержать две или три фазы:

1. Фаза SETUP, в которой мы принимаем пакет SETUP, содержащий запрос к устройству. Эта фаза обязательная.
2. Фаза DATA (данные), в которой мы отправляем, то, что требует хост. Эта фаза не обязательная.
3. Фаза STATUS, которая нам говорит, что хост закончил принимать данные (фаза DATA закончена) и ожидает подтверждения завершения транзакции. Эта фаза обязательная.

Если, к примеру, взять запрос SET_ADDRESS (которое мы позже разберем), то в нем не требуется принимать или передавать данные; нужно просто присвоить устройству новый адрес, который в качестве параметра находится в пакете SETUP. Поэтому фаза данных закономерно отсутствует. Напротив, запрос GET_DESCRIPTOR подразумевает отправку дескриптора, т. е. какого-то количества данных хосту, что само по себе предусматривает наличие фазы данных. И мы имеем контрольную транзакцию уже с тремя фазами.

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

При получении пакета можно приступать к его расшифровке. В пакете SETUP имеется следующая последовательность из 8 байтов:

0x80 0x06 0x00 0x01 0x00 0x00 0x40 0x00

где

0x80 - поле bmRequestType - стандартный запрос к устройству.
0x06 - поле bRequest - номер запроса - GET_DESCRIPTOR.
0x00 0x01 - поле wValue - тип дескриптора, старший (второй) байт - DEVICE_DESCRIPTOR.
0x00 0x00 - поле wIndex - зависит от запроса - не используется.
0x40 0x00 - поле wLength - количество байт, требуемое хостом в ответном пакете - 64 байта.

Первые два байта конфигурационного пакета выбираются из буфера через регистр UEDATX двумя командами lds R17, UEDATX и lds R16, UEDATX. Таким образом, значение поля bRequest теперь находится в регистре R16, а значение поля bmRequestType - в регистре R17. Первым всегда проверяется равенство R16 числу 0х06 (cpi R16, 0x06), что соответствует запросу GET_DESCRIPTOR. Если равенство установлено, то происходит переход на метку get_dsc, где проверяется уже поле bmRequestType (cpi R17, 0x80). Значение 0x80 в регистре R17 означает переход на метку stand_desc. В метке stand_desc запускается подпрограмма read_buff, в которой считываются из буфера остальные 6 байт конфигурационного пакета в регистры R18 - R23 (lds R18, UEDATX - lds R23, UEDATX). Командами lds R24, UEINTX, cbr R24, 1 << RXSTPI и sts UEINTX, R24 сбрасывается разряд RXSTPI регистра UEINTX, подтверждая прием пакета SETUP (ACK), и очищая буфер ЕР0.

На выходе из подпрограммы read_buff, проверяется значение регистра R19 (cpi R19, 1), содержащего теперь тип дескриптора. Если значение оказывается равным 0x01, тогда нужно обработать дескриптор устройства (DEVICE_DESCRIPTOR), и происходит переход на метку d_dev. Значение младшего байта поля wLength (и соответственно регистра R22) в первом, полученном нами конфигурационном пакете, равно 0x40 или 64 в десятичной системе. Таким образом, хост требует от нас дескриптор устройства размерностью 64 байта.

Обработка фазы DATA. Конфигурационный пакет успешно принят и расшифрован. Наступает черед фазы DATA (данных). В метке d_dev проверяется состояние флага TXINI регистра UEINTX (команды lds R24, UEINTX и sbrs R24, 0). Его единичное состояние говорит нам о том, что был принят пакет IN, и передатчик модуля USB готов принять данные для отправки. Эти данные, представленные в виде массивов констант, и есть дескрипторы нашего устройства. Массивы записаны в память программ, начиная с адреса $300, после программного кода (директива .ORG $300), и извлекаются от туда один за другим, по мере поступления запросов от хоста.

Примечание: директива без .ORG с адресом $300 использовалась не случайно. Без этой директивый константы окажутся сразу за кодом. Однако в моем варианте программы директива нужна, т. к. количество отправленных байт в метке d_dev проверяется в регистре R30. И этот регистр, содержащий младший байт адреса константы, должен иметь начальное нулевое значение. Без .ORG $300 (можно использовать и другое значение адреса, $400, $500 и т. д.) нулевое значение R30 не гарантируется.

Первый массив (метка dev_desc) является дескриптором нашего устройства, и он имеет размер 18 байт (стандартное значение). Разберем по байтам, что находится в дескрипторе устройства.

0x12 - (bLength) - размер дескриптора в байтах - 18 байт;
0х01 - (bDescriptorType) - тип дескриптора - DEVICE_DESCRIPTOR;
0х00, 0х02 - (bcdUSB) - номер спецификации USB, которой удовлетворяет устройство, в двоично-десятичном формате – USB 2.0 на скорости Full Speed;
0х00 - (bDeviceClass) - класс прибора - не указывается;
0х00 - (bDeviceSubClass) - подкласс прибора - не указывается;
0х00 - (bDeviceProtocol) - протокол прибора - не указывается;
0х20 - (bMaxPacketSize0) - размер пакета для конечной точки 0 - 32 байта;
0xEB, 0x03 - (idVendor) - идентификатор производителя устройства (VID) - Atmel Corp.;
0x13, 0x20 - (idProduct) - идентификатор продукта (PID) - стандартное HID-устройство;
0x00, 0x10 - (bcdDevice) - номер версии устройства - взят из демо-программы Atmel;
0х01 - (iManufacturer) - индекс текстовой строки производителя (строковые дескрипторы рассмотрим позднее);
0х02 - (iProduct) - индекс текстовой строки изделия;
0х03 - (iSerialNumber) - индекс текстовой строки серийного номера;
0х01 - (bNumConfigurations) - количество возможных конфигураций - одна конфигурация.

Для отправки дескриптора устройства в индексный регистр Z загружается адрес первого элемента нашего дескриптора (команды ldi R31, high(dev_desc*2) и ldi R30, low(dev_desc*2)). Командой lpm R24,Z+ пересылается значение, находящееся по этому адресу (число 0x12) в регистр R24, и происходит переход на следующий адрес с инкрементом регистра Z (косвенная адресация с постинкрементом). Затем значение из регистра R24 помещается в регистр данных UEDATX модуля USB для последующей записи в буферную память ЕР0. Этот цикл (out_data_d) повторяется 18 раз, пока не будут записаны в буфер все 18 байт дескриптора (cpi R30, 18). После этого программно сбрасывается разряд TXINI (команды lds R24, UEINTX, cbr R24, 1 << TXINI и sts UEINTX, R24) для отправки данных хосту, и происходит переход на подпрограмму w_nakout (rcall w_nakout).

Обработка фазы STATUS. Наступает очередь фазы STATUS, и нам нужно определить момент ее наступления и обработать. Это и является задачей подпрограммы w_nakout. Обратимся к временной диаграмме из даташита [] (рис. 3):

Рис. 3. Диаграмма последовательности обмена данными.

Здесь видно, что при переходе от фазы DATA к фазе STATUS хост меняет направление передачи данных - пакеты IN меняются на пакеты OUT. Именно это обстоятельство используется в подпрограмме w_nakout, чтобы отследить окончание фазы данных. Кстати аналогичным образом происходит переход DATA -> STATUS и в контрольной транзакции с фазой записи данных - пакеты OUT меняются на IN (смотрите соответствующую временную диаграмму в даташите []).

После того, как хост принял от нас необходимое количество данных, он инициирует фазу STATUS, посылая нам первый пакет OUT (и пакет нулевой длины - согласно спецификации), на который контроллер всегда отвечает пакетом NAK (показано на диаграмме). Одновременно в регистре UEINTX аппаратно устанавливается флаг NAKOUTI. Факт установки этого флага отслеживается в первых трех строчках подпрограммы w_nakout. Установленный флаг NAKOUTI сбрасывается (cbr R24, 1 << NAKOUTI, sts UEINTX, R24) для приема следующего пакета. Хост в свою очередь, получив от нас пакет NAK, повторяет запрос, посылая второй пакет OUT.

Приход второго пакета мы ожидается в цикле w_out проверкой значения разряда RXOUTI регистра UEINTX (команды lds R24, UEINTX, sbrs R24, 2) до появления в нем единицы. Установка этого разряда в единицу свидетельствует о получении модулем USB пакета OUT. Когда второй пакет получен, командами cbr R24, 1 << RXOUTI и sts UEINTX, R24 очищается разряд RXOUTI, генерируя маркер подтверждения ACK. Транзакция завершена. Далее осуществляется выход из подпрограммы (ret) и выход из обработчика прерывания (rjmp vihod_ep) в основной цикл сна программы.

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

Вторым запросом при энумерации, после получения урезанного дескриптора устройства, является назначение адреса устройству на шине. В данном случае хост инициирует контрольную транзакцию с двумя фазами. Первая фаза - SETUP - отправка конфигурационного пакета с запросом к устройству USB. Вторая фаза - STATUS - подтверждение. Конфигурационный пакет теперь представляет собой следующую последовательность байтов:

0х00 0х05 0хXX 0х00 0х00 0х00 0х00 0х00

где

0x05 (второй байт) - поле bRequest - номер запроса - SET_ADDRESS.
0xXX (третий байт) - младший байт поля wValue - адрес, назначенный устройству. Может иметь любое значение от 1 до 127.

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

Получив пакет SETUP и имея в своем буфере его содержимое, конечная точка EP0 генерирует запрос на прерывание. Это выводит МК из режима сна, и запускает обработчик прерывания по метке USB_ENDPOINT. Здесь проверяется, от какой конечной точки поступил запрос (lds R24, UEINT, cpi R24, 1), и происходит переход на метку ep_0. Через регистр UEDATX в регистры R17, R16 загружаются первые два байта конфигурационного пакета из буфера ЕР0. Первым проверяется значение R16. Если оно не равно 0х06, то происходит переход на метку next_0. Значение 0х05 показывает запрос SET_ADDRESS, при этом произойдет переход на метку set_adr. Новое значение адреса на шине идет следующим (третьим) байтом в конфигурационном пакете. Оно считывается из буфера командой lds R24, UEDATX и переписывается в регистр USB-адреса устройства UDADDR командой sts UDADDR, R24. Сбрасывается разряд RXSTPI регистра UEINTX, подтверждая прием пакета SETUP (команды lds R24, UEINTX, cbr R24, 1 << RXSTPI и sts UEINTX, R24). Получив подтверждение (ACK), хост сразу переходит на фазу STATUS (фаза данных отсутствует), отправляя пакет IN пока еще по нулевому адресу.

В описании сказано, что контроллер не подтверждает прием первого IN-пакета фазы STATUS, посылая маркер NAK. Однако в ходе написания программы опытным путем выяснилось, что по факту этого не происходит - флаг NAKINI остается в нулевом состоянии. Остается только убедиться, что разряд TXINI установлен (lds R24, UEINTX, sbrs R24, 0) и затем сразу сбросить его (cbr R24, 1 << TXINI). Этим действием посылается хосту пакет нулевой длины (так называемый ZLP - Zero Length Packet). Он отличается отсутствием данных - между приемом IN-пакета и сбросом TXINI отсутствует стадия записи данных в буфер конечной точки для дальнейшей отправки (какой мы ее видим например, при передаче дескриптора). Согласно спецификации USB отправка ZLP в ответ на пакет IN, является обязательным условием выполнения запроса SET_ADDRESS. Этим мы как бы сообщаем хосту, что запрос выполнен, и готовы к дальнейшему обмену уже по новому адресу. Затем после проверки (в метке vt) аппаратной установки разряда TXINI регистра UEINTX, отдельно командами lds R24, UDADDR, ori R24, 0x80 и sts UDADDR, R24, записывается единица в разряд ADDEN регистра UDADDR - для активации нового адреса. На этом работа подпрограммы закончена. Происходит выход из обработчика прерывания (rjmp vihod_ep) до появления нового пакета SETUP. Теперь наше устройство считается адресованным, и все последующие запросы будут приходить к нему уже по назначенному хостом новому адресу. Адрес содержится, как мы знаем, в пакете запроса с маркером SETUP.

Отправка декскриптора устройства. Новый, третий по счету пакет SETUP, приходит с запросом GET_DESCRIPTOR, как уже упоминалось ранее:

0x80 0x06 0x00 0x01 0x00 0x00 0x12 0x00

где

0x80 - поле bmRequestType - стандартный запрос, адресованное устройству.
0x06 - поле bRequest - номер запроса - GET_DESCRIPTOR.
0x00 0x01 - поле wValue - тип дескриптора (старший байт) - DEVICE_DESCRIPTOR.
0x00 0x00 - поле wIndex - зависит от запроса - не используется.
0x12 0x00 - поле wLength - количество байт, требуемое хостом в ответном пакете - 18 байт.

При рассматрении полученного конфигурационного пакета оказывается, что он имеет в поле wLength (младший байт) новое значение длины дескриптора - 18 байт (0х12). Это длина дескриптора нашего устройства, которую мы отправили при первом его запросе. Механизм обработки здесь в точности повторяет обработку первого запроса, т. е. здесь мы вновь проходим все рассмотренные ранее стадии:

[СПИСОК №1, обработка контрольных транзакций]
- получение пакета SETUP;
- вызов обработчика USB_ENDPOINT
- чтение запроса (конфигурационного пакета) и его анализ;
- отправка дескриптора;
- подтверждение завершения транзакции;
- выход из обработчика.

Вообще все контрольные транзакции, которые требуют отправки дескриптора (а таковых большинство), всегда имеют три фазы, и обрабатываются строго в соответствие с этим списком. Запомним этот список, мы часто будем упоминать его далее по тексту, под названием - СПИСОК №1. Что касается транзакции с запросом SET_ADDRESS, то ее мы уже рассмотрели. Транзакцию с запросом SET_CONFIGURATION мы еще рассмотрим.

В дополнение к сказанному можно отметить, что поскольку длина дескриптора (18 байт) не превышает размера конечной точки EP0 (32 байта), то не требуется дробить его на части - все отправляется одним пакетом - 18 байт. Дробить понадобится дескриптор конфигурации, но об этом позже.

Отправка дескриптора конфигурации. После получения полноценного дескриптора устройства хост запросит дескриптор конфигурации, и для этого сформирует новый запрос - GET_CONFIGURATION. Полученный конфигурационный пакет теперь выглядит так:

0x80 0x06 0x00 0x02 0x00 0x00 0xFF 0x00

где

0x80 - поле bmRequestType - стандартный запрос, адресованный устройству.
0x06 - поле bRequest - номер запроса - GET_DESCRIPTOR.
0x00 0x02 - поле wValue - тип дескриптора (старший байт) - CONFIGURATION_DESCRIPTOR.
0x00 0x00 - поле wIndex - зависит от запроса - не используется.
0xFF 0x00 - поле wLength - количество байт, требуемое хостом в ответном пакете - взято условно-максимальным.

До вызова подпрограммы чтения запроса - read_buff по метке stand_desc все идет по отработанной схеме, согласно СПИСКУ №1. После прочтения запроса выясняется, что содержимое регистра R19 равно двум (0х02). Значения регистров R20 - R23 можно уже не проверять. Происходит переход Идем на метку d_con для выполнения запроса GET_CONFIGURATION_DESCRIPTOR.

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

Первым идет дескриптор конфигурации длиной 9 байт:

0х09 - длина дескриптора конфигурации - 9 байт;
0х02 - тип дескриптора - CONFIGURATION_DESCRIPTOR;
0х29, 0х00 - общая длина дескриптора конфигурации – суммарная длина всех пяти дескрипторов, входящих в его состав - 41 байт;
0х01 - количество интерфейсов в конфигурации - 1;
0х01 - номер нашей единственной конфигурации - 1;
0х00 - индекс строки, описывающей нашу конфигурацию. Не используется;
0х80 - устройство получает питание от шины;
0х32 - и потребляет ток 100 mA.

Дальше идет дескриптор интерфейса, длиной 9 байт:

0х09 - длина дескриптора интерфейса - 9 байт;
0х04 - тип дескриптора - INTERFACE_DESCRIPTOR;
0х00 - используем единственный интерфейс с номером 0;
0х00 - используем единственную альтернативную установку с номером 0. Понятие "альтернативная установка" - описано в [1];
0х02 - количество используемых конечных точек, исключая EP0 - 2 точки;
0х03 - класс интерфейса - 3 для HID-устройств;
0х00 - подкласс интерфейса - 0;
0х00 - протокол интерфейса - 0;
0х00 - индекс строки, описывающей интерфейс (отсутствует).

Дальше идет HID-дескриптор, длиной 9 байт:

0х09 - длина HID-дескриптора - 9 байт;
0х21 - тип дескриптора - HID_DESCRIPTOR;
0х00, 0х01 - номер версии HID - стандартное значение - 0х0100;
0х00 - код страны, для локализации устройства. Не локализовано -0;
0х01 - количество дескрипторов репорта нашего устройства - 1;
0х22 - тип дескриптора - REPORT_DESCRIPTOR;
0х22, 0х00 - длина дескриптора репорта (младший байт) - 34 байта.

Дальше идет дескриптор конечной точки 1, длиной 7 байт:

0х07 - длина дескриптора EP1 - 7 байт;
0х05 - тип дескриптора ENDPOINT_DESCRIPTOR;
0х81 - адрес конечной точки и ее направление - IN;
0х03 - тип передачи - Interrupt (по прерываниям);
0х08, 0х00 - максимальный размер пакета для EP1 (младший байт) - 8 байт;
0х0F - частота опроса хостом конечной точки 1 на предмет готовности данных - 16 мс.

Последним идет дескриптор конечной точки 2, длиной 7 байт:

0х07 - длина дескриптора EP2 - 7 байт;
0х05 - тип дескриптора ENDPOINT_DESCRIPTOR;
0х02 - адрес конечной точки и ее направление - OUT;
0х03 - тип передачи - Interrupt (по прерываниям);
0х08, 0х00 - максимальный размер пакета для EP2 (младший байт) - 8 байт;
0х0F - частота опроса хостом конечной точки 2 на предмет готовности данных - 16 мс..

Теперь по имеющимся данным можно изобразить структуру нашего устройства - рис. 4 (см. [1]):

Рис. 4. Логическая структура устройства USB.

Метка d_con: после контрольной проверки разряда TXINI на наличие единицы (получен пакет IN), командами lds R24, UEINTX и sbrs R24, 0, адрес первого байта дескриптора конфигурации загружается в индексный регистр Z (команды ldi R31, high(con_desc*2) и ldi R30, low(con_desc*2)). Далее профилактически очищается регистр R23 (clr R23 - необязательная команда) и проверяется значение R22. Оно после прочтения конфигурационного пакета равно не девяти, а 0хFF, поэтому происходит переход на метку out_dat_c.

Здесь все работает так же, как при отправке дескриптора устройства. Однако есть особенность – длина дескриптора конфигурации - 41 байт, но размер ЕР0 всего 32 байта. Поэтому мы не можем передать дескриптор одним пакетом, придется его передавать двумя кусками. Сначала последовательно загружаются первые 32 байта нашего дескриптора в буфер для отправки (цикл out_dat_c). После чего первый блок данных дескриптора отправляется хосту, для чего сбрасывается разряд TXINI после выхода из цикла. Получив порцию информации и зная, что это не все (хосту уже известна длина дескриптора), хост посылает второй пакет IN, чтобы получить оставшуюся часть. Момент прихода пакета IN мы отслеживается по аппаратной установке в единицу все того же разряда TXINI, циклическим опросом по метке d_con_1. Затем аналогичным образом загружается в буфер EP0 оставшиеся 9 байт дескриптора (цикл out_dat_c1). Обратите внимание, что счетчик - регистр R23 - перед входом в цикл out_dat_c1, содержит число 32 - количество уже отправленных байт. Для отправки загруженных данных снова сбрасывается разряд TXINI после выхода из цикла out_dat_c1. Дальше последует фаза STATUS, поэтому происходит переход на уже знакомую подпрограмму w_nakout (rcall w_nakout). Далее происходит выход из обработчика прерывания (rjmp vihod_ep). Все просто, не правда ли? А теперь посмотрите на тот же фрагмент кода, написанного на Си в демонстрационной программе STK526-series2-hidio-2_0_2-doc. Есть разница?

Примечание редактора: мне не кажется все это таким уж простым. ИМХО, применять готовые библиотеки и примеры кода на C гораздо проще.

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

0x80 0x06 0x03 0x03 0x00 0x00 0xFF 0x00

0x80 0x06 0x00 0x03 0x00 0x00 0xFF 0x00

0х04 0х03 0х09 0х04

0х04 0х03 0х19 0х04

0x80 0x06 0x02 0x03 0x00 0x00 0xFF 0x00

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

0x80 0x06 0x00 0x01 0x00 0x00 0x12 0x00

0x80 0x06 0x00 0x02 0x00 0x00 0x09 0x00

0x80 0x06 0x00 0x02 0x00 0x00 0x29 0x00

0x00 0x09 0x01 0x00 0x00 0x00 0x00 0x00

Обработка запросов класса HID. Наше устройство USB относится к классу HID. Устройства этого класса помимо стандартных запросов, поддерживают ряд специфических, к которым относится запрос SET_IDLE:

0x21 0x0A 0x00 0x00 0x00 0x00 0x00 0x00

где

0x21 - поле bmRequestType - запрос, относящийся к HID-устройству.
0x09 - поле bRequest - номер запроса - SET_IDLE.

Значения остальных полей нас не интересуют. В обработчике прерывания (вызванного как обычно приходом пакета SETUP) в R16 и R17 обнаруживаются значения 0x0A и 0x21 соответственно (метка next_2), после чего происходит переход на метку set_idle, где подтверждается прием пакета SETUP - первые три команды. Затем, убедившись в готовности передатчика (команды lds R24, UEINTX и sbrs R24, 0), отправляется хосту пакет нулевой длины (команды cbr R24, 1 << TXINI и sts UEINTX, R24), подтверждая тем самым исполнение запроса SET_IDLE. Далее необходимо проверить значение флага - регистра R2 (tst R2). Единица в этом регистре показывает, что текущий запрос SET_IDLE был послан хостом сразу после пробуждения (WAKE_UP) через выбранную перед этим пробуждением конечную точку EP0 (вспомните описание USB_GENERAL). Практика показала, что в этом случае никаких запросов от хоста больше не последует, и для дальнейшего успешного обмена (без зависаний ПО хоста) необходимо вновь выбрать конечную точку EP2. Это осуществляется командами ldi R16, 2 и sts UENUM, R16 после возврата R2 в исходное состояние (clr R2). Затем происходит выход из обработчика прерывания и возврат в основной цикл сна. Если же значение флага - регистра R2 - нулевое, то это означает, что идет начатый стандартный процесс идентификации HID-устройства, и программа уходит из прерывания в основной цикл, оставляя активной ЕР0, с ожиданием прихода следующего пакета SETUP с новым (и последним) запросом.

Обработка запроса GET_DESCRIPTOR_REPORT. В устройствах, относящихся к HID-классу, обмен данными между конечной точкой IN (у нас это EP1), конечной точкой OUT (у нас это EP2) и хостом осуществляется посредством специальных информационных посылок, равных размеру конечной точки (8 байт), именуемых репортами. Представление данных в репорте подчиняется определенным правилам, которые описаны в специфическом дескрипторе репорта (REPORT_DESCRIPTOR), характерном только для HID-класса. Правила эти должны быть известны хосту, поэтому до начала обмена через точки IN и OUT он посылает последний запрос - GET_DESCRIPTOR_REPORT:

0x81 0x06 0x00 0x22 0x00 0x00 0x62 0x00

где

0x81 - поле bmRequestType - стандартный запрос для интерфейса, с передачей данных от устройства к хосту.
0x06 - поле bRequest - номер запроса - GET_DESCRIPTOR.
0x00 0x22 - поле wValue - тип дескриптора (старший байт) - REPORT_DESCRIPTOR.
0x00 0x00 - поле wIndex - зависит от запроса - не используется.
0x62 0x00 - поле wLength - количество байт, требуемое хостом в ответном пакете – 98 (34 байта + 64 байта).

Замечание: длина нашего дескриптора репорта - 34 байта, и поэтому мы логично ожидаем в младшем байте поля wLength значение 0х22 (34). Однако хост (по пока не выясненной причине) требует 98 байт дескриптора (0х62), что на 64 байта больше фактического значения. Тем не менее мы отправляем только имеющиеся 34 байта (ни больше, ни меньше), и хост остается "доволен". Дескриптор репорта идет последним в нашем блоке дескрипторов, и он находится по адресу, заданному меткой rep_desc. За его основу был взят дескриптор из демонстрационной программы STK526-series2-hidio-2_0_2-doc (файл usb_descriptors.c), затем дескриптор был немного урезан (исключена секция Feature report), и теперь выглядит так:

1. 0x06, 0x00, 0xFF Usage Page (Vendordefined)
2. 0x09, 0x01 Usage (UsageID - 1)
3. 0xA1, 0x01 Collection (Application)
4. 0x09, 0x02 Usage (UsageID - 2)
5. 0x15, 0x00 Logical Minimum (0)
6. 0x26, 0xFF, 0x00 Logical Maximum (255)
7. 0x75, 0x08 Report Size (8)
8. 0x95, 0x08 Report Count (8)
9. 0x81, 0x02 IN report (Data, Variable, Absolute)
10. 0x09, 0x03 Usage (UsageID - 3)
11. 0x15, 0x00 Logical Minimum (0)
12. 0x26, 0xFF, 0x00 Logical Maximum (255)
13. 0x75, 0x08 Report Size (8)
14. 0x95, 0x08 Report Count (8)
15. 0x91, 0x02 OUT report (Data, Variable, Absolute)
16. 0xC0 End Collection

Опишу то, что удалось понять в дескрипторе репорта.

Строка 1 - поле Usage Page - задает некоторый класс устройств с общими характеристиками. Первый байт этого поля может иметь значение 0х05 (как правило) или 0х06 (у нас). Два младших бита первого байта показывают количество оставшихся байтов в этом поле. Число 0х06, например, в двоичном представлении - 00000110b. Два младших разряда (10b) это десятичное число 2. Значит после первого байта (0х06) следуют еще два - 0х00 и 0хFF. В нашем случае устройство не относится к какому-то определенному классу, а его назначение определяется производителем (Vendordefined).

Строка 2 - поле Usage - задает подкласс устройств или функций, которые функционируют в пределах класса, указанного в поле Usage Page. Здесь первый байт - идентификатор поля - как правило имеет значение 0х09. Второй байт - идентификатор собственно устройства или функции, который задает их назначение. В нашем дескрипторе эти идентификаторы, идущие в порядке возрастания (строки 2, 4, 10), показаны для примера и не задействованы.

Строка 3 - поле Collection - задает начало группы элементов одного типа. Тип указывается во втором байте. У нас - группа элементов прикладного типа (Application), с идентификатором 0х01.

Строка 5 - поле Logical Minimum - определяем минимальное значение в каждом принимаемом байте, в логических единицах. Минимальное значение задается вторым байтом и равно нулю (0х00). Здесь не забываем тот факт, что направление передачи берется относительно хоста. То есть IN-репорт это пакет данных, получаемых хостом.

Строка 6 - поле Logical Maximum - определяем максимальное значение в каждом принимаемом байте, в логических единицах. Максимальное значение задается вторым байтом и равна 255 (0хFF). Если первый байт этого поля (0х26) представить в двоичном виде - 00011010b, то увидим, что два младших разряда есть десятичное число два. Это означает, как мы уже знаем, присутствие еще двух байтов после первого - 0xFF и 0x00, причем назначение последнего не установлено.

Строка 7 - поле Report Size - задаем размер единицы (одного элемента данных) принимаемой информации в битах - 8 бит или 1 байт.

Строка 8 - поле Report Count - задаем количество единиц принимаемой информации - 8 единиц. Таким образом количество принимаемых байтов в репорте - восемь. И размер репорта составляет восемь байт.

Строка 9 - поле IN report, говорит нам, что все рассмотренные ранее строки, начиная с 4-ой, относятся к IN-репорту. В первом байте поля (0х81) старшая тетрада (так называемое поле тега = 1000b) означает тип репорта - IN. Младшая (0001b) содержит в двух младших битах единицу, что означает, что за первым байтом (0х81), последует только один байт со значением - 0х02. Это самый ответственный байт. В нем сгруппированы биты (данных), отвечающие за определенные характеристики и представление данных в репорте ( в данном случае в IN-репорте). Подробно все они описаны в [3]. Мы лишь отметим, что число 0х02 во втором байте означает, что данные репорта могут изменяться (Data), представлены, как восемь отдельных восьмибитных элементов (Variable), и значения их берутся относительно нуля (Absolute). Вот все, что касается IN-репорта.

Строки 11 .. 14 в точности повторяют поля, которые мы уже рассмотрели раньше. Только теперь они относятся к OUT-репорту, то есть пакету данных, получаемому устройством.

Строка 15 - поле OUT report. Для нее справедливо все, что раньше было сказано про строку девять. Отличие только в первом байте (0х91), старшая тетрада которого - 1001b - обозначает тип репорта - OUT.

Строка 16 - поле End Collection - определяет конец группы элементов одного типа.

Обработка запроса GET_DESCRIPTOR_REPORT ничем не отличается от обработки других запросов. После получения очередного пакета SETUP выполняются два первых пункта из СПИСКА №1. После проверки значения поля bRequest в регистре R16 (cpi R16, 0x06), которое равняется 0х06, происходит переход на метку get_dsc. Там, уже в регистре R17, проверяется значение поля bmRequestType, и если оно равно 0х81, то это означает, что данный дескриптор относится к интерфейсу. Происходит переход на метку int_desc, где считываются остальные 6 байт конфигурационного пакета (вызовом подпрограммы read_buff). Однако нас интересуют только два из них - тип дескриптора в регистре R19, и количество байт для отправки хосту в регистре R22. Если значения в этих регистрах совпадают с ожидаемыми, то происходит переход на метку d_rep_1, где проверяется, что получен пакет IN, и проверяется готовность передатчика (lds R24, UEINTX и sbrs R24, 0), очищается счетный регистр R23 (clr R23) и в Z-регистр загружается значение адреса первого элемента дескриптора репорта - команды ldi R31, high(rep_desc*2) и ldi R30, low(rep_desc*2). Длина дескриптора здесь снова превышает размер конечной точки (34 против 32), поэтому отправляться дескрипутор будет двумя кусками (как когда-то отправляли дескриптор конфигурации). Сначала первые 32 байта дескриптора переписываются в буфер конечной точки EP0 (цикл out_dat_r) и этот первый блок отправляется хосту (lds R24, UEINTX, cbr R24, 1 << TXINI и sts UEINTX, R24). Затем, после прихода следующего пакета IN и готовности передатчика (цикл d_rep_2), переписываеются в буфер EP0 оставшиеся два байта (цикл out_dat_r1). Обратите внимание, что значение счетчика байтов (R23) до этого было равно 32. Затем хосту отправляются два байта (lds R24, UEINTX, cbr R24, 1 << TXINI и sts UEINTX, R24) и далее как обычно отрабатывается фаза SETUP (rcall w_nakout), чем завершается транзакция.

На практике установлено, что после отправки дескриптора репорта пакеты SETUP больше не поступают, соответственно никаких запросов к устройству не предъявляется. Поэтому по-видимому устройство USB успешно прошло все этапы энумерации и HID-идентификации. Теперь оно считается работоспособным? и готовым к использованию в соответствиb со своим функциональным назначением. Можно приступать непосредственно к обмену данными с устройством через заявленные конечные точки один (IN) и два (OUT), это так называемый РАБОЧИЙ РЕЖИМ. Поэтому после отправки дескриптора репорта и завершения транзакции (rcall w_nakout) выбирается для обмена конечная точка EP2 (ldi R16, 2 и sts UENUM, R16), и ей разрешается генерировать запрос на прерывание по приходу пакета OUT (lds R24, UEIENX, sbr R24, 1 << RXOUTE и sts UEIENX, R24). Далее происходит выход из обработчика прерывания в основной цикл сна (rjmp vihod_ep). Теперь вместо конечной точки EP0 источником прерываний у нас становится конечная точка EP2. Вспомним, что хост посылает запрос OUT, когда хочет передать нам данные, и делает это с интервалом, не превышающим указанный интервал в дескрипторе конечной точки.

И последнее замечание. Поскольку никакие запросы, кроме описанных здесь, от хоста не поступают, в программе они не принимаются и не обрабатываются. Однако, если неподдерживаемый запрос все же поступит (что не наблюдалось) - устройство отвечает на него маркером STALL (метки n_3 и n_4).

[РАБОЧИЙ РЕЖИМ]

Рабочий режим - основной режим работы нашего устройства, в котором реализуется его функционал. В этом режиме обмен происходит уже под управлением пользовательского приложения (ПО хоста). Пользовательское приложение это обычный исполняемый файл (.exe), который был написан в программной среде RadASM/MASM32 (среда разработки значения не имеет; это может быть Си, Delphi и т. д.).

Обмен с HID-устройством происходит по прерываниям/запросам от хоста (с определенным в дескрипторе конечной точки интервалом). В нашем случае после процедуры энумерации для первоначального обмена была выбрана EP2 (OUT) т. е. мы ожидаем от хоста запрос OUT. Когда он поступит, данные репорта уже находятся в буфере EP2, и мы их просто переписываем в регистры R3..R10. После этого выбирается конечная точка точку EP1 (IN), и от хоста ожидается уже запрос IN, по которому данные из регистров R3..R10 переписываются в буфер EP1, и далее отправляются хосту. Затем опять выбирается EP2, и весь процесс повторяется.

Назначение нашего демонстрационного ПО хоста состоит в том, чтобы передать устройству текущие координаты указателя мыши (OUT-репорт), принять их обратно от устройства (IN-репорт) и вывести в рабочую область окна программы. Внешний вид запущенного приложения (с подключенным устройством) показан на рис. 5.

Рис. 5. ПО хоста, работающее с устройством USB.

Здесь в левом верхнем углу рабочей области надпись Connected означает, что устройство, имеющее VID - 03EB (Atmel Corp.) и PID - 2013 (HID-Device), подключено к компьютеру. Правее этой надписи отображаются текущие координаты указателя мыши. В левом нижнем углу рабочей области мы видим все восемь байт IN-репорта, т. е. то, что мы получаем от устройства. Координаты указателя - последние четыре байта.

Передача координат указателя мыши происходит при нажатии на ее левую кнопку в пределах рабочей области приложения. Это действие приводит к формированию OUT-репорта и последующей его передаче (через драйвер) в устройство. Принятый устройством пакет OUT запускает обработчик прерываний USB_ENDPOINT, где выясняеется (в метке ep_2), что источником прерывания была конечная точка два (ЕР2), и происходит переход на метку ep_out. Здесь последовательно проверяется установка в единицу разряда RXOUTI - получен пакет OUT (команды lds R24, UEINTX и sbrs R24, 2) и разряда FIFOCON - данные пакета сохранены в банке ЕР2 (команда sbrs R24, 7). Затем сбрасывается разряд RXOUTI для подтверждения прерывания - команды lds R24, UEINTX, cbr R24, 1 << RXOUTI и sts UEINTX, R24. Сохраненные в буфере данные переписываются в регистры R3..R10 (lds R3, UEDATX, ..., lds R10, UEDATX) и сбрасывается разряд FIFOCON (команды lds R24, UEINTX, cbr R24, 1 << FIFOCON и sts UEINTX, R24).

Данные приняты. Координаты указателя мыши теперь размещены в регистрах R7..R10 следующим образом: R7 – младший байт координаты X, R8 - старший байт координаты X, R9 - младший байт координаты Y, R10 - старший байт координаты Y. Теперь, чтобы отправить координаты обратно хосту, при получении пакета IN нужно активировать конечную точку EP1 (команды ldi R16, 1 и sts UENUM, R16) и разрешить от нее прерывание (команды lds R24, UEIENX, ldi R24, 1 << TXINE и sts UEIENX, R24). Далее происходит возврат из обработчика прерывания в основной цикл сна (rjmp vihod_ep).

Приложение на компьютере написано таким образом, что через определенное время (примерно 20 .. 50 мс) после отправки OUT-репорта оно формирует запрос на получение данных от устройства - IN-репорт. Приход пакета IN от хоста выводит МК из режима сна, запускается переход на обработчик прерывания USB_ENDPOINT. Здесь происходит проверка, что прерывание было вызвано конечной точкой EP1 (команда cpi R24, 2) и происходит переход на метку ep_in (rjmp ep_in). По метке ep_in проверяется состояние разрядов FIFOCON и TXINI регистра UEINTX - команды lds R24, UEINTX, sbrs R24, 7 и sbrs R24, 0, единицы в которых говорят о том, что банк ЕР1 свободен, и получен пакет IN. Банк загружается данными, ранее полученными от хоста, из регистров R3..R10 (sts UEDATX, R3, ..., sts UEDATX, R10), затем последовательно сбрасываются разряды TXINI (команды lds R24, UEINTX, cbr R24, 1 << TXINI и sts UEINTX, R24) и FIFOCON (cbr R24, 1 << FIFOCON и sts UEINTX, R24). Если данные успешно отправлены, то разряды TXINI и FIFOCON аппаратно установятся в единицы, это проверяется в цикле по метке no_in. Теперь нужно ожидать новую порцию данных от хоста. Для этого разрешается прерывание по приходу пакета OUT (lds R24, UEIENX, ldi R24, 1 << RXOUTE и sts UEIENX, R24) и выбирается конечная точка EP2 (ldi R16, 2, sts UENUM, R16). Далее происходит выход из обработчика прерывания в основной цикл сна (rjmp vihod_ep).

;Демонстрационная реализация устройства USB HID на ассемблере для AT90USB162.
;Автор Каменяр Сергей <batonator@yandex.ru> (15 июля 2016 г.)
;Размер EP0=32 байта.
;.include "iousb162.h"
.include "usb162def.inc"
 
.CSEG

;------------------------------------------------
;Вектора сброса и обработчиков прерываний:
;------------------------------------------------
.ORG $000
   rjmp RESET
.ORG $016
   rjmp USB_GENERAL     ;обработка общих событий
.ORG $018
   rjmp USB_ENDPOINT    ;обработка прерывания конечной точки

EP0   EQU   EPNUM0      ;конечная точка управления
EP1   EQU   EPNUM1      ;конечная точка IN
EP2   EQU   EPNUM2      ;конечная точка OUT

CMD_USB_SET_ADDRESS        EQU   0x05
CMD_USB_GET_DESCRIPTOR     EQU   0x06

;------------------------------------------------
;Начало основной программы:
;------------------------------------------------
RESET:
   ldi R16, high(RAMEND)
   out SPH, R16
   ldi R16, low(RAMEND)
   out SPL, R16
   clr R1
   clr R2
   clr R25
   clr R26
 
   ldi R16, 0 << REGDIS
   sts REGCR, R16
 
   cli
   wdr
   in R16, MCUSR
   andi R16, (0xff & (0 << WDRF))
   out MCUSR, R16
   lds R16, WDTCSR
   ori R16, (1 << WDCE)|(1 << WDE)
   sts WDTCSR, R16
   ldi R16, (0 << WDE) 
   sts WDTCSR, R16
   ldi R16, 0x1F   ;00011111
   out DDRD, R16
   ldi R16, 0      ;00000000
   out PORTD, R16
   ldi R16, (0 << PLLP2)+(0 << PLLP1)+(1 << PLLP0)+(1 << PLLE)
   out PLLCSR, R16
bit_lock:
   in R16, PLLCSR
   sbrs R16, 0
   rjmp bit_lock
   lds R16, USBCON
   sbr R16, 1 << USBE
   sts USBCON, R16
   cbr R16, 1 << FRZCLK
   sts USBCON, R16
   lds R16, UDCON
   cbr R16, 1 << DETACH
   sts UDCON, R16
r_bus:
   lds R16, UDINT
   sbrs R16, 3
   rjmp r_bus
   cbr R16, 1 << EORSTI
   sts UDINT, R16
   rcall conf_ep_0
   lds R16, UDCON
   sbr R16, 1 << RSTCPU
   sts UDCON, R16
   ldi R24, (1 << SUSPE)+(1 << EORSTE)
   sts UDIEN, R24
   ldi R24, 1 << RXSTPE
   sts UEIENX, R24
   ldi R16, 1 << SE
   out SMCR, R16
   sei
SLP:
   sleep
   rjmp SLP
   
;------------------------------------------------
;Обработчик общих прерываний USB
;------------------------------------------------
USB_GENERAL:
   lds R24, UDINT 
   sbrs R24, 3
   rjmp next_ev_1
   cbr R24, 1 << EORSTI 
   sts UDINT, R24
   rjmp vihod_ug

next_ev_1:
   sbrs R24, 0
   rjmp next_ev_2
   cbr R24, 1 << SUSPI
   sts UDINT, R24
   lds R24, USBCON
   sbr R24, 1 << FRZCLK
   sts USBCON, R24
   in R16, PLLCSR
   cbr R16, 1 << PLLE
   out PLLCSR, R16
   lds R24, UDIEN
   sbr R24, 1 << WAKEUPE
   sts UDIEN, R24
   rjmp vihod_ug
   
next_ev_2:
   sbrs R24, 4
   rjmp vihod_ug
   in R16, PLLCSR
   sbr R16, 1 << PLLE
   out PLLCSR, R16
lock_bit:
   in R16, PLLCSR
   sbrs R16, 0
   rjmp lock_bit
   lds R24, USBCON 
   cbr R24, 1 << FRZCLK 
   sts USBCON, R24
   lds R24, UDINT
   cbr R24, 1 << WAKEUPI
   sts UDINT, R24
   lds R24, UDIEN
   cbr R24, 1 << WAKEUPE
   sts UDIEN, R24
   sts UENUM, R1
   inc R2
vihod_ug:
   reti

;------------------------------------------------
; Обработчик прерывания конечной точки 
;------------------------------------------------
USB_ENDPOINT:
   lds R24, UEINT
   cpi R24, 1 << EP0
   brne ep_1
   rjmp ep_0

ep_1:
   cpi R24, 1 << EP1
   brne ep_2
   rjmp ep_in

ep_2:
   cpi R24, 1 << EP2
   brne ep_no
   rjmp ep_out

ep_no:
   rjmp vihod_ep

ep_0:
; Управляющая конечная точка
   lds R17, UEDATX
   lds R16, UEDATX

   cpi R16, CMD_USB_GET_DESCRIPTOR
   brne next_0
   rjmp get_dsc

next_0:
   cpi R16, CMD_USB_SET_ADDRESS
   brne next_1
   rjmp set_adr

next_1:
   cpi R16, 0x09
   brne next_2
   cpi R17, 0x00
   brne next_2
   rjmp set_cfg
   
next_2:
   cpi R16, 0x0A
   brne next_3
   cpi R17, 0x21
   brne next_3
   rjmp set_idle

next_3:
   rjmp n_3

get_dsc:
   cpi R17, 0x80         ;Get_Stand_device
   brne sl_1
   rjmp stand_desc

sl_1:
   cpi R17, 0x81
   brne sl_2
   rjmp int_desc
   
sl_2:
   rjmp vihod_ep
   
stand_desc:
   rcall read_buff
   cpi R19, 1
   brne n_1
   rjmp d_dev

n_1:
   cpi R19, 2
   brne n_2
   rjmp d_con

n_2:
   cpi R19, 3
   brne n_4
   rjmp d_str
   
n_3:
   lds R24, UEINTX
   cbr R24, 1 << RXSTPI
   sts UEINTX, R24
n_4:
   lds R24, UEINTX
   sbrs R24, 0
   rjmp n_4
   lds R24, UECONX
   sbr R24, 1 << STALLRQ
   sts UECONX, R24
   rjmp vihod_ep

d_dev:
   lds R24, UEINTX
   sbrs R24, 0
   rjmp d_dev
   ldi R31, high(dev_desc*2)
   ldi R30, low(dev_desc*2)
out_data_d:
   lpm R24, Z+
   sts UEDATX, R24
   cpi R30, 18
   brne out_data_d
   lds R24, UEINTX
   cbr R24, 1 << TXINI
   sts UEINTX, R24
   rcall w_nakout
   rjmp vihod_ep

d_con:
   lds R24, UEINTX
   sbrs R24, 0
   rjmp d_con
   ldi R31, high(con_desc*2)
   ldi R30, low(con_desc*2)
   clr R23
   cpi R22, 9
   breq con_drv
out_dat_c:
   lpm R24, Z+
   sts UEDATX, R24
   inc R23
   cpi R23, 32
   brne out_dat_c
   lds R24, UEINTX
   cbr R24, 1 << TXINI
   sts UEINTX, R24
d_con_1:
   lds R24, UEINTX
   sbrs R24, 0  
   rjmp d_con_1
out_dat_c1:
   lpm R24, Z+
   sts UEDATX, R24
   inc R23
   cpi R23, 41
   brne out_dat_c1
   lds R24, UEINTX
   cbr R24, 1 << TXINI
   sts UEINTX, R24
   rcall w_nakout
   rjmp vihod_ep
   
con_drv:
   lpm R24, Z+
   sts UEDATX, R24
   inc R23
   cpi R23, 9
   brne con_drv
   lds R24, UEINTX
   cbr R24, 1 << TXINI
   sts UEINTX, R24
   rcall w_nakout
   rjmp vihod_ep

d_str:
   cpi R18, 0
   brne s_1
   ldi R31, high(str_0*2)
   ldi R30, low(str_0*2)
   ldi R20, 4
   rjmp d_str_1

s_1:
   cpi R18, 1
   brne s_2
   ldi R31, high(str_1*2)
   ldi R30, low(str_1*2)
   ldi R20, 12
   rjmp d_str_1

s_2:
   cpi R18, 2
   brne s_3
   ldi R31, high(str_2*2)
   ldi R30, low(str_2*2)
   ldi R20, 32
   rjmp d_str_1

s_3:
   cpi R18, 3
   brne s_4
   ldi R31, high(str_3*2)
   ldi R30, low(str_3*2)
   ldi R20, 10
   rjmp d_str_1

s_4:
   rjmp vihod_ep

d_str_1:
   lds R24, UEINTX 
   sbrs R24, 0
   rjmp d_str_1
out_st:
   lpm R24, Z+
   sts UEDATX, R24
   dec R20
   brne out_st
   lds R24, UEINTX
   cbr R24, 1 << TXINI
   sts UEINTX, R24
   cpi R18, 2
   breq d_str_2
   rcall w_nakout
   rjmp vihod_ep

d_str_2:
   lds R24, UEINTX
   sbrs R24, 0
   rjmp d_str_2
out_st_1:
   lpm R24, Z+
   sts UEDATX, R24
   inc R20
   cpi R20, 2
   brne out_st_1
   lds R24, UEINTX
   cbr R24, 1 << TXINI
   sts UEINTX, R24
   rcall w_nakout
   rjmp vihod_ep

int_desc:
   rcall read_buff
   cpi R19, 0x22
   breq n_5
   rjmp vihod_ep

n_5:
   cpi R22,0x62
   breq d_rep_1
   rjmp vihod_ep

d_rep_1:
   sbi PORTD, 4
   lds R24, UEINTX
   sbrs R24, 0
   rjmp d_rep_1
   clr R23
   ldi R31, high(rep_desc*2)
   ldi R30, low(rep_desc*2)
out_dat_r:
   lpm R24, Z+
   sts UEDATX, R24
   inc R23
   cpi R23, 32
   brne out_dat_r
   lds R24, UEINTX
   cbr R24, 1 << TXINI
   sts UEINTX, R24
d_rep_2:
   lds R24, UEINTX   
   sbrs R24, 0 
   rjmp d_rep_2
out_dat_r1:
   lpm R24, Z+
   sts UEDATX, R24
   inc R23
   cpi R23, 34
   brne out_dat_r1
   lds R24, UEINTX
   cbr R24, 1 << TXINI
   sts UEINTX, R24
   rcall w_nakout
   ldi R16, 2
   sts UENUM, R16
   ldi R24, 1 << RXOUTE
   sts UEIENX, R24
   rjmp vihod_ep

ep_out:
   lds R24, UEINTX
   sbrs R24, 2           ;RXOUTI
   rjmp ep_out
   sbrs R24, 7           ;FIFOCON
   rjmp ep_out
   lds R24, UEINTX
   cbr R24, 1 << RXOUTI
   sts UEINTX, R24
   lds R3, UEDATX
   lds R4, UEDATX
   lds R5, UEDATX
   lds R6, UEDATX
   lds R7, UEDATX
   lds R8, UEDATX
   lds R9, UEDATX
   lds R10, UEDATX
   lds R24, UEINTX
   cbr R24, 1 << FIFOCON
   sts UEINTX, R24
   ldi R16, 1
   sts UENUM, R16
   ldi R24, 1 << TXINE
   sts UEIENX, R24
   rjmp vihod_ep 

ep_in:
   lds R24, UEINTX
   sbrs R24, 7       ;FIFOCON
   rjmp ep_in
   sbrs R24, 0       ;TXINI
   rjmp ep_in
   sts UEDATX, R3
   sts UEDATX, R4
   sts UEDATX, R5
   sts UEDATX, R6
   sts UEDATX, R7
   sts UEDATX, R8
   sts UEDATX, R9
   sts UEDATX, R10
   lds R24, UEINTX
   cbr R24, 1 << TXINI
   sts UEINTX, R24
   cbr R24, 1 << FIFOCON
   sts 0x00E8, R24
no_in:
   lds R24, UEINTX
   sbrs R24, 0       ;TXINI
   rjmp no_in
   sbrs R24, 7       ;FIFOCON
   rjmp no_in
   ldi R24, 1 << RXOUTE
   sts UEIENX, R24
   ldi R16, 2
   sts UENUM, R16
   rjmp vihod_ep

set_adr:
   lds R24, UEDATX  
   andi R24, 0x7F
   sts UDADDR, R24  
   lds R24, UEINTX  
   cbr R24, 1 << RXSTPI
   sts UEINTX, R24
   lds R24, UEINTX
   sbrs R24, 0   
   rjmp vihod_ep
   cbr R24, 1 << TXINI
   sts UEINTX, R24
vt:
   lds R24, UEINTX
   sbrs R24, 0
   rjmp vt
   lds R24, UDADDR
   ori R24, 0x80
   sts UDADDR, R24
   rjmp vihod_ep

set_cfg:
   lds R24, UEINTX
   cbr R24, 1 << RXSTPI
   sts UEINTX, R24
s_cfg:
   lds R24, UEINTX
   sbrs R24, 0
   rjmp s_cfg
   cbr R24, 1 << TXINI
   sts UEINTX, R24
   ldi R16, 1
   sts UENUM, R16
   lds R16, UECONX  
   sbrs R16, 0
   ori R16, 0x01
   sts UECONX, R16 
   ldi R16, (1 << EPTYPE1)+(1 << EPTYPE0)+(1 << EPDIR)
   sts UECFG0X, R16
   ldi R16, 0x02
   sts UECFG1X, R16
test_c_ep1:
   lds R16, UESTA0X 
   sbrs R16, 7 
   rjmp test_c_ep1
   ldi R16, 2
   sts UENUM, R16
   lds R16, UECONX
   sbrs R16, 0
   ori R16, 0x01
   sts UECONX, R16
   ldi R16, (1 << EPTYPE1)+(1 << EPTYPE0)+(0 << EPDIR)
   sts UECFG0X, R16 
   ldi R16, 0x02
   sts UECFG1X, R16
test_c_ep2:
   lds R16, UESTA0X
   sbrs R16, 7 
   rjmp test_c_ep2
   sts UENUM, R1  
   rjmp vihod_ep

set_idle:
   lds R24, UEINTX 
   cbr R24, 1 << RXSTPI
   sts UEINTX, R24
   lds R24, UEINTX
   sbrs R24, 0   
   rjmp vihod_ep
   cbr R24, 1 << TXINI
   sts UEINTX, R24
   tst R2
   breq vihod_ep
   clr R2
   ldi R16, 2
   sts UENUM, R16
vihod_ep:
   reti

conf_ep_0:
   sts UENUM, R1
   lds R16, UECONX  
   sbrs R16, 0
   ori R16, 0x01
   sts UECONX, R16
   ldi R16, (0 << EPTYPE1)+(0 << EPTYPE0)+(0 << EPDIR)
   sts UECFG0X, R16
   ldi R16, 0x22
   sts UECFG1X, R16
test_c_ep0:
   lds R16, UESTA0X
   sbrs R16, 7           ;если CFGOK=1 - EP0 сконфигурирована - идем дальше.
   rjmp test_c_ep0
   ret

w_nakout:
   lds R24, UEINTX
   sbrs R24, 4
   rjmp w_nakout
   cbr R24, 1 << NAKOUTI
   sts UEINTX, R24
w_out:
   lds R24, UEINTX
   sbrs R24, 2
   rjmp w_out
   cbr R24, 1 << RXOUTI
   sts UEINTX, R24
   ret

read_buff:
   lds R18, UEDATX    ;String_type
   lds R19, UEDATX    ;Desc_type=01
   lds R20, UEDATX    ;Dummy_byte
   lds R21, UEDATX    ;Dummy_byte
   lds R22, UEDATX    ;LSB(wLength)
   lds R23, UEDATX    ;MSB(wLength)
   lds R24, UEINTX
   cbr R24, 1 << RXSTPI
   sts UEINTX, R24
   ret
   
.ORG $300
dev_desc:
   .DB 0x12,0x01,0x00,0x02,0x00,0x00,0x00,0x20,0xEB,0x03
   .DB 0x13,0x20,0x00,0x10,0x01,0x02,0x03,0x01
con_desc:
   .DB 0x09,0x02,0x29,0x00,0x01,0x01,0x00,0x80,0x32,0x09
   .DB 0x04,0x00,0x00,0x02,0x03,0x00,0x00,0x00,0x09,0x21
   .DB 0x00,0x01,0x00,0x01,0x22,0x22,0x00,0x07,0x05,0x81
   .DB 0x03,0x08,0x00,0x0F,0x07,0x05,0x02,0x03,0x08,0x00
   .DB 0x0F
str_0:
   .DB 0x04,0x03,0x09,0x04
str_1:
   .DB 0x0C,0x03,0x41,0x00,0x54,0x00,0x4D,0x00,0x45,0x00
   .DB 0x4C,0x00
str_2:
   .DB 0x22,0x03,0x41,0x00,0x56,0x00,0x52,0x00,0x20,0x00
   .DB 0x55,0x00,0x53,0x00,0x42,0x00,0x20,0x00,0x48,0x00
   .DB 0x49,0x00,0x44,0x00,0x20,0x00,0x44,0x00,0x45,0x00
   .DB 0x4D,0x00,0x4F,0x00
str_3:
   .DB 0x0A,0x03,0x30,0x00,0x30,0x00,0x30,0x00,0x30,0x00
rep_desc:
   .DB 0x06,0x00,0xFF,0x09,0x00,0xA1,0x01,0x09,0x00,0x15
   .DB 0x00,0x26,0xFF,0x00,0x75,0x08,0x95,0x08,0x81,0x02
   .DB 0x09,0x00,0x15,0x00,0x26,0xFF,0x00,0x75,0x08,0x95
   .DB 0x08,0x91,0x02,0xC0

.EXIT

[Словарик]

ADC Analog-to-Digital Converter, АЦП, аналого-цифровой преобразователь.

bit stuffing вставка бит по специальному алгоритму в последовательном потоке бит на линии. Применяется для целей синхронизации или уменьшения/устранения постоянной составляющей в сигнале.

bus powered devices устройства USB, получающие питание +5V от шины USB (линия VBUS). Питающее напряжение на линии VBUS формирует хост.

daisy chained термин, относящийся к линейной (иногда кольцевой) топологии сети. Иногда такую топологию называют шлейфовой. Дословный перевод daisy chain – "цепочка маргариток", что означает венок из маргариток.

downstream нисходящее соединение. Такое соединение имеет место для хоста по отношению к устройству USB.

Endpoint, конечная точка специфическое понятие стандарта USB, символизирующее источник или приемник потока данных.

EPx EndPoint (конечная точка) номер x.

errata исправления, добавления к стандарту.

Feature фича, какая-нибудь возможность (особенность) устройства.

Feature Selector селектор фичи, число, от которого зависит выбор какой-нибудь возможности (особенности) устройства.

FLASH энергонезависимая память для хранения программ или данных.

FrameWork фреймворк, рабочая среда, рабочее окружение.

handshaking "рукопожатие", процедура установления связи.

Host хост, главное устройство на шине. Обычно это компьютер.

ICD In Circuit Debug, внутрисхемная отладка.

ISR Interrupt Service Routine, подпрограмма обработки прерывания.

ISP In-System Programming, программирование в системе. Так называется последовательный интерфейс программирования микроконтроллера.

Latency латентность, время ожидания на обработку, время задержки.

LDO regulator, Low Dropout регулятор, имеющий маленькое падение напряжения, достаточное для нормальной работы (стабилизации).

LSB Least Significant Byte, младший значащий байт. Иногда, в зависимости от контекста, это может относиться к биту, т. е. будет означать младший значащий бит.

MSB Most Significant Byte, старший значащий байт. Иногда, в зависимости от контекста, это может относиться к биту, т. е. будет означать старший значащий бит.

OTP ROM однократно программируемая память (обычно для программы).

Padding дополнение байтами до нужного количества (обычно нулевыми байтами).

payload полезная нагрузка, передаваемые в потоке данные.

PCB печатная плата.

peer-to-peer возможность обмена данными между равноправными устройствами.

Pipe(s) буквальный перевод "труба" ("трубы"). Означает специальным образом сформированные частные потоки данных через интерфейс USB. Иногда pipe называют каналом.

plug штеккер, коннектор на конце кабеля или на торце устройства USB (например, флешки). Этот коннектор втыкается в сокет, который обычно ставится на корпусе устройства (компьютера или периферии USB).

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

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

self powered devices устройства USB, питающиеся от отдельного источника (не от шины USB).

socket сокет, разъем на корпусе компьютера или периферии USB, куда втыкается plug (коннектор).

status reporting получение информации о статусе устройства.

tiered star топология многоярусная звезда.

token символ.

Token Packet символ, показывающий, какие дальше идут данные.

trade-off компромисс.

upstream восходящее соединение. Такое соединение имеет место для устройства USB по отношению к хосту.

Автор: Каменяр Сергей, batonator@yandex.ru.

[Ссылки и литература]

1. Чекунов Д. Программисту USB-устройств.
2. Немоляев А.В. Популярно о USB.
3. Агуров П.В. - Интерфейс USB. Практика использования и программирования.
4. Макетная плата AVR-USB162.
5. Ю. Магда. Ассемблер. Разработка и оптимизация Windows-приложений.
6. V-USB - A Firmware-Only USB Driver for Atmel AVR Microcontrollers site: obdev.at.
7. USB in a NutShell - путеводитель по стандарту USB.
8. LUFA - бесплатная библиотека USB для микроконтроллеров Atmel AVR.
9. Библиотеки для управления устройствами USB HID.
10. Engbedded Atmel AVR® Fuse Calculator site:engbedded.com.
11. Как настроить RadAsm под MASM32 site:devprog.wordpress.com.