CH341A futher improvement -- to support MSVC build

[mcuee]

Other than #1336, the other main issue with #1215 is that it only supports libusb-1.0 API. Therefore the default Windows MSVC build will not work since it uses avrdude-libusb which only supports libusb-0.1 API.

It will be good to add support for MSVC build via avrdude-libusb.

[stefanrueger]

It is unclear to me what a path to solving this issue is. None of the current maintainers have given this priority, so it is unlikely to be fixed anytime soon. There are (literally) 15 open issues mentioning libusb. This particular one sounds to me that time might solve it, eg, once MSVC supports libusb-1.0. In which case doing nothing might be OK? I suggest closing as won't fix.

[mcuee]

@stefanrueger

I think it is okay for an issue (especially enhancement request, or low impact bug) to exist for long. In avrdude we have very old issues which no one is working on. Netheverless they are still valid issues.

As for MSVC build, right now it is the default Windows binary provided when releasing avrdude. And it is using avrdude specific avrdude-libusb which was very useful when libusb-1.0 library had major problems with libusb0.sys. With libusb-1.0.26 release (on 11-April-2022), I see less issues (but there are still some issues) with libusb.sys now.

We can swtich msvc build to use official libusb-1.0 project and then this issue and #968 can be closed. However, we should hear @mariusgreuel's opinion on this topic. Take note that #968 is not a critical issue and this #1339 is just an enhancement,

[mcuee]

Issues related to msvc build using avrdude-libusb.

• avrdude MSVC build problem with USB composite device (avrdude-libusb library issue) -- low priority #968

[mcuee]

There are (literally) 15 open issues mentioning libusb.

https://github.com/avrdudes/avrdude/issues?q=is%3Aissue+is%3Aopen+libusb

I will explain one by one.

• [patch #8954] Enable usage of libusb-1.0 for stk500v2 (aka avrispmkii) #704 -- I will close it as @dl8dtl mentions that avrdude will continue to use libusb-0.1 API.
• Flashing an Arduino Leonardo with AVRDUDE is troublesome #788 -- not really related to libusb, rather related to USB serial port handling
• Rework PICKit2 programmer to use libhidapi instead of libhid (which will make it work under macOS) #883 -- not really related to libusb, rather related to use hidapi (help wanted from community)
• Add Apple M1 silicon to Nightly-Builds #939 -- nothing related to libusb, it is rather related to lack of Apple Silicon github action machine (may soon get sorted out by github)
• Unable to build libavrdude dynamic and static library with CMake buildsystem #952 -- nothing related to libusb, rather related to CMake
• avrdude MSVC build problem with USB composite device (avrdude-libusb library issue) -- low priority #968 -- this is the main bug related to the current MSVC build (not using libusb but rather avrdude-libusb), but it is of low impact
• Differentiate multiple USB programmers of the same VID/PID (libusb or hidapi or libftdi) #973 -- this is related to libusb but not limited to libusb, but also USB serial port and hidapi/libftdi
• Linux and macOS releases are missing -- static linking version preferred (Low Priority) #987 -- nothing related to libusb, rather related to CMake
• Enhance CMake to be able to support static link for Linux and macOS #1159 -- nothing related to libusb, rather related to CMake
• Atmel ICE/PowerDebugger TPI issues on MacOS #1217 -- not elated to libusb but rather hidapi issue or FW issue
• PICKit 4, SNAP, Atmel ICE and Power Debugger only work with hidapi but not libusb (low priority) #1221 -- libusb related, I believe it is an avrdude bug. However, it is of low impact as hidapi is the right library to use and not libusb (unless on NetBSD/OpenBSD which do not support hidapi)
• ftdi_syncbb: very slow D2XX based MSVC build compared to libftdi based MinGW build #1253 -- not really related to libusb, but rather related to avrdude-libfftdi versus libftdi. I actually support @mariusgreuel's use of avrdude specific avrdude-libftdi under Windows since it does not need to swtich Windows driver (if using libftdi).
• Abstract out transport -- libusb and hidapi #1316 -- libusb related but not limit to libusb but also hidapi/libftdi/etc, This can be a code refactoring exercise whch I think may help avrdude project in the long run.
• CH341A futher improvement -- to support lower clock AVR chips #1336 -- not really related to libusb
• CH341A futher improvement -- to support MSVC build #1339 -- related to avrdude-libusb usage in MSVC build under Windows

So in the end, only two issues are really related to the use of avrdude-libusb for MSVC build under Windows.

• avrdude MSVC build problem with USB composite device (avrdude-libusb library issue) -- low priority #968
• CH341A futher improvement -- to support MSVC build #1339

[mcuee]

There are two enhancement which may benefit avrdude project to bridge the difference between different platforms.

• Harmonize WIN32 implementation of serial time-outs with Posix one #1249 -- between Windows (both MinGW/MSVC) and Posix systems
• To adopt PR #1264 approach of using Readline replacement for MinGW build (Low Priority) #1271 -- between Windows MSVC build and MinGW build (not a major issue, especically when MinGW build is using GNU Readline).

[stefanrueger]

@mcuee Thanks for analysing and closing some of the issues that no longer need attention.

[mcuee]

Move this to discussion.

[mcuee]

Close this for now as it is already a known limitation documented.
https://github.com/avrdudes/avrdude/wiki/Known-limitations-of-avrdude