Why on the another device driver

The device drivers of the SiLabs USB examples, USB_INT and USB_BULK, are excellent and enough to show the potential of 'F32x series as long as the examples concern. They also give the implementation of the function that the commercial products should be equipped, such as the GUID support.
However we also need a testbench, in which we can test the functions that the SiLabs drivers don't support, but 'F32x has. For example, vendor request and Isochronous transfer. Cypress' device driver is rather rough comparing to SiLabs', but it supports these functions.
Anyway, these device drivers, both SiLabs' and Cypress', are only used for the development of 'F32x firmware. We should develop our own device driver for our final products. Our interest is to fix the feature of 'F32x firmware and realize it. For this purpose, the device driver that supports full functions of 'F32x is desirable.

Cypress driver implementation to the USB_INT and USB_BULK examples

USB_INT_Cypress
USB_BULK_Cypress

These patch drive 'F32x on the Cypress' device driver. SiLabs examples below is used as the patch base.
USB_INT, "Last updated 30 JAN 2004" version.
USB_BULK, "Last updated 18 JUN 2004" version

Firmware
Only VID (Vendor ID) and PID (Product ID) on the Device Descriptor is replaced to Cypress'. No other change.

Device driver
The device driver is included in EZ-USB Development Tools V2.61.700. You can download it from EZ-USB Development Tools V2.61.700 (62365KB) on Cypress site.
Please note, this Development Tools is offered for the development of the EZ-USB parts. It is desirable that you have at least one EZ-USB chip, if you are going to download it.

Use C:\Cypress\USB\Drivers\ezusbw2k.inf to install the driver when 'F320TB is pluged in to USB port.

Host application
The difference between SiLabs' and Cypress' is on CreateFile(), ReadFile() and WriteFile().
"ezusbsys.h" is a product of Cypress. So I didn't include it in these ZIP files. Copy C:\Cypress\USB\Drivers\ezusbdrv\ezusbsys.h to each \Host Application Source\, after installing EZ-USB Development Kit.

And I warn that this patch is a quick and dirty one only to show that USB_INT and USB_BULK examples works on the other device driver. This patch will also give the start point to implement another functions such as Vendor Request and Isochronous transfer.

Tsuneo

My USB topics
How to increase HID_Example In/Out packet size?
FIFO read/write performance
256000 bytes/sec Isochronous transfer
Isochronous test patch
Multi-thread and Overlapped example for USB_INT Host Application
Vendor Requests test code
USB_INT and USB_BULK on Cypress device driver

[EDIT]
Dec 16, 2004 Changed EZ-USB download URL
July 20, 2005 Changed EZ-USB download URL

After all, I'll reply here. I want to know the opinion of many people about this.

"why do you suggest we use cypress USB 'device driver'"

As for USB_INT,
a) Cypress' device driver is straightforward.
SiLabs' device driver is elaborate one. It has the ability to issue IN transfer back to back. But they failed in the design. Its queue stocks asynchronous ReadFile() call, though the transfers should be preserved actually. It discards transfer if no waiting ReadFile() call exists when one transfer finished. Thus, frequent ReadFile() call should be needed to take every transfer without drop, if we call it synchronously. Otherwise, we should use asynchronous call to make the queue work. If the transfer is buffered, the application will be easier. So I say they failed.

On the other hand, Cypress' is simple. No queue. No back to back ability. It simply issues a transfer when it is called by DeviceIoControl(). Cypress' uses DeviceIoControl() instead of ReadFile(). Its calling parameter is common with interrupt and bulk transfer. If we call it synchronously or asynchronously, no change is needed on the calling schema. Only change ReadFile() to DeviceIoControl() and its parameters.

b) No need to modify the device driver to increase the transfer size
SiLabs' driver has the fixed number, 8, for the transfer size as I mentioned in "Increasing Packet Size on EP1". To increase this number, you should modify the device driver source. Cypress' transfer size is up to 64KB, without any modification.

You may feel that if the calling schema is not simplified, why we should replace the device driver? My first answer is the cost to develop the custom device driver. If you can do with the simple driver, the development cost should be reduced in a great deal. Once you tried it on the simple driver, you can confidently declare that you can do with the simple driver.
My another answer is the simplicity to understand the mechanism. One DeviceIoControl() call directly corresponds to one transfer. I think it is important that the designer completely understands the mechanism to achieve the commercial quality.

As for USB_BULK,
I have no complaint on the SiLabs bulk driver, except for it doesn't support the vendor request. They use both bulk and vendor request on the USBXpress driver. I don't know why they removed the vendor request call from the USB_BULK driver. Vendor request is useful to set or get the setup condition of the device, such as push button states or LED lighting. The implementation of the vendor request to the USB_BULK firmware is simple, as the Endpoint0() handler is well structurized. Even the device driver supports it, we can use it at once.
Somebody will take it a matter that SiLabs driver is a bit slower than the Cypress' like "What is maximum speed on Bulk". But I feel it's a trivial thing. Anyway we should develop our own driver.

Tsuneo