[osnwt 0]

Привет всем!

 

Возникло желание сделать HID-совместимое устройство на AVR с программно реализованным USB стеком. Тем более, что появилась отличная открытая и бесплатная реализация стека, написанная на C (кроме критического по времени куска - тот на асме) и документированная на предмет возможностей и ограничений. Буквально 5 дней назад вышла версия с поддержкой HID девайсов, сэкономив мне кучу времени.

 

В общем, примеры все работают. И свое устройство, в целом, тоже работает. Проблема лишь с написанием HID Report Descriptor для этой штуки. Это просто какое-то шаманство. Скажем, есть работающий report. В начале стоит левый LOGICAL MINIMUM (0), который не нужен, ибо перед первым же INPUT определены свои minimum и maximum. Стоит его убрать - всё, винды видят устройство с ошибкой.

 

Пример два: стоит в работающем дескрипторе REPORT ID (1). Всё работает. Убираю REPORT ID, уменьшаю на 1 количество байтов в возвращаемых данных (поскольку первый байт исчез), правлю длину дескриптора (так как два байта на REPORT ID тоже ушло). Компилирую, прошиваю, включаю - не работает.

 

Перерыл весь инет. Все ссылаются на HID Descriptor Tools с usb.org. Интерфейс там еще тот, но ладно. Проверка ошибок там бестолковая, конечно. Винды более критичны к этому. Но другого-то инструмента нет. Перечитал все доки, нигде нет конкретных указаний. В материалах с usb.org сплошные should или may.

 

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

 

Собственно, вопросы к уважаемой публике:

 

1) можно ли где-то посмотреть диагностику виндовского HID parser'а: что конкретно его не устраивает в предлагаемых ему дескрипторах?

 

2) есть ли какие-либо решения для создания дескрипторов наподобие HID Descriptor Tools, но дающие более-менее работоспособные под Windows варианты?

 

Не верится, что проблема кроется где-то в софтверной реализации. Ибо, сначала не мог поднять количество байтов выше 2-х в interrupt transfer. Думал, что бага в библиотеке. Но потом из рабочего кода взял другой дескриптор с 7-ю байтами - и тоже всё работает до первой правки.

 

В общем, мистика! Help!

[osnwt 0]

Чтобы говорить конкретнее, вот один из примеров. Этот дескриптор работает:

 

#define USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH    (57)  /* total length of report descriptor */

#define USB_HID_REPORT_SIZE     7

static uchar    reportBuffer[USB_HID_REPORT_SIZE];  /* buffer for HID reports */

const char usbHidReportDescriptor[USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH] PROGMEM =
{
    0x05, 0x01,                    // USAGE_PAGE (Generic Desktop)
    0x15, 0x00,                    // LOGICAL_MINIMUM (0)
    0x09, 0x04,                    // USAGE (Joystick)
    0xa1, 0x01,                    // COLLECTION (Application)
    0x85, 0x01,                    //   REPORT_ID (1)
    0x09, 0x01,                    //   USAGE (Pointer)
    0xa1, 0x00,                    //   COLLECTION (Physical)
    0x09, 0x30,                    //     USAGE (X)
    0x09, 0x31,                    //     USAGE (Y)
    0x15, 0x81,                    //     LOGICAL_MINIMUM (-127)
    0x25, 0x7f,                    //     LOGICAL_MAXIMUM (127)
    0x75, 0x08,                    //     REPORT_SIZE (8)
    0x95, 0x02,                    //     REPORT_COUNT (2)
    0x81, 0x02,                    //     INPUT (Data,Var,Abs)
    0x05, 0x02,                    //     USAGE_PAGE (Simulation Controls)
    0x09, 0xba,                    //     USAGE (Rudder)
    0x09, 0xbb,                    //     USAGE (Throttle)
    0x81, 0x02,                    //     INPUT (Data,Var,Abs)
    0xc0,                          //     END_COLLECTION
    0x16, 0x01, 0xfe,              //   LOGICAL_MINIMUM (-511)            <------------
    0x05, 0x01,                    //   USAGE_PAGE (Generic Desktop)
    0x09, 0x36,                    //   USAGE (Slider)
    0x09, 0x37,                    //   USAGE (Dial)
    0x15, 0x81,                    //   LOGICAL_MINIMUM (-127)
    0x25, 0x7f,                    //   LOGICAL_MAXIMUM (127)
    0x75, 0x08,                    //   REPORT_SIZE (8)
    0x95, 0x02,                    //   REPORT_COUNT (2)
    0x81, 0x02,                    //   INPUT (Data,Var,Abs)
    0xc0                           // END_COLLECTION
};

 

