Делаем AVR USB (software) правильно, уровень схемы Опции

[MAXvaLL]

При реализации софтварного USB на AVR возникают вопросы. Как сделать правильно?

Видел варианты:

1. МК питается 5В от шины. D+ и D- напрямую к МК через резисторы ~ 200 Ом. D- подтянута на +5В через резистор ~10кОм.
Проблемы: по спецификации USB макс. допустимый уровень сигнала относительно земли 4.6В (или даже меньше) Смотрим USB2.0 Spec. Figure 7-2. Maximum Input Waveforms for USB Signaling
Можно спалить порт.

2. То же что и 1. , но дополнительно на D+ и D- поставлены стабилитроны на 3.6В (на землю), а вместо резисторов на 200 Ом стоят по 68 Ом.
Проблема: емкость стабилитронов - искажение формы сигнала. И всеравно будут выбросы.

3. МК питается от 3.3-3.6В от шины через стабилизатор или 2 диода. Подтяжка D- 1.5 кОм. На D+ и D- стоят резисторы по 68 Ом или вообще без резисторов.
Проблема: Минимальная необходимая частота 12 Мгц, а при использовании внутреннего генератора 16.5 Мгц. Насколько корректно гонять МК на такихз частотах при таком питании? В даташите как-то туманно про это написано: на титульной странице одно, на графиках другое, и ничего конкретного я так и не нашел.


Лично я использовал вариант 3. МК ATmega8 при кварце 12МГц. Работает.
Интересует заведется ли Tiny25 на 16.5 Мгц при питании 3.5-3.6В ?

Еще: атмел советует не гонять встроенный ацп быстрее 1 МГц (тактирование)
Я запустил при 3х Мгц. Работает. Насколько это корректно? (Полученная точность устраивает)

[Dimonira]

Имхо самое правильное, это использовать то, что специально предназначено для интерфейса USB. Всё остальное уже в той или иной степени "неправильно" априори.
То же самое я бы сказал и про работу в нерекомендуемых режимах.
Лучше сразу взять то, что сможет штатно обеспечить ваши требования. Неужели вам не хватает из чего выбрать?

[ukpyr]

Минимальная необходимая частота 12 Мгц, а при использовании внутреннего генератора 16.5 Мгц.

8 МГц гарантируеся при 2.7В. 3.6 выше на 1 вольт, так что 12 МГц должно работать без проблем. 16 МГц - сомневаюсь (разве что кристаллы произведенные по новой технологии).

[MAXvaLL]

Имхо самое правильное, это использовать то, что специально предназначено для интерфейса USB. Всё остальное уже в той или иной степени "неправильно" априори.
То же самое я бы сказал и про работу в нерекомендуемых режимах.
Лучше сразу взять то, что сможет штатно обеспечить ваши требования. Неужели вам не хватает из чего выбрать?

Это понятно. Но это излишества для данного случая. Но ведь делают ТАК, и работает. Вопрос в том что менее неправильно =)

Вариант 3 например вообще ничем не плох для USB ИМХО.

Кто уточнит, какой вольтаж жрет USB?

[ukpyr]

Кто уточнит, какой вольтаж жрет USB?

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

[MAXvaLL]

имхо лучше не превышать 3.6В, т.е. с двумя диодами - самая правильная схема.

Ограничивать уровень стабилитронами - жестоко по отношению к ногам контроллера.

Я согласен! Но, как я уже говорил, возникает проблема работы МК на высоких частотах при таком питании, а это необходимо!

Это почему? По отношению к МК стабилитроны ставят ПОСЛЕ резисторов, а ЮСБ пофиг, оно всеравно не должно выдавать больше 3.6 В.

-------------------------

Если верить графикам в ДШ на тини х5, при 3.3В гарантируют работу до 13МГц, а при 4В до 17МГц.
Так что шанс что работать будет на 16.5МГц от 3.6В есть, но с некоторой натяжкой...
Только вот где взять эти 3.6В? Диоды низя, т.к. если с юсб придет чуть меньше 5В, то питание МК упадет, а оно и так на пределе...

Все же, чем плох вариант со стабилитронами??? (Если искажение формы не критично)

