Как увеличить скорость на HID AT89C5131, Как увеличить скорость на HID AT89C5131 Опции

[StasK]

Как увеличить скорость на HID, а то у меня 800 байт/сек как на низкоскоростном. D+ вроде присоединен к VRef через 1.5 кОм, что должно дать полноскоростное устройство (как у Агурова). Может дело в дескрипторе?

[toweroff]

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

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

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

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

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

[StasK]

Как я уже упоминал, с 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.