USB data transfer speed with DemoJM60

[donw]

I have the DemoJM60 board, running the CMX USB stack
demo code, patched to echo back 64 byte data packets.
My PC code is Visual Basic 6 running  USBHIDIO.vbp  from lvr.com
which uses the HID driver of XP.
The best transfer speed I get is  ~10Kbytes per 9 seconds,
which is way below the theoretical 64KB/sec.
The USB data lines are pulsing every 1 msec as expected.
A scope port-toggle-on-packet-recieve/send (hid_report_pending(out_report))
shows sends every 14 msecs, rather that the 1 msec.
I have the data size set to 64 bytes, and poll time set to 1 msec as per others
on this forum have mentioned.
- I get the impression that a send & recieve cycle involves at least 3  lots of 1 msec
sends by the Host (out command/data in receive/ack). This would explain some of the slow
operation.

Can anyone enlighten me on the max. transfer I can achieve using HID. ?
Do I need to go to Bulk transfer or other mode? I need to transfer 2MByte to the Host.

- Also found a good intro to USB:      http://www.beyondlogic.org/usbnutshell/usb1.htm

[donw]

Jim:
In the hcc_u8 geh_config_descriptor, the USB_FILL_EP_DESC, the last value should be 1 for a 1 ms poll time.

Yes I have done the 1 msec poll. (I have been following all USB posts on this site)
Does anyone know just how fast I can expect packet echos to be?
The 12msec data transfer period seems strange... I realise my limitations may be
to do with VB6, which does a wait-for-recieve after a packet send....

[PeterHouse]

Don,

Based on a little bit of USB stuff I did a few years ago using VB6, I believe your problem lies in two areas.  1. Bulk transfers should be faster and 2. I believe this is the real problem: There is a lot of software between the VB app and the USB device which each packet you send has to traverse.  I am guessing you are sending a packet, waiting for a response, and sending another packet.  You should try sending multiple packets and then wait for the first one to send the Nth one, wait on the second to send the Nth+1 and so on.  Due to the asynchronous nature of VB and Windows this approach may not work and you may need to just send them as fast as you can and error check afterwards to make sure they all arrived instead of waiting for each packet.

You may also find  that AV software has inserted itself into the communication stack for the USB channel to scan for virus like activity on USB memory devices.  This will also cause a performance hit.

Good Luck,

Peter House

[JimDon]

He is using HID so there are no bulk transfers.
I've never heard of AV spicing into the USB stack, but I suppose it is possible.
Usually AV will get on the file system stack for this sort of thing. USB Drives are also part of the file system.

Most likely the real problem is the poll rate which is set the descriptors.

In the hcc_u8 geh_config_descriptor, the USB_FILL_EP_DESC, the last value should be 1 for a 1 ms poll time.