Use native WCH driver for LinkE programmer on Windows?

[AlexanderMandera]

Is it possible to use of the "WCHLink_A64" driver on Windows instead of the libusb for the LinkE programmer?

The use of Zadig makes the "out-of-the-box" flashing experience a bit more difficult, see https://github.com/AlexanderMandera/arduino-wch32v003/issues/9

I don't know where I have seen it in the past, but I saw a program that used an additional DLL instead of libusb, so the native driver could be used.

Is something like this desired?

[cnlohr]

I would really appreciate it if someone could write that. I put some effort into it and didn't get anywhere :(

[jnk0le]

Here are diffs of GPL-lettered MRS openocd fork: https://github.com/karlp/openocd-hacks/commits/mrs-wch-riscv-221010

from a quick look - it still invokes libusb api

Also I'm hosting windows builds of this fork here: https://github.com/jnk0le/openocd-wch/releases It would be good to make it work with just the zadig.

IMO we should avoid proprietary chinese drivers as much as possible.

[AlexanderMandera]

But then we should add a feature to change/install the drivers without using additional software like Zadig.

I have looked into the same repo and it seems to use a WCHLinkDll.dll of some sort (see https://github.com/karlp/openocd-hacks/blob/266d7c8d3f6ceae5e600de13d39a1dedc6b1d604/src/jtag/drivers/wlink.c#L1430), and it looks like it is used for every programmer on Windows.

But that DLL would be proprietary, so an automatic driver replacement and an option to revert it would be a good idea.

What do you think? @cnlohr

[PBrunot]

@AlexanderMandera I share my experience on Windows. I installed the proprietary MounStudio, it automatically updated its drivers and got MounStudio to download a sketch on the CH32V003. Then, I installed platformio extension with VSCode, ran an example from this library, and it worked on first try. Even debugging (e.g. step by step instructions) is working flawlessly. I've got the following hardware WCH_LinkE rev 1.1 from Aliexpress

[jnk0le]

It would be good to make it work with just the zadig.

ok, the solution was dumber than I thought https://github.com/jnk0le/openocd-wch/commit/aa6b548f74dbfba2f240660fcc70ed70f12a1ca9

[cw2]

I would really appreciate it if someone could write that. I put some effort into it and didn't get anywhere :(

@cnlohr @AlexanderMandera If anyone is interested, I have managed to implement an initial version of minichlink communication over WCH custom/proprietary driver "WCHLink_A64" on Windows - the code is available at https://github.com/cw2/ch32v003fun/tree/experimental/minichlink-wchlinkdll-driver

Important notes, known issues & limitations:

• The code is experimental work in progress, use at your own risk, etc. ;)
• In order to build the binary, open the folder in a recent version of Visual Studio with CMake tools installed,
• The code is based on information publicly available on the Internet,
• The WCH library WCHLinkDll.dll is not directly used,
• The potential integration into minichlink is subject to further discussion, please consider the current implementation as a hack only (especially outside pgm-wch-linke.c)

[cnlohr]

I'm not going to accept MSC_VER in the main 003fun headers. We could do something like HOST_SIM or something like that. It's ok in the minichlink code and headers though, i.e. VS using non-standard strcasecmp

Why did you use VS? The linking process for DLLs cross-target becomes so much messier and their DLLs are much larger than if you use clang or GCC. Also GCC/TCC/Clang has all of the features that we use for things like getopt, etc. VS also significantly hampers who is going to be willing to work on/maintain this.

I love removing the dependency on libusb on Windows, it's always a prick in my side, but it is something that we need to support in Linux, so we'd need to guard it with a #define. I wonder if there's a way for you to just make "libusb" functions in a #if defined(WINDOWS) || defined(WIN32) || defined(WIN64) at the top, that does the scary USB stuff inside them, so the main part of the code still reads clearly. Though honestly, what you've done is probably OK enough if guarded by #ifdef's.

[cnlohr]

To clarify - I still absolutely would accept a VS solution, but, it's just not how we normally build on Windows... And we already have means to target windows in CI and how users do it, with Make.

[cw2]

I'm not going to accept MSC_VER in the main 003fun headers.

I am not going to ask that ;) Regarding the use of VS, I have my reasons, but rest assured there will be absolutely no trace in the final code...

I love removing the dependency on libusb on Windows, it's always a prick in my side, but it is something that we need to support in Linux, so we'd need to guard it with a #define. I wonder if there's a way for you to just make "libusb" functions in a #if defined(WINDOWS) || defined(WIN32) || defined(WIN64)...

I can replace libusb functions, resp. make them conditional compile on Windows, that's not a problem, but would not that be a breaking change for users that do not want to use WCH custom driver?