CH341A futher improvement -- to support MSVC build

[mcuee]

Other than #1336, the other main issue with https://github.com/avrdudes/avrdude/pull/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.

• 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.

• 704 -- I will close it as @dl8dtl mentions that avrdude will continue to use libusb-0.1 API.

• 788 -- not really related to libusb, rather related to USB serial port handling

• 883 -- not really related to libusb, rather related to use hidapi (help wanted from community)

• 939 -- nothing related to libusb, it is rather related to lack of Apple Silicon github action machine (may soon get sorted out by github)

• 952 -- nothing related to libusb, rather related to CMake

• 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

• 973 -- this is related to libusb but not limited to libusb, but also USB serial port and hidapi/libftdi

• 987 -- nothing related to libusb, rather related to CMake

• 1159 -- nothing related to libusb, rather related to CMake

• 1217 -- not elated to libusb but rather hidapi issue or FW issue

• 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)

• 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).

• 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.

• 1336 -- not really related to libusb

• 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.

• 968

• 1339

[mcuee]

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

• https://github.com/avrdudes/avrdude/issues/1249 -- between Windows (both MinGW/MSVC) and Posix systems
• https://github.com/avrdudes/avrdude/issues/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.