On 2012.09.04 00:04, Chris McClelland wrote: > Presumably the same is true for the set-alt-interface call?
Unlike what is the case for SET_CONFIGURATION, there's a WinUsb_SetCurrentAlternateSetting() we can use in WinUSB, so we're not limited there. > If you're interested, the project I'm porting (from libusb-0.1) is > FPGALink: > > http://www.makestuff.eu/wordpress/software/fpgalink/ Ah, but of course, your name was familiar... Great work with makestuff! And that FPGALink project looks pretty cool too. > The performance difference is staggering. The libusb-0.1-based version > did about 26MiB/s, whereas the libusbx-based version pretty much maxes > out the bus, achieving about 43MiB/s, at least on Linux. Windows > performance is less impressive (something like 33MiB/s IIRC). I'm hoping > the forthcoming support for the libusbK back-end will improve that. Thanks for the info. And yes, I too hope the new drivers can help with performance. > Interestingly I have been using my own fxload replacement for several > years, which I have now ported to libusbx (but not yet pushed to > github): > > http://www.makestuff.eu/wordpress/software/fx2tools/ Now you tell me! ;) For what is worth, I too have a partial port of cfxload/libfx2loader with libusbx support, which is one of the option I investigated before going the fxload route. While I have to say your code is A LOT cleaner than the fxload one, and offers more features out of the box (plus personally, I like GPLv3 better than GPLv2), I eventually thought it wouldn't fit the bill for a libusbx sample, especially as we would have to revert your breakdown into small sources and library vs app, to provide something more monolithic. Can't say I'm still 100% sure I'm making the right choice (and at the very least, I'd like to use your firmware with the vendor commands for eeprom flashing), but on the other hand, I don't think having 2 competing apps for programming FX devices, that are both based on libusbx, will be that bad for FX users. If anything, it'll give them more choice, and more features to pick from. > I tried setting the debug level higher but it had no effect; I suspect > the Windows and Ubuntu binaries hard-code it disabled. I'll try building > from source tomorrow. The 1.0.9 version of the library doesn't come with logging enabled by default, unlike later versions where it can be set on the fly, so you will indeed need to recompile. > In any event, I think I might have found my problem, and it's (surprise > surprise) in the firmware. As a library developer, that's of course what I was also hoping to hear. > The FX2 is...eccentric. I will agree here too. I've spent more time than I'd like trying to flash my EEPROM without using the Cypress driver, and trying to make sense of why it doesn't work... > I will trawl back through the commit-log and try to get back to a known- > good state. OK. Don't hesitate to let us know if you pick up potential issues with libusbx. Regards, /Pete ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
