Lou, > > The issue is that the rlink uses a slightly unique driver > (forget the > > name) that the libusb filter driver cannot see. > > you have to remove the standard rlink driver and use the > main libusb driver. > > So that driver being active prevents the interface from even > so much as appearing to libusb? Freaky. The rlink support > uses libusb, so anything that is needed to use libusb under > Windows is needed here. > Including things like not having other drivers competing with > libusb for the device. >
windows drivers work in a strange way, each device has a registered driver, eg. rlink uses the jungo driver by default. libusb-win32 has two ways of accessing a device, we can install libush as the default driver or use a filter driver. > > > > This is a pain as other interfaces (jlink, ftdi) behave > fine with the > > filter driver. > > If there's something I should be doing differently to make > that work nicely, I'm interested. I don't know what that > would be, though, since the device seems not to even show up > in the bus/device list under the problem condition. Perhaps > that's something to do with the way the/a filter driver works. > The tweak would be in libusb-win32, i may look into this to see why the filter driver is not being loaded for the jungo driver. > I don't have a Windows machine to test on. Only Linux. I > surmise that this filter driver thing has something to do > with LibUsb-Win32. > > > To be honest though the best way to access the interface is > directly > > rather than using the filter driver. > > Well ok, then. Any drawbacks? > No, except raisonance tools will not see the rlink. The advantage of using the filter driver is that openocd and ride will see the rlink. Cheers Spen _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