Кстати, что-то я раньше не обращал внимания, но тут
http://www.cesko.host.sk/IgorPlugUSB/IgorP...20(AVR)_eng.htm
тоже разновидность варианта 1. Но резисторы по 68Ом, да еще и подтяжка 1.5кОм от 5В
Удивительно, как это работает =)

[Jhohn]

Все же, чем плох вариант со стабилитронами??? (Если искажение формы не критично)

Стабилитрон не надежный, у него разброс будет напряжения стабилизации, и в серийном производстве не годится. + потребление большое.

Кто уточнит, какой вольтаж жрет USB?

ой, не помню, 0.2 А точно выдержит, максимум вроде 0.5 А что-то так, а точнее читай: " Павел Агуров - Интерфейс USB.djvu " там все есть

Сообщение отредактировал Jhohn - Nov 28 2008, 20:28

[Petka]

При реализации софтварного USB на AVR возникают вопросы. Как сделать правильно?

Делаем AVR USB (softvare) правильно

для начала надо выбрать:
1) профессиональное решение
2) любительское решение
если (1), то проще и дешевле использовать МК к USB на борту. Или внешнюю микросхему с USB.
если (2), то правильно так, как работает "на коленке".

[Jhohn]

для начала надо выбрать:
1) профессиональное решение
если (1), то проще и дешевле использовать МК к USB на борту. Или внешнюю микросхему с USB.

+ надежность

[acorn]

Кто уточнит, какой вольтаж жрет USB?

Ты про ток? Вольтаж-то оно не жрет, а дает по питанию 5В, сигналы - 3х вольтовые. Брать по питанию можно до 500мА, но об этом нужно попросить хост. Чтобы попросить, нужно пройти enumeration потребляя при этом не более 20мА. По умолчанию 100мА дадут.

[MAXvaLL]

для начала надо выбрать:
1) профессиональное решение
2) любительское решение
если (1), то проще и дешевле использовать МК к USB на борту. Или внешнюю микросхему с USB.
если (2), то правильно так, как работает "на коленке".

Я уже ответил на подобное предложение выше. Не надо читать морали, я попросил ответ на поставленный вопрос. Вы вообще в жизни все делаете ПРАВИЛЬНО? Может у вас была лицинзионная винда лет 10 назад? (не корпоративная)

Мне надо сделать 2 устройства, но это не значит что абы-как.

Ставить ФТДИ просто смешно для данного проекта и не оправданно.

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

Между прочим, скажите, чем вариант 3 при правильной реализации хуже хардварного ЮСБ? Только не надо махать руками и говорить что это любительское решение. Мне пожалуйста факты изложите.

Стабилитрон не надежный, у него разброс будет напряжения стабилизации, и в серийном производстве не годится. + потребление большое.
ой, не помню, 0.2 А точно выдержит, максимум вроде 0.5 А что-то так, а точнее читай: " Павел Агуров - Интерфейс USB.djvu " там все есть

А кому какое дело до этого разброса? По спецификации напряжение должно быть больше 2.8В и меньше 3.6В. Если ваши стабилитроны в это требование не укладываются, то думаю есть смысл сменить поставщика =)))

Почему потребление больше? ток ограничивают резисторами, ну да, немного больше, но опять-таки кому до этого дело (10мА больше или меньше?)

А про ток разговора не было... Именно, 500мА макс.

Ты про ток? Вольтаж-то оно не жрет, а дает по питанию 5В, сигналы - 3х вольтовые. Брать по питанию можно до 500мА, но об этом нужно попросить хост. Чтобы попросить, нужно пройти enumeration потребляя при этом не более 20мА. По умолчанию 100мА дадут.

Нет, я про допустимый уровень на линиях данных на входе хоста. Просто тут все говорят про 3.6В , а я в спецификации видел циыру 4.6В

[ukpyr]

Это почему? По отношению к МК стабилитроны ставят ПОСЛЕ резисторов, а ЮСБ пофиг, оно всеравно не должно выдавать больше 3.6 В.

емкость низковольтных стабилитронов достигает 500 пФ, для LS может сойдет, но все равно многовато.

Между прочим, скажите, чем вариант 3 при правильной реализации хуже хардварного ЮСБ?

не полностью реализован контроль ошибок и некоторые другие фишки

