Thanks but this isn't a acceptable solution in most of the cases. Typically one could attach two or more devices of the same type (ex 2 or 3 cams). 2 instances of the same Application should be able by design to open different Cams and interact with them without generating problems or interfere between them self.
Which kind of mechanism is Cypress using for overcome this problem ?
The KB article that I provided is capable of acheiving the same. Once a handle is opened that particular device will not be visible to other applications. After the handle is closed it will be visible to other applications too.
If a feature like this needs to be implemented in a method other than that, the driver has to maintain a variable to represent this (CyUSB.sys one instance irrespective of number of devices connected to it, not the case for CyAPI.lib) and provide that to CyAPI.lib. There are also a whole bunch of scenarios that need to be discussed and understood. Please create a tech support with details on why you need this feature and what are the specific scenarios that need to be met. This way our team can internally discuss and figure out what needs to be done.
Hi, this isn't correct. I added the "exclusive" registry entry which you told me and I got the following behaviour:
only one Cypress device ( I suppose that exclusivity is related to devices which are using the Cypress driver) is visible at the time even if they have different PIDs (ex: boot and streamer firmware). The windows 7 device manager tells: "Windows cannot load the device driver for this hardware because a previous instance of the device driver is still in memory. (Code 38)". As soon as I remove one of the 2 devices (which for instance have different PID) the remaining device is able to load the driver into the memory. This means with your modification (under Windows 7 64 bit OS) only one device can be in use. This of curse solves the issue of concurrent access to a particular device since it allows only 1 device to be present on the system, but I think you can agree that this isn't an acceptable solution for a professional product.
The target scenario is very simple and is going to happen to everybody as soon as they sell an FX3 based product. I have two identical USB 3.0 products (Same PID and VID, maybe only the serial number is different). Both devices are then connected to the USB 3.0 tree of a PC. What one would expect is that two instances of the same or a different application are able to open and use one of the two FX3 devices. It shouldn't be possible that the two applications are opening ad using the SAME FX3 device (isn't it?).
Under MS windows it isn't possible to open and use twice a given serial port. I would expect the same behaviour also for a USB device. I would expect a sharing mechanism to be implemented at a higher level than the driver.
What I need is a mechanism which allows me to handle in an exclusive manner 2 FX3 based devices both connected at the same time to the same host PC. Both of them shall be usable.
Best regards, JoeBre