Достаточно убрать ненужный совершенно

     0x16, 0x01, 0xfe,              //   LOGICAL_MINIMUM (-511)            <------------

 

и соответственно подправить длину дескриптора с

#define USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH    (57)  /* total length of report descriptor */

на

#define USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH    (54)  /* total length of report descriptor */

 

и всё. :blink:

 

Может, кто видит в этом криминал, типа там, выравнивание на границу слова или т.п.? Если да, то какой именно? У меня уже идей нет, двое суток непрерывно долбаюсь с таким моментом, которого вообще, по идее, и быть не должно.

[osnwt 0]

Не верится, что проблема кроется где-то в софтверной реализации.

...

В общем, мистика!

Ладно, никто не отвечает - отвечу себе сам :-)

 

Проблема решена. Оказалось, что Makefile, идущий в примерах проектов, не учитывает зависимостей скомпилированной USB библиотеки от файла USB конфигурации проекта. Зависимость основного приложения от него я вставил сразу, а про библиотеку забыл совсем. В результате получалось внетренее несоответствие скомпилированных объектников, а в итоге - неработоспособный код.

 

Сейчас все работает прекрасно. Вопрос снят, тема закрыта. :cheers:

[GDI 0]

А можно ссылочку на эту библиотеку?

[osnwt 0]

Я всё ждал, когда кто-нибудь спросит :)

 

Можно, конечно - A Firmware-Only USB Driver for Atmel AVR Microcontrollers, Objective Development Software GmbH.

 

Там же несколько готовых референс-проектов с исходниками для AVR и PC, а также интересная статья о том, как удалось реализовать NRZI декодирование и BitStuffing на лету в реальном времени (в отличие от известных ассемблерных реализаций), использовав на каждый бит ровно 8 из 8 имеющихся циклов!

 

Так что теперь вставить поддержку USB в устройство на меге за $2 становится совсем простым делом. Отличная работа, спасибо ребятам!

Изменено 14 февраля, 2006 пользователем osnwt

[GDI 0]

Спасибо.

[unichorn 0]

Да вот здесь лежит интересная книга "Интерфейс USB"

http://lord-n.narod.ru/walla.html

Только что скачал. :)

[osnwt 0]

Хорошая книжка, спасибо.

 

Вчера была пара часов времени, попробовал портировать библиотеку под IAR-овский компилятор с ассемблером (у меня всё остальное пишется в нём, а иметь несколько компайлеров неудобно). Пока не сильно преуспел. Правда, времени копать глубже не было. Добился лишь того, что она стала компилироваться, и поменял calling convention ассеблерных фрагментов (gcc и iar по разному используют регистры). Пока не заработала, но я по серьезному за нее еще не брался.

 

А интересно то, что один и тот же исходный текст дал под gcc 3.4.5 с оптимизацией по размеру (-Os) на 100 байтов меньший код, чем компилятор IAR 4.10 при такой же максимальной оптимизации по всем параметрам. Если учесть, что около 900 байтов из 2500 занимает ассемблерный модуль, который размер не поменяет никак, а еще довольно много занимают дескрипторы в виде таблиц, то разница в более чем 5% в пользу gcc меня очень поразила. Не так давно IAR славился своей оптимизацией кода. А сейчас наблюдаю совершенно обратную картину. Спросонья (в 3 часа ночи) даже не поверил своим глазам, буду смотреть еще.

[grave 0]

Кто-то уже реализовал USB HID Keypad на меге? Было бы интересно взглянуть.

[osnwt 0]