Сообщение отредактировал ukpyr - Nov 29 2008, 08:45

[MAXvaLL]

не полностью реализован контроль ошибок и некоторые другие фишки

Выходные данные контролируются полностью хостом.

Входне не полностью? А откуда такая информация?

[ukpyr]

вроде АВР выдает АСК независимо от правильности полученных данных (на проверку нет времени)

[Rst7]

вроде АВР выдает АСК независимо от правильности полученных данных (на проверку нет времени)

Именно так. Я дорабатывал драйвер от ObjDev и выкладывал его тут на форуме. При кварце 20МГц выполняется подсчет CRC на лету, так что неправильные пакеты NAK'аются. В железе я его, правда, не проверял, так что надо доводить до ума. Если интересно - поищите.

[Petka]

Мне надо сделать 2 устройства, но это не значит что абы-как.

Ставить ФТДИ просто смешно для данного проекта и не оправданно.

Вот как раз для 2х устройств FTDI ставить и оправданно.
+ Просто + надёжно.

Между прочим, скажите, чем вариант 3 при правильной реализации хуже хардварного ЮСБ?

1) Оверклокинг.
2) Не полное соответствие спецификации USB. Как физический протокол, так и реализация стэка.

[ukpyr]

Оверклокинг.

для 2.7В - да, для 3.6В - нет (12МГц)

[Rst7]

Ставить ФТДИ просто смешно для данного проекта и не оправданно.

Так возьмите AT90USB162. Около $3 в глубокой рознице у наших торгашей. Можно и дешевле найти.

Для упрощения своей жизни мы сымитировали софтом саму FTDI. Т.е. наше железо выглядит как последовательный порт с FTDI'шными дровами. Только самой FTDI нету

[MAXvaLL]

вроде АВР выдает АСК независимо от правильности полученных данных (на проверку нет времени)

Не могу так просто с вами согласиться.
Вот функция вычисления crc16. Она что, для мебели просто?!
Кстати, о чем речь собственно? Лично я про http://www.obdev.at/products/avrusb/index.html
И кстати драйвер не стоит на месте, а развивается.

Код

; extern unsigned usbCrc16(unsigned char *data, unsigned char len);
; data: r24/25
; len: r22
; temp variables:
;   r18: data byte
;   r19: bit counter
;   r20/21: polynomial
;   r23: scratch
;   r24/25: crc-sum
;   r26/27=X: ptr
usbCrc16:
    mov     ptrL, argPtrL
    mov     ptrH, argPtrH
    ldi     resCrcL, 0
    ldi     resCrcH, 0
    ldi     polyL, lo8(0xa001)
    ldi     polyH, hi8(0xa001)
    com     argLen; argLen = -argLen - 1
crcByteLoop:
    subi    argLen, -1
    brcc    crcReady ; modified loop to ensure that carry is set below
    ld      byte, ptr+
    ldi     bitCnt, -8; strange loop counter to ensure that carry is set where we need it
    eor     resCrcL, byte
crcBitLoop:
    ror     resCrcH; carry is always set here
    ror     resCrcL
    brcs    crcNoXor
    eor     resCrcL, polyL
    eor     resCrcH, polyH
crcNoXor:
    subi    bitCnt, -1
    brcs    crcBitLoop
    rjmp    crcByteLoop
crcReady:
    ret

Вот как раз для 2х устройств FTDI ставить и оправданно.
+ Просто + надёжно.

1) Оверклокинг.
2) Не полное соответствие спецификации USB. Как физический протокол, так и реализация стэка.

Ну это кому как. Физически фтди сложнее поставить ( tqfp с шагом 0.5 против dip8 )
Мне и это просто, хотя немного менее надежно - да.
Я не против НОРМАЛЬНОГО юсб, просто это решение тоже имеет право на жизнь.

1) Нет.

для 2.7В - да, для 3.6В - нет (12МГц)

+1

2) Поясните поподробнее, что имеется ввиду. (про стек)
А физика в чем не та? Ну вместо дифф. передатчика 2 обычных, ну и что?

[Rst7]

Не могу так просто с вами согласиться.
Вот функция вычисления crc16. Она что, для мебели просто?!

