On Wed, Dec 1, 2021 at 3:40 AM Joerg Wunsch <[email protected]> wrote: > The latter is what ARM went for, with their CMSIS-DAP spec. I think > it's a big crock, but the grok "every device looks like a human > interface" is quite present in many places, mainly due to Windows not > providing a generic USB driver for every device straight from the > beginning of their USB support (WinUSB came much later). As they > (obviously) did have to provide out-of-the-box HID support, people > went that way. ("Please install a device driver for your keyboard. > Press <Enter> to continue." :-)
CMSIS-DAP has two version, one for HID and the other with WinUSB. For HID devices, we recommend HIDAP and not libusb. https://github.com/libusb/libusb/wiki/FAQ#Does_libusb_support_USB_HID_devices > Having said this, as long as it doesn't break libusb support (which is > the common baseline for all Unix-like systems), and doesn't add a > truckload of more #ifdefs, it's certainly fine to have that. If it > works well, I even think libusb support is no longer needed for > Windows anymore. It only went there in order to support Windows at > all. As mentioned in the other reply, it is good to move away from libusb-0.1 API to libusb-1.0 API. > > The easiest way to get Windows to load the WinUSB driver > > automatically, is to add a WinUSB compatibility descriptor to the device > > firmware. > > That's again where I don't really understand Windows. Why is it > necessary to have *any* specific hack at all? Why couldn't they just > offer WinUSB for *every* device, at least for every device that hasn't > any more specific driver? > > But OK, we won't change Microsoft here. It's just cumbersome to deal > with. Yes it is unfortunate that Microsoft does not ship with a generic USB driver... But then more JTAG debuggers or programmers are moving to WinUSB driver or HID, and with things like Zadig, life is as difficult as before under Windows. > I'd be more than happy to have a Windows guy in the boat, hopefully > including someone who can roll native Windows binary releases as well. > So far, I've always been rolling them using a MinGW32 > cross-compilation on my FreeBSD development system, but that isn't > something running very smoothely anyway. So well, if you want to > actively support AVRDUDE development on the Windows front, be welcome! > I will recommend Windows developers to use MSYS2 which has good infrastructure to support building avrdude from source. $ pacman -Ss avrdude mingw32/mingw-w64-i686-avrdude 6.3-2 Software for programming Atmel AVR Microcontrollers (mingw-w64) mingw64/mingw-w64-x86_64-avrdude 6.3-2 Software for programming Atmel AVR Microcontrollers (mingw-w64) I provide libftdi binaries for Windows and it does not take much time for me to do that regularly with the help of MSYS2. https://github.com/mcuee/libftdi/releases https://sourceforge.net/projects/picusb/files/ -- Xiaofan
