Increasing speed in interrupt tranfer

can you make the oscilator jump fater?

No. There are 1000 frames / second, i.e. one every millisecond - and with a very, very strict requirement on allowed jitter. Change the oscillator frequency, and you will no longer have compatible USB communcation.

Hello Westermark,

Thanks alot for your reply. In the bulk transfer guarantied time delivery is not there. In case the bus is busy there will be delay as there is no reserved bandwidth. Our application demands both time and data correctness. In the books and websites the maximum speed possible for the interrupt transfer was found to be 64 kbytes/sec per end point. The core used is LPC2148 which gives 5 interrupt IN endpoints. So maximum speed possible 320kbytes/s. But more speed is demanded for our application. Currently HID device class driver is used which supports interrupt transfer.Is there any possibility of increasing the maximum packet size from 64bytes? I tried increasing the packet size but the enumeration fails. If i go for a custom driver in host side will my problem solved? Please suggest me a solution for this.

Two things.

1) Who would claim your required bandwidth? Just make sure that you don't connect through a USB hub and no other device should be there to steal bandwidth on the cable.

2) Firewire allows allocation of way more bandwidth. Yes. Much more expensive. But you get what you pay for. If you do not want to take the cost of a bus designed to allow you to allocate x Mbit/s of dedicated bandwidth, then you will have to settle for what you can get from the standards you do pay for.

3) Or you may look into ethernet together with QoS.

Hello Westermark,
Thanks for the reply. The problem in using bulk trnsfer is that application will be tested in the stress condition loading the PC with many other applications and it is expected to meet both guarantied data and time. Thats why the interrupt transfer was chose. So your opinion is the maximum packet size cannot be increased from 64bytes for interrupt transfer in any method? Our present scope is using usb 2.0 full speed only. Your suggession will be very helpful to me.

s/Two/Three/

Hello Westermark, Thanks for the reply.USB 2.0 full speed is the only scope. If we go for custom driver also the packet size increasing is not possible? Thanks in advance.

OK, Per. He is hard :-)

> The problem in using bulk trnsfer is that application will be tested in the stress condition loading the PC with many other applications and it is expected to meet both guarantied data and time. Thats why the interrupt transfer was chose.

Under stressed condition of PC, any transfer type can't guarantee transfer timing. No difference for bulk from interrupt. The interrupt bandwidth is guaranteed just on the USB wire. If PC device driver or your application can't pass transfer requests to the host controller in time, the guaranteed bandwidth is lost in vain.

> If we go for custom driver also the packet size increasing is not possible?

It can't.
USB spec defines wMaxPacketSize of interrupt as up to 64 bytes in full-speed.

If you want to guarantee such a high transfer speed on full-speed, run it on bulk with a separated host controller (add-on PCI card for USB), so that the device can occupy full bandwidth. Or, insert a multi-TT hub between the bulk device and the PC.

Multi-TT hubs
Belkin F5U234V1, F5U237v1
etc.

Tsuneo

Hi Tsuneo
Thanks for the reply.For our application even if other devices are there in the USB bus it should guaranty data correctness and time. Thats why we chose interrupt transfer instead of bulk transfer. But we could find that the speed of interrupt transfer is not sufficient for our application. Any other possible solution? Thanks for helping me out Tsuneo.

Hi All,
We are planning to buy Bulk based USB Driver. Can please you suggest me some.