Функция эта используется для создания пакета для передачи и для проверки целостности пакета при приеме, но уже после того, как хосту сказано, что пакет принят нормально. Поэтому нет перепосылки неправильно принятого пакета. Еще раз повторюсь, ищите мои правки драйвера и доводите их до ума. Там контрольная сумма считается на ходу и хост ставится в известность о необходимости перепосылки.

[MAXvaLL]

Функция эта используется для создания пакета для передачи и для проверки целостности пакета при приеме, но уже после того, как хосту сказано, что пакет принят нормально. Поэтому нет перепосылки неправильно принятого пакета. Еще раз повторюсь, ищите мои правки драйвера и доводите их до ума. Там контрольная сумма считается на ходу и хост ставится в известность о необходимости перепосылки.

Ясно.

Но у меня используются только управляющие транзакции, и если устройство не ответит на запрос, программа просто пошлет запрос еще раз.

Вопрос: а если обнаружена ошибка, UsbSetup будет вызвана?

Более того, даже если некоторые (главное чтоб не все ) ответы пропадут, это не важно.

Так что то что ущербно для одной задачи, вполне приемлимо для другой!

Да, ваш опыт интересен, но нет возможности гонять МП на 20 МГц (питать буду от 3.3В и гонять на 12.8МГц, обеспечивая максимум аппаратной совместимости)
Да и нет необходимости.

[vvvvv]

У меня вопрос немного в сторону, но может кто знает, возможно ли в AT90USB162 настроить так, чтобы определялась в виндах как два устройства одновременно, например клава и RS232

[Jhohn]

Но у меня используются только управляющие транзакции, и если устройство не ответит на запрос, программа просто пошлет запрос еще раз.

похоже вы не разобрались в USB. Если не получит подтверждения (ask, и т.п.) системное обеспечение уравляющее хост-контроллером вышлет повторный запрос, а потом если не будет ответа еще раз вышлет, а не ПО

Вопрос: а если обнаружена ошибка, UsbSetup будет вызвана?

вопрос не понял.

Более того, даже если некоторые (главное чтоб не все ) ответы пропадут, это не важно.

Так что то что ущербно для одной задачи, вполне приемлимо для другой!

Что ж у вас за задача? Вначале ОС определяет на своем уровне есть ли новое устройство и посылает всякие setup пакеты. Если ОС не определит то напишет "неизвестное устройство".

[MAXvaLL]

У меня вопрос немного в сторону, но может кто знает, возможно ли в AT90USB162 настроить так, чтобы определялась в виндах как два устройства одновременно, например клава и RS232

Теоретически да, нужно чтобы устройство имело 2 различных интерфейса, каждому из которых сопоставленны свои ендпоинты. (если в этом МК нет ограничений этому препятствующих, то можно и практически)
Каждый интерфейс реализует свою задачу.

похоже вы не разобрались в USB. Если не получит подтверждения (ask, и т.п.) системное обеспечение уравляющее хост-контроллером вышлет повторный запрос, а потом если не будет ответа еще раз вышлет, а не ПО

вопрос не понял.

Что ж у вас за задача? Вначале ОС определяет на своем уровне есть ли новое устройство и посылает всякие setup пакеты. Если ОС не определит то напишет "неизвестное устройство".

Я-то разобрался.
А вот вы похоже пишете не поняв о чем я. И так и не разобравшись в чем суть темы вообще.
Я говорю, что если управляющий пакет потеряется (т.к. МП всегда шлет ACK), то соответственно программа не получит ответ в течении заданного времени, и повторит запрос.
Если вы не поняли, посмотрите выше - и поймете, что проверка ошибок реализованна ПОСЛЕ подтверждения приема пакета.

Я о функции
USB_PUBLIC uchar usbFunctionSetup(uchar data[8])
из драйвера ObDev (ссылка выше)
которая вызывается при приходе управляющей транзакции.
Интересует что будет, если обнаружиться ошибка приема пакета? Будет ли вызванна функция?

Я не об этом. Нумерация у меня всегда проходит без вопросов.
Я говорю уже про процесс обмена МОЕЙ программы с устройством.
И я для этого использую ендпоинт 0. И меня это вполне устраивает.
Задача: переодический запрос и получение нужного параметра. (всего несколько байт)

[MAXvaLL]

Знатоки AVR USB, отзовитесь!