Кто-то уже реализовал USB HID Keypad на меге? Было бы интересно взглянуть.

Keypad я не делал - делал стандартный HID игровой манипулятор типа "Джойстик с 8-ю осями, 24 кнопками и hat switch". Тема эта популярна на форуме http://sukhoi.ru, где любители полетать на MS Flight Simulator и других симуляторах оборудуют такими устройствами свои домашние пилотские кабины со штурвалами и педалями. Правда, до сих пор писали на ассемблере под мегу 8 или 16. Входы - кнопки и АЦП контроллера.

Я же макетировал и такой вариант, и вариант для моделистов (см. форум http://rcdesign.ru): подключение стандартной PPM/PCM радиоаппаратуры управления моделями через USB адаптер к системе. В данном случае в качестве входного сигнала используется выход передатчика (низкочастотный модулирующий), из которого выделяются сигналы каналов, кои и передаются по USB. В данном варианте HID-устройство представляло собой как стандартный джойстик, так и просто "HID-совместимое устройство", необходимое для работы одному из популярных симуляторов моделей вертолетов и самолетов.

 

Исходников не привожу, так как задача там тривиальна, а примеры хорошо комментированы. ADC в одном случае и Input Capture во втором.

 

На очереди - макетирование двухстороннего обмена с созданным устройством для управления конфигурацией (чтение/запись), после чего - вариант USB crypto boot loader'а по тому же USB каналу, что и работа основного устройства. Задача реализуема (собственно, половина уже написана, но пока нет времени на завершение). Основа: исходники HID устройства плюс appnotes от Atmel. Плюс утилиты со стороны PC, работающие с USB для конфигурирования и перешивки firmware (тоже частично написаны).

 

Так что в работоспособности HID-keypad сомнений нет, но в одной из схем на obdev.at я видел ошибку - там были перепутаны D+ и D-. На какой - навскидку не помню.

[d71 0]

! а как я раньше туму не увидел, именно интересует iar реализация

сего проекта:

папа - моделист очень просит 20 осей и тыщу кнопок....

[lazycamel 0]

! а как я раньше туму не увидел, именно интересует iar реализация

сего проекта:

папа - моделист очень просит 20 осей и тыщу кнопок....

 

А 100 тысяч мульёнов уже не надо ? :-)

 

Вы все-таки не забывайте, что пакеты у этой реализации только 8 байт максимум.

 

И при частоте опроса девайса 125Гц передача даже 20 8-битных осей вызовет время реакции системы 1/40 сек.

 

По собственному опыту знаю что для джойстиков на этой реализации 2-3 пакета (14-21 байт данных) это уже грань за которой начинаются ощутимые задержки.

Изменено 27 февраля, 2006 пользователем lazycamel

[d71 0]

насколько я знаю 4 оси это только плоскости, наверно еще 2 осея на газ и еще что-то

кнопок там нету :)

[osnwt 0]

именно интересует iar реализация

сего проекта

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

 

Вы все-таки не забывайте, что пакеты у этой реализации только 8 байт максимум.

 

И при частоте опроса девайса 125Гц передача даже 20 8-битных осей вызовет время реакции системы 1/40 сек.

Можно, в принципе, передавать данные бОльшими блоками (не путать блок с USB транзакцией: один блок может передаваться в несколько транзакций). 10 мс - это минимальный заказанный период опроса устройства на предмет наличия данных для Interrupt Transfer, через который HID манипуляторы отдают данные. И 8 байтов - это действительно предел для Interrupt Transfer для low-speed devices.

 

Другой вопрос, что при этом теряется основное достоинство такой реализации: установка в системе как стандартный HID манипулятор без драйверов и фильтров. А если писать свой драйвер, выполняющий чтение блоков данных через Control Transfer вместо Interrupt, то смысл всей идеи теряется. Проще тогда взять аппаратно реализованный USB 2.0 на каком-нибудь недорогом контроллере.

[Roy 0]

Да вот здесь лежит интересная книга "Интерфейс USB"

http://lord-n.narod.ru/walla.html

Только что скачал. :)

 

Что-то я не нашел там этой книжки :-(