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

Для USB 2.0 в дескрипторе устройства надо задать номер версии спецификации USB в формате BCD:
0x00, 0x02, // bcdUSB (lsb first)
третий и четвертый байты дескриптора

Так так и записано:
{9,0x21,0x0002,0,1,0x22,0x2100}
а все равно 800/сек.

А пример дескриптора к полноскоростному HIDу кто-нть может показать? Плиз!!!!

Вот на мышку (USB 2.0). В даташите на микруху написано, что она поддерживает Full-Speed, это соответствует спецификации USB1.1

У меня есть диск с примерами к книге Агурова могу выложить если надо.

Я понял в чем было дело!!!

config.h
#define EP_INTERVAL_1 0x20

usb_kbd_enum.c
code struct
{ struct usb_st_configuration_descriptor cfg;
struct usb_st_interface_descriptor ifc;
struct usb_st_hid_descriptor hid ;
struct usb_st_endpoint_descriptor ep1 ;
Uchar rep[SIZE_OF_REPORT] ;
}
usb_configuration =
{
{ 9, CONFIGURATION, CONF_LENGTH, NB_INTERFACE, CONF_NB,
CONF_INDEX, CONF_ATTRIBUTES, MAX_POWER},
{ 9, INTERFACE, INTERFACE_NB, ALTERNATE, NB_ENDPOINT, INTERFACE_CLASS,
INTERFACE_SUB_CLASS, INTERFACE_PROTOCOL, INTERFACE_INDEX },
{ 9, HID, 0x1101, 8, 1, REPORT, 0x3B00 },
{ 7, ENDPOINT, ENDPOINT_NB_1, EP_ATTRIBUTES_1, EP_SIZE_1, EP_INTERVAL_1 },


The example sets it to 32 ms.
When the device is configured to full-speed (attach pull-up to D+), you can reduce EP_INTERVAL_1 to 1 (ms).
When configured to a low-speed (D- pull-up), the minimum is 10 ms.

А у меня этот EP_INTERVAL_1 был в нуле и, наверное, по умалчанию определяется как low-speed с 10 ms. А надо поставить
#define EP_INTERVAL_1 0x01 для full-speed


И, вообще, надо переходить с этого дорогущего AT89C5131 на что-то более рациональное.

И, вообще, надо переходить с этого дорогущего AT89C5131 на что-то более рациональное.
[/quote]

150р - это дорого для USB2.0 ???

150 - дорого для С51, я думаю перейти на ARM Cortex-M3.

StasK, и какая скорость достигнута?

точно больше 40k/sec

чот маловато.... я имею 3 Мбит/с, и то тормозится из-за обилия обращения во внешнюю память в больших циклах

Здравствуйте народ!

Немного не в тему, но всеж про эту микруху и про хид. А у Вас для ХИД устройства есть функции обработки СЕТ_РЕПОРТ? У меня проблема при передачи репорта с компутера, на последнем происходит ошибка с таймоутом, хотя данные до устройства доходят.... Не подскажите что АТ89С513ХХХ должна отвечать на СЕТ_РЕПОРТ, чтобы компутер отработал выдачу отчета?

Я думал посылка данных нулевой длинны и есть Акноледж в фазе стутса, может я не прав? Все остальные фунекции работают, и с приемом репортов, и описаний, и устрйотво в системе регистрируется как хид, а этот сет_репорт из библиотеки хид.длл неработает...

Прослушка УСБТрайсом, рождает больше вопросов, чем ответов, какие-то лишние посылки, и запросы с ожиданием ответа... Посылка данных нулевой длинны принимается как передача от устройства, а не как акноледж... Подскажите плз кто разбирался...

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



Я прикрепил листинги для контроллера и для компа.Нажмите для просмотра прикрепленного файлаНажмите для просмотра прикрепленного файла

а вот у вас в функции ФаелВрайт, есть магическая стрчока в 9 байт отчета вписать 15, почему?

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

есть какие-то особенности при заполнении буфера репорта или нет? к чему там это число 15?

У меня единственное - не как HID сделано, а как bulk. Драйвера юзал libusb, портированные с linux
От компа к компу скорость не меняется и остается на уровне 3Мбит. При этом в конфигурации USB указывается 1.1, а не 2.0

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

Ошибка, не 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