[QuickWitted]

Кстати, что-то я раньше не обращал внимания, но тут
http://www.cesko.host.sk/IgorPlugUSB/IgorP...20(AVR)_eng.htm
тоже разновидность варианта 1. Но резисторы по 68Ом, да еще и подтяжка 1.5кОм от 5В
Удивительно, как это работает =)

А оно и не работает...

По твоей классификации вариант со стабилитронами
я делал так:
http://www.swordgreenline.narod.ru/IgorPlug2.html

При правильной сборке - заводится сразу...
(количество повторений превысило 2000, все возникшие проблемы решались.)

Знатоки AVR USB, отзовитесь!

И.

Теоретически да, нужно чтобы устройство имело 2 различных интерфейса, каждому из которых сопоставленны свои ендпоинты. (если в этом МК нет ограничений этому препятствующих, то можно и практически)

Сам то понял что написал?
Нужно два дескриптора, а не "ендпоинты"

пример - клава и мыша

static const char hidReportDescriptor0[] PROGMEM = {
/* partial keyboard */
0x05, 0x01, /* Usage Page (Generic Desktop), */
0x09, 0x06, /* Usage (Keyboard), */
0xA1, 0x01, /* Collection (Application), */
0x85, 0x01, /* Report Id (1) */
0x95, 0x04, /* Report Count (4), */
0x75, 0x08, /* Report Size (8), */
0x15, 0x00, /* Logical Minimum (0), */
0x25, 0x65, /* Logical Maximum(101), */
0x05, 0x07, /* Usage Page (Key Codes), */
0x19, 0x00, /* Usage Minimum (0), */
0x29, 0x65, /* Usage Maximum (101), */
0x81, 0x00, /* Input (Data, Array), ;Key arrays (4 bytes) */
0xC0, /* End Collection */

/* mouse */
0x05, 0x01, /* Usage Page (Generic Desktop), */
0x09, 0x02, /* Usage (Mouse), */
0xA1, 0x01, /* Collection (Application), */
0x09, 0x01, /* Usage (Pointer), */
0xA1, 0x00, /* Collection (Physical), */
0x05, 0x09, /* Usage Page (Buttons), */
0x19, 0x01, /* Usage Minimum (01), */
0x29, 0x03, /* Usage Maximun (03), */
0x15, 0x00, /* Logical Minimum (0), */
0x25, 0x01, /* Logical Maximum (1), */
0x85, 0x02, /* Report Id (2) */
0x95, 0x03, /* Report Count (3), */
0x75, 0x01, /* Report Size (1), */
0x81, 0x02, /* Input (Data, Variable, Absolute), ;3 button bits */
0x95, 0x01, /* Report Count (1), */
0x75, 0x05, /* Report Size (5), */
0x81, 0x01, /* Input (Constant), ;5 bit padding */
0x05, 0x01, /* Usage Page (Generic Desktop), */
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, 0x06, /* Input (Data, Variable, Relative), ;2 position bytes (X & Y) */
0xC0, /* End Collection, */
0xC0, /* End Collection */
};

[MAXvaLL]

И.

Сам то понял что написал?
Нужно два дескриптора, а не "ендпоинты"

Что, И?

Вопрос задан:
USB_PUBLIC uchar usbFunctionSetup(uchar data[8])
из драйвера ObDev (ссылка выше)
которая вызывается при приходе управляющей транзакции.
Интересует что будет, если обнаружиться ошибка приема пакета? Будет ли вызванна функция?

Я-то понял, а вы?
Я написал, что надо 2 ИНТЕРФЕЙСА. (а бывают интерфейсы без ЕП?!)
Соответственно каждому интерфейсу по дескриптору.

[QuickWitted]

Вопрос задан:
USB_PUBLIC uchar usbFunctionSetup(uchar data[8])
из драйвера ObDev (ссылка выше)
которая вызывается при приходе управляющей транзакции.
Интересует что будет, если обнаружиться ошибка приема пакета? Будет ли вызванна функция?

У меня вопрос немного в сторону, но может кто знает, возможно ли в AT90USB162 настроить так, чтобы определялась в виндах как два устройства одновременно, например клава и RS232

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

Соответственно каждому интерфейсу по дескриптору.

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

