On Fri, Jun 26, 2009 at 11:56 PM, Dominic<dominic.r...@gmx.de> wrote:
> I've been investigating the Windows USB mess a little yesterday. Maybe > someone can help fill in the uncertainties, here's what I have collected so > far. > > o libusb-win32 is API compatible with libusb 0.1, but is capable of > somethings that libusb 0.1 can't libusb-win32 has two development branches. libusb-win32 0.1 is API compatible with libusb 0.1 and adds isochronous transfer and asynchronous I/O support specific to Windows. > o libftdi apparently works with libusb-win32's API (see for example > Freddie's post) Yes. > o libusb-win32 comes with 3 (maybe 4) backends > - a libusb driver and a libusb filter driver (not sure if this > differenciation is still correct) > - a HID backend (I've seen something like that with Keil's ULINK I guess, > which looks like a HID to Windows, and thus needs no driver) > - a WinUSB backend This is libusb-win32 1.0 branch. Unfortunately it is not working yet and I do not know when the author will get time to get it working. Several people suggested WinUSB backend to fix Vista 64 issues. I suggested the HID backend since there are issues to use libusb-win32 with HID device. > o libusb-win32's drivers are supposed to be a dead end because they wont > work with 64-bit windows (and probably not with Windows 7), but they do work > for > older versions that don't have WinUSB support (particularly 2000... leaving > 98/ME behind doesn't sound overly disturbing to me) > > o the FTDI chips are not HID, so the HID backend is dead for our purposes The HID backend is for other device. There are many HID based device. Typically we use native HID API to access HID device. But many programs use libusb to access HID device under Linux. > o the WinUSB backend brings a WHQL signed driver, which is good, because it > runs on all windows versions that required signed drivers (Vista 64-bit, > Windows 7) > > o The WinUSB How-To says that you need to get the whole driver package > including the .inf file signed. Some postings to newsgroups suggest that > this is not necessary. It might be that you get a warning, which shouldn't > be that much of a problem. It is ok to load the driver even though there is a warning. You can do the same with libusb-win32 device driver if somebody can pay the digital signature (not so expensive). One company already got their libusb-win32 based device driver certified by WHQL but they renamed all the driver name to their own name. > o libusb-win32's development seems sporadic if not stalled You can say it is stalled right now since the SVN is 22 months old. > Conclusions > > + libusb-win32 would be good, because it works on all present windows > platforms, and because it's supposed to work on upcoming versions, too > > + libusb-win32 would be good, because it allows us to use libftdi, which > implements all the FTDI-chip specific USB communication. Using the > information available in libftdi wouldn't be much of a problem, but it's > certainly a lot of coding work that is mostly unrelated to OpenOCD > > - I have no idea about how stable and reliable libusb-win32 is Based on my experiences it is quite good. The filter driver can cause many problems (including serious BSOD and lost of all USB device) and is no longer recommended by the author. The device driver has never caused problem for me. > o (Re-)writing libftdi with plain WinUSB should be possible and would remove > the uncertainties of libusb-win32, but would burden the OpenOCD project with > the task of keeping it stable and up to date. It would also leave out > Windows 2000 and before. > You can always use libusb-win32+libftdi for Windows 2k. If possible, some people with Windows knowledge can look at the libusb-win32 1.0 branch to judge how mature (or im-mature) it is. WinUSB is a good solution with or without libusb-win32. If libusb-win32's WinUSB backend can be made to work, it is of course better since it will benefit other open source projects as well. But a WinUSB based solution specific to OpenOCD (for FTDI) device may be easier. -- Xiaofan http://mcuee.blogspot.com _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
