We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Something curious is happening with my USB HID device.
It is a Full-speed Device. The curious thing is that my VB software transfers 64 bytes of data (EP0 CONTROL TRANSFER) to the device only one time each 05 SOF signals of the USB line. So, instead of 64 KB/s I am only having 64/5 Kb/s data transfer rate.
I have even set my VB software to run in High priority mode - So it has nothing to do with Windows priorities.
Would anyone have a clue how I can increase the data transfer rate ?
Hi, Tsuneo,
I still have a problem:
This is how microsoft´s USBVIEW sees the device:
Device Descriptor: bcdUSB: 0x0110 bDeviceClass: 0x00 bDeviceSubClass: 0x00 bDeviceProtocol: 0x00 bMaxPacketSize0: 0x40 (64) idVendor: 0x0B6A (Maxim Integrated Products) idProduct: 0x7889 bcdDevice: 0x1234 iManufacturer: 0x01 iProduct: 0x02 iSerialNumber: 0x03 bNumConfigurations: 0x01
ConnectionStatus: DeviceConnected Current Config Value: 0x01 Device Bus Speed: Full Device Address: 0x02 Open Pipes: 2
Endpoint Descriptor: bEndpointAddress: 0x82 IN Transfer Type: Interrupt wMaxPacketSize: 0x0040 (64) bInterval: 0x0A
Endpoint Descriptor: bEndpointAddress: 0x01 OUT Transfer Type: Interrupt wMaxPacketSize: 0x0040 (64) bInterval: 0x01
According to your hints, I used the following report descriptor
Report Descriptor:
06 00 FF 09 01 A1 01 ‘globals 15 00 26 FF 00 75 08 ‘input report - I guess #0 85 01 95 40 09 01 81 02 ‘output report #1 09 01 91 02 ‘output report #2 85 03 96 00 10 09 01 91 02 C0
I can send corretly 64 bytes Through report #1 and 4096 bytes through report #2
But although the device really sends an IN PACKET (I have a USB Packet analyzer in the USB line and I can see the IN PACKET being read and acknowlodged by the host), the Readfile function does not get the data and keep giving me a return of 0 bytes read …
What can going wrong ?
Antonio
> I can send corretly 64 bytes Through report #1 and 4096 bytes through report #2
You've changed the report descriptor as follows,
06 00 FF // USAGE_PAGE (Vendor Defined Page 1) 09 01 // USAGE (Vendor Usage 1) A1 01 // COLLECTION (Application) ‘globals 15 00 // LOGICAL_MINIMUM (0) 26 FF 00 // LOGICAL_MAXIMUM (255) 75 08 // REPORT_SIZE (8) ‘input report - I guess #0 85 01 // REPORT_ID (1) 95 40 // REPORT_COUNT (64) <------ 09 01 // USAGE (Vendor Usage 1) 81 02 // INPUT (Data,Var,Abs) ‘output report #1 09 01 // USAGE (Vendor Usage 1) 91 02 // OUTPUT (Data,Var,Abs) ‘output report #2 85 03 // REPORT_ID (3) <------ 96 00 10 // REPORT_COUNT (4096) 09 01 // USAGE (Vendor Usage 1) 91 02 // OUTPUT (Data,Var,Abs) C0 // END_COLLECTION
With this report descriptor, On the device side, the output report ID 1 is received in 65 bytes. The first byte is Report ID (1 byte = 0x01), and 64 bytes body follows. It is split into two transactions (64, 1). In above post, I've chosen 63 byte for this output report, to keep it in single transaction.
Similarly, report ID 3 is received in 4097 bytes, 1 byte report ID + 4096 bytes body
> ‘input report - I guess #0
Report ID 0 is reserved for the default - when no report ID appears on the report descriptor. To define report ID explicitly, arbitrary number, other than 0, is selected.
> the Readfile function does not get the data and keep giving me a return of 0 bytes read ...
As the format of the coming input report is wrong, HID device driver drops the report.
The device sends 65 bytes input report, one byte report ID (1), following 64 bytes body. This report is sent in two transactions (64, 1).
If you want to send it in single transaction, set the length (REPORT_COUNT) to 63.
Tsuneo
Actually I tested it with your report descriptor first. Even with 3Fh as the report count and 40h as the pipe byte count. My firmware is sending 40h bytes back, with 00 as the first one. (I can see with the USB ANALYZER). the ReadFile Function cannot read the single transaction that really appears on the USB line. It has to do with defining 02 output reports in the report descriptor. If we define only 01 output report, it works fine. Also, it you use 85 01 for the input report 85 02 for the first output report and 85 03 for the second output report, the device does not configure correctly. The host doesn´t issue the IN tokes he should from time to time.(Of course I have checked the REPORT lenght in the Class descriptor.) windows is really a nightmare. Can you test that descriptor at your end just to make sure ?
> Actually I tested it with your report descriptor first… My firmware is sending 40h bytes back, with 00 as the first one… the ReadFile Function cannot read the single transaction that really appears on the USB line.
The first byte should be 0x01, for report ID 1 It is the reason why HID class driver drops the report.
Yes It really worked !!!
Everything is fine. I am finding a problem in the READFILE function, though. I think you´ll know the answer.
Supose the device sends an IN PACKET. If I run the ReadFile function AFTER the packet has arrived to the Host, the function gets back with the correct result.
In the other hand, if I make a loop for the readffile function to detect the arrival of a packet, it never finds it the loop goes on forever.
How can I make the readFile function detect the packet while in the loop ?
Please find below the loop I am using in VB6
While (NumberOfBytesRead < 64) recv_buf(0) = 1 result = ReadFile(ReadHandle, recv_buf(0), CLng(Capabilities.InputReportByteLength), NumberOfBytesRead, HIDOverlapped) DoEvents Wend
Thanks
Just to add to the above post.
If I us the createFile function without the FILE_FLAG_OVERLAPPED The readfile detects the in Packet without a problem.
But I need to use the FILE_FLAG_OVERLAPPED because I need the function to return and not hang the thread until the packet arrives. what to do ?
This one doesn´t work 'ReadHandle = CreateFile _ (DevicePathName, _ (GENERIC_READ Or GENERIC_WRITE), _ (FILE_SHARE_READ Or FILE_SHARE_WRITE), _ Security, _ OPEN_EXISTING, _ FILE_FLAG_OVERLAPPED, _ 0)
This one works but the thread hangs untill the packet arrives 'O PACOTE F0 QUANDO O VB ESPERA EM LOOP ... ReadHandle = CreateFile _ (DevicePathName, _ (GENERIC_READ Or GENERIC_WRITE), _ (FILE_SHARE_READ Or FILE_SHARE_WRITE), _ Security, _ OPEN_EXISTING, _ 0, _ 0)
I made it work.
Everything works perfectly now.
For HID programming on PC side in VB.Net, this library make your life easy. When you don't use it directly, the source code will give you many suggestions.
USB Hid Device Library " href= "http://www.lvr.com/hidpage.htm">http://www.lvr.com/hidpage.htm www.lvr.com/.../generic_hid_vb_46.zip
HI, Tsuneo,
Something funny is happening with my VB application that controls the HID device.
When I run the software fom within the visual studio 6, it works fine and talks to the device, both in XP and windows 7.
After compilation, the .exe runs OK in wondows 7, but not in XP. In XP it issues no errors, but does not send messages to the HID Device.
It seems to me it is something abou the registration of the .dll in wondows. I am using the VB code from JAN AXELSON so I have tried to register (Using regsvr32) the .OCX and .DLL. The HID.DLL and setupapi.DLL isues and error (Entry point not found) and does not register.
Have you ever experienced anything like that ?
Maybe, your distribution is missing some DLL (or OCX) required.
Run Dependency Walker on the target PC for your application EXE. It tells missing DLL, if any.
Dependency Walker www.dependencywalker.com/
See VB6 manual at the chapter of packaging for deployment, to make setup project.
Distributing Your Applications - VB6 msdn.microsoft.com/.../aa716256(VS.60).aspx