[MAXvaLL]

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

А я про это и ответил. На практике. Разговор про теорию был т.к. я не знаком конкретно с этим МК.

И получиться 2 интерфейса, которые видяться виндой как 2 логических устройства.

А зачем вы привели дескрипторы Hid Repport'ов? Это тут причем?
Я говорю про общий случай, когда в одном физическом устройстве могут быть совершенно разные логические устройства, а не только хид клава и мышь.

Хоть бы объяснили человеку (кто спросил) что это за дескрипторы!

[QuickWitted]

Хоть бы объяснили человеку (кто спросил) что это за дескрипторы!

Это стандартный пример.

у атмела есть кривая пояснялка
doc7599.pdf
doc7805.pdf

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

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

uchar usbFunctionSetup(uchar data[8])
{
usbRequest_t *rq = (void *) data;

DBG1(0xa0, data, 8);

if ((rq->bmRequestType & USBRQ_TYPE_MASK) == USBRQ_TYPE_CLASS) { /* class request type */
if (rq->bRequest == USBRQ_HID_GET_REPORT) {
/* wValue: ReportType (highbyte), ReportID (lowbyte) */
if (rq->wValue.bytes[0] == 1) {
usbMsgPtr = inputBuffer1;
return sizeof(inputBuffer1);
} else if (rq->wValue.bytes[0] == 2) {
usbMsgPtr = inputBuffer2;
return sizeof(inputBuffer2);
}
return 0;
} else if (rq->bRequest == USBRQ_HID_SET_REPORT) {
/* wValue: ReportType (highbyte), ReportID (lowbyte) */
/* we have no output/feature reports */
return 0;
} else if (rq->bRequest == USBRQ_HID_GET_IDLE) {
usbMsgPtr = &idleRate;
return 1;
} else if (rq->bRequest == USBRQ_HID_SET_IDLE) {
idleRate = rq->wValue.bytes[1];
}
return 0;
}

return 0;
}

[QuickWitted]

Вопрос к АЛЛ
как до HID достучаться с Дэльфи?

Как выявили поиски HID RS232 и HID LPT требуют драйвер...
(HID ком порт, без стороннего драйвера НЕ РАБОТАЕТ.)

"использование интерфейса USB в качестве виртуального COM-порта."
"Другое важное преимущество заключается в том, что используются стандартные драйвера Windows и
не требуется создание какого-либо своего драйвера."

и ниже

"После подключения устройства к USB система опознает новое устройство"
"Выбираем установку с указанного места и указываем путь расположения файла mcpusb.inf"

типа mcpusb.inf с диска это не сторонний драйвер.

Для АВР предлагают использовать связку - usbser.sys и usbser.sys из файла avrcdc_inf.zip

Всё забываю ответить на вопрос что будет если произойдёт сбой.
Ответ – зависнет. Или до передёргивания шланга, или до сброса по сторожевому таймеру (если взведён).

Откапал ещё одну почитайку по поводу комбиков.

http://microchip.com.ru/1010/Support/USB%20apps.html
Практическое использование интерфейса USB в PIC контроллерах.

Да это пик, а не АВР, но другого мануала на "Составное USB устройство" я пока не видел.

Да и это подробностью не блещет

1. Создание дескриптора -> Изменим структуру дескриптора. ->Устройство будет иметь 2 интерфейса,
в каждом по одной конечной точке.
2. В соответствии с измененной структурой нужно изменить дескриптор
3. Определить идентификаторы интерфейсов, используемые конечные точки, размеры report дескрипторов.
4. инициализировать дополнительные конечные точки и изменить функцию обработки HID-запросов.
5. Каждое из устройств, мышка и джойстик, должны передавать данные каждый в свою конечную точку.
Поэтому нам необходимо добавить функции передачи данных в конкретные конечные точки и проверки,
что нужная конечная точка свободна.

Для упрощения создания дескриптора устройства можно воспользоваться программой HID Descriptor Tool,
которую можно скачать с сайта www.usb.org

Вот и вся дока...

Хоть бы объяснили человеку (кто спросил) что это за дескрипторы!

P.S: Если кому понятней начинать с конца, то картинку можно перевернуть ендпоинтами к верху

Эскизы прикрепленных изображений

 

