Не знаю, но работает. Но было бы самому интересно.

Ошибка, не 40, а меньше 16. Я думаю, это связано с тем, что я использую 1 и 2 конечную точку. Они имеют буфер FIFO 32 байта, а посылка HID high-speed - 64, это в 2 раза. Еще эти точки не ping-pong, еще в 2 раза.
Я поменял номер конечной из контроллера на 3 или 4, но в этом случае ничего не передается. Почему?

Как я уже упоминал, с HID я не работал... Во-первых, у меня ping-pong, во-вторых - bulk. Конечных точек, соответственно, 3 - системная (0, 32 байта), ИН и ОУТ (4,5), их размеры по 64 байта

обработка 0-й точки в прерывании, рабочих точек - в основной задаче в цикле

контрольные точки задавались в подключенной библиотеке libusb, там же указывались параметры точек. Соответственно, когда менял номера, все тоже рушилось, и нихрена не работало

возможно, HID имеет 0-ю точку как универсальную, и еще одну как дополнительную. Нужно смотреть, как настроен драйвер и управляющий софт сверху

Кстати, а для чего используется именно класс HID? Лень было искать драйвер, или специфика девайса такова?

Надо посмотреть инфу о HID драйвере и как он выбирает конечные точки устройства, кроме Control.
Мне надо гнать 3700 двухбайтных точек с CCD в комп. На 64 кбайтах получается 8 посылок/сек, что вполне подходит. Поэтому решили использовать HID, чтобы пользователю было удобно, да и нам не надо думать о работоспособности под разными операционками.

Согласно этой статье на http://www.microsoft.com/whdc/archive/hid4.mspx
HID общается с Interface а не с Endpoint. Поэтому я не понимаю, почему при изменении номера endpoint на 4 или 5 ничего не работает.

There has been some confusion among Human Interface Device (HID) device implementers in determining whether their HID devices are draft #4 compliant. This confusion stems from a decision by the USB Implementers' Forum to associate the HID descriptor with the Interface, rather than with the Endpoint. The HID descriptor has been repositioned within the Configuration descriptor; the correct order is now Configuration/Interface/HID/Endpoint.

The HID USB driver supplied with Microsoft Windows operating systems looks at the order of the descriptors within the Configuration descriptor to determine whether a device is draft #4 compliant. If the driver sees a descriptor order of Interface/Endpoint/HID, it assumes this is an older device and sends all requests to the Endpoint. If it sees a descriptor order of Interface/HID/Endpoint, it assumes this is a draft #4 compliant device and sends all requests to the Interface.

Moving the HID descriptor has had two troublesome results:
•

Developers have been confused to see bmRequestType with a value of 82h in their bus trace when they were expecting to see 81h.
•

The Configuration descriptor is not parsed correctly under Windows 95 OSR 2.1. Notice that this is only an issue if you are writing or updating HID drivers for OSR 2.1. This is not a problem if you are using HID drivers supplied with Windows 98.

What are the cures?

If bmRequestType is 82h, your HID descriptor is associated with the Endpoint descriptor, rather than with the Interface descriptor. To fix this, relocate the HID descriptor so that it sits after the Interface descriptor and before the Endpoint descriptor. The device firmware that handles the setup packet needs to look for a request type of 81h, rather than 82h. Finally, for devices with multiple interfaces, such as a keyboard with built-in mouse, the wIndex field must reflect the interface for which a Report descriptor is being requested.

The Windows 95 OSR 2.1 USB class driver incorrectly assumes that the Endpoint descriptor immediately follows the Interface descriptor. A solution that works equally well on both Windows 95 and Windows 98 is to clear everything out of the Configuration descriptor returned from the device except Configuration, Interface, and Endpoint descriptors before being passed to USB functions. A sample function that performs this task is available for downloading.

Ну это же кошмар...
Хид по умолчанию 2 точки
Контрольная и ин точка для посылки репортов, типа интерапт.
можно добавить одну оут точку для приема фичей и оутпут репортов.

номера используемых точек указываются в описании, в структурах которые передаются при описании хид устройства в систему. Так что, сменив точки, надо сменить и описание ХИД устройства.
Но хид в принципе не рассчитан на прокачку данных, вы же должны и стандарт репорта задать, и интервалы опроса репортов. И вообще по умолчанию хид девайс работает от прибора в компутер, но никто не говорит, что в обратную сторону будет также качаться....


Еще одно замечание, мой кристал ат89С5130А при обработке контрольной точки в прерывании работал жуть как медленно, потому что в крситале есть ошибка и прерывание вызывали не только флаги контрольной точки, но и куча дополнительной фигни происходящей на усб... читайте ераты и проверьте, может у вас программа сидит в прерывании 90% времени как у меня было, от того и отчеты редко шлет...













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

Так мне и нужно от прибора в компутор.
А по поводу времени в интерапт, то USB монитор показывает посылки каждую мс, так что репоты идут с нормальной частотой, но по 32 байта и не ping-pong.
Еще помучаюсь некоторое время и может всеж перейду под свои драва. Но как не хочется в это лезть...

свои дрова - геморой ... если только ОС зафиксировать... да и все равно геморой...

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

а какой геморрой с дровами?? Я ж говорю - libusb, все исходники прилагаются

Project Admins: dsd_, jerdfelt
Operating System: All BSD Platforms (FreeBSD/NetBSD/OpenBSD/Apple Mac OS X), All POSIX (Linux/BSD/UNIX-like OSes), Linux
License: GNU Library or Lesser General Public License (LGPL)
Category: Software Developmen

+я нашел под win32

+ там был креатор для ini-файла

+добавлю, что атмелевский прогер для 89C5131/30 сам пользует libusb

Сообщение отредактировал toweroff - Jun 10 2008, 07:26