Now that the firmware is working, I'm focusing on the application side.  The application I'm adapting to USB was written in C (originally written for Windows 2.0 and only recently ported to 32 bit Windows and VC 2005).

The system currently runs with one ISA card in a PC and a daisy chain cable running between multiple external chassis (up to 5).  With USB, there will be a USB card in each chassis and I need to keep track of which card is which.  At initialization I run a scan to detect the hardware in each chassis and then that is stored in an array in memory that is cross referenced to which USB device has which hardware.

I'm looking at the documentation for CyAPI and the cydesc sample.  I see that getting the descriptor and a CCyUSBConfig object are fairly easy, but it looks like they don't tell me anything unique about a given instance of a device.  The only thing I can see that is unique is the index used by Open().  Will this index stay the same even if the user plugs in or removes another device that uses CyUSB.sys?  I'm not concerned with the user plugging or unplugging our cards while in operation.  If they did that for any reason, it would be cause to restart the application afterwards.

Since CyAPI sees all devices that use CyUSB.sys it is conceivable that the user might plug or unplug another device that uses the same driver while the system is in operation and I need to deal with that possibility.  If that changes the indexes, then that will crash our system.

Is there something else unique to each instance that I can use to keep track of the devices?

Bill

Bill,

I am not sure whether I have understood your requirements correctly.

I believe you have 5 usb devices connected to a host and want to idebtify the device from its instance created in vc++.

Why dont you use serialNumber member of CCyUsbdevice class.

-shub

I thought the serial number was hardcoded in the firmware.  There is a field in dscr.a51 file in the firmware for the serial number. 

Does Windows assign a unique value to the serial number?  At the moment I only have one card available, so I can't test it.

Bill

Yes that is right serial numer is hard coded in firmware in dscr.a51. But as you said you have 5 different devices you can load each device with the firmware having different serial number.

-shub

That won't be possible.  My customer wants all the cards to have the same firmware.  This is going into a production test system and they don't want to track five different part numbers.  I can see at least  dozen different kind of headaches from that approach.

Why don't you expose the hub/port information through CyAPI?  I know the information is there because you can get it if you're using the SetupDi routines.  I need to be able to track some kind of unique information about each instance.  The hub/port is the only thing I know of that is unique if you have two identical devices installed on the same system.  There may be something else, but that's the only thing I know of.

Bill

One other question I have seen asked on other forums: Why doesn't Cypress publish the source to the CyUSB.sys driver and CyAPI library?  You're in the business of making the ICs and these are tools to help people interface with them.  You don't make any money on these products and you give away the source code to everything else.

If I had the source to CyAPI, I could add the hub/port information to the library myself in a fairly short time.  I'd rather not use the lower level API if I can avoid it.  It looks like a lot more coding to do the same things CyAPI does for me.  This is the only stumbling block.

Bill

Bill,

Actually Cyusb.sys is a propritery source and cypress does not give this out.  But you can get the source of cyapi  under a software license agreement from cypress by creating a tech support case.

-shub

I was able to sucesfully address a very similar issue. Although, I have to admit my solution will require some additional firmware design. I use this technique to match-up a numbered PCB to board-specific calibration parameters from a data source (file, DB, whatever...) in software.

How are you programming your firware? Bootloading or is it all pre-programmed onto an EEPROM? My approach is based on the former...

The EZUSB devices requires at least an EEPROM to store your VID/PID information ("boot" EPROM as CY calls it). There is enough additional space left over to store a few bytes of serial-number information. So, when the VID/PID is programmed to the EPROM during manufacturing/testing, the PCB serial number is written in the bytes that follow.

In the firmware I created a vendor-specific command that re-reads this boot EEPROM form the i2c interface, parses out the serial # bytes from the stream and sends those back as the data payload for the EP0 command.

This approach works well. However, if your firmeware is on a "hard" ROM or your EPROMS are vendor-programmed em-masse this approach may not work for your manufacturing process. After all, it does mean that each ROM is "custom"...even though it's only a 2 byte diff.

I just saw this.  The hardware is fairly low yield production.  On the order of a dozen units a year (though the way sales have been the last few months, it could be twice that this year).  The firmware is being downloaded for development, but will be burned into an EEPROM in the real world.

My customer put a rotary hex switch on the card edge and wired it up to the lower nibble of Port A.  I'm reading that at firmware init and setting one of 16 device descriptors.  It's a little kludgy, but it works.

Bill

My system can have from 1 to 13 USB devices and I'm concerned about whether the user can power down the computer and be assured that the system will come back in the same state.

I did some experiments and expected the device order (Device # - # being the number sent to the Open() call) to track the USB ports, but instead, no matter how I swapped the USB port locations where the devices were plugged in, I always had:

Device 0 tracked Serial Number A

Device 1 tracked Serial Number B

Device 2 tracked Serial Number C

I changed the serial number of Device 0 from "A" to "D" and then the order was:

Device 0 tracked Serial Number B

Device 1 tracked Serial Number C

Device 2 tracked Serial Number D

Customer will not be able to change the serial number.  Can I be assured that the device ordering will track serial number?

USB spec does not say anything about this. So you may not see this in all OSes.

One thing you can do it populate the devicehandle array using serial number to remove this dependency and be clear of any assumptions rather than relying on the OSes to do it the same way.

Regards,

Anand

 Thanks Anand,

I was trying out the new 64 bit driver and I mistakenly assumed that it was the new driver that was causing the difference in ordering.  I'll have to start testing with 32 bit/XP too.

Pam