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.
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.
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.
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.
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.
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.
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.
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.
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.