[QuickWitted]

Что то тема заглохла...

Вопрос к АЛЛ
как до HID достучаться с Дэльфи?

[Xenia]

Кто знает, отчего берутся USB-запросы (CDC Class Requests):
SEND_ENCAPSULATED_COMMAND
GET_ENCAPSULATED_RESPONSE
?
Обычно их не обрабатывают, но любопытно, для чего они нужны. Короче говоря, мой вопрос формулируется так: "Какую команду из Windows-API должно подать приложение, чтобы моя AVRка получила один из этих реквайстов?" И в частности, если у меня на USB организован виртуальный COM-порт. Как вызвать все остальные реквайсты я знаю, остались непонятными только эти. В книгах и исходниках эти два реквайста всегда упоминаются, однако ни слова не нашла про то, в связи с каким событием такие запросы посылаются. Драйвер, конечно, может послать любой реквайст, но остается неясным, как побудить драйвер к этому (я использую стандартный драйвер виртуального порта usbser.sys, встроенный в Windows).

Сообщение отредактировал Xenia - Jun 21 2009, 00:45

[Genadi Zawidowsk...]

Кто знает, отчего берутся USB-запросы (CDC Class Requests):
SEND_ENCAPSULATED_COMMAND
GET_ENCAPSULATED_RESPONSE
?
Обычно их не обрабатывают, но любопытно, для чего они нужны. Короче говоря, мой вопрос формулируется так: "Какую команду из Windows-API должно подать приложение, чтобы моя AVRка получила один из этих реквайстов?" И в частности, если у меня на USB организован виртуальный COM-порт. Как вызвать все остальные реквайсты я знаю, остались непонятными только эти. В книгах и исходниках эти два реквайста всегда упоминаются, однако ни слова не нашла про то, в связи с каким событием такие запросы посылаются. Драйвер, конечно, может послать любой реквайст, но остается неясным, как побудить драйвер к этому (я использую стандартный драйвер виртуального порта usbser.sys, встроенный в Windows).

Попробуйте применить TransmitCommChar - может, оно вызовет SEND_ENCAPSULATED_COMMAND ?

хотя, почитал первый попавшийся даташит - и показалось, что это - рлддержка для DeviceIoControl

Сообщение отредактировал Genadi Zawidowski - Jun 21 2009, 07:47

[Xenia]

Попробуйте применить TransmitCommChar - может, оно вызовет SEND_ENCAPSULATED_COMMAND ?

Уже думала про это, но лениво было проверять .

хотя, почитал первый попавшийся даташит - и показалось, что это - поддержка для DeviceIoControl

А вот это как раз меня больше всего интересует! К сожалению, константы DeviceIoControl для СОМ-порта не описаны.
Любопытно, что функция

BOOL EscapeCommFunction(
HANDLE hFile, // handle to communications device
DWORD dwFunc // extended function to perform
);

очень похожа на DeviceIoControl, поскольку значение dwFunc очень похожа по смыслу на констанды DeviceIoControl:
dwFunc value:
CLRDTR Clears the DTR (data-terminal-ready) signal.
CLRRTS Clears the RTS (request-to-send) signal.
SETDTR Sends the DTR (data-terminal-ready) signal.
SETRTS Sends the RTS (request-to-send) signal.
SETXOFF Causes transmission to act as if an XOFF character has been received.
SETXON Causes transmission to act as if an XON character has been received.
SETBREAK Suspends character transmission and places the transmission line in a break state until the ClearCommBreak function is called.
CLRBREAK Restores character transmission and places the transmission line in a nonbreak state.

К сожалению, нмчего похожего на SEND_ENCAPSULATED_COMMAND и GET_ENCAPSULATED_RESPONSE тут нет.

[Marian]

как до HID достучаться с Дэльфи?

Программирование простейших USB-устройств на Delphi

[Br.Misha]

Здраствуйте!
Я понимаю что тема уже старая но межет у кого нить есть пример AVR - CDC. Мне нада просто пересылать/принимать байты(как по обычому юарту).
Кстате, нормально ли работает дряйвер от obdev на 16Мгц(при соотвецтвенной настройке конечно?))
ЗЫ: на http://www.recursion.jp меня не слать! тот пример у меня не работает.