Should I also include VID:PID of the WCH-Link to the KNOWN_CMSIS_DAP_IDS?

Hi @eugene-bright! Please take a look at commit a926e94 that adds support for another non-compliant CMSIS-DAP probe. (Man, I wish people would properly implement the spec… 😩) Those changes match solely against the VID/PID, so you won't need the accepted names change. (It also works on all supported OSes/backends.)

The only change needed should be adding the WCH-Link VID/PID to KNOWN_CMSIS_DAP_IDS in pyocd/probe/pydapaccess/interface/common.py.

You'll also need to rebase your changes onto the develop branch and update this PR to target develop.

Finally, please add your copyright below the existing copyrights in the file(s) you edit.

If you're quick, you can get it in before the 0.34 release coming late today or tomorrow! 😉 Thanks!

@flit Thank you for the valuable advice. In the related issue I was instructed otherwise (to not try to use matching by VID:PID).
I'm worried about the commit a926e94. Will it ever come to main from develop?

Lol! 😄 Sorry, I'm behind on issues lately since I've been focusing on preparing for the upcoming release, so I hadn't seen the comments from @elfmimi.

Imo, there's are arguments to be made both for matching by name and ID pair.

develop will be merged to main shortly, right before the upcoming v0.34 release is made. Standard development process. It keeps main free of potential new bugs and regressions until code on develop is ready.

At the minimum, please include the VID/PID in the list in common.py.

It's up to you if you want to add a generalised device name matching mechanism like your initial commit for this PR. However, it will need to work with all USB backends for CMSIS-DAP (hidapi, pyusb, pyusb_v2, pywinusb). So if you decide to implement this, please move ACCEPTED_DEVICE_NAMES to common.py and add a device name matching function there that is imported and used in the backends. (Hrrmm… possibly even a single matching function that takes the device name, vid, and pid…)

I think I need to leave a comment on that VID(0x2a86) , which my instinct tells me is not officially approved.

@elfmimi Very good point. According to the official USB-IF vendor IDs list, VID 0x2a86 (decimal 10886) is registered to "KITRIS AG". Ummm…

(Aside: Why is the world would the USB-IF list vendor IDs in decimal? Have you ever heard of someone reference a VID in decimal? Of course not. 🤣 )

Fwiw, Patrick Yang, the CTO of WCH, is on twitter. Someone might ask him publicly why the WCH USB VID is assigned to Kitris AG. 😜

There's more to this VID story! Apparently another version (?) of the WCH-Link has the VID 0x1A86. (See #1121) This value is correctly registered to Nanjing Qinheng Microelectronics Co., Ltd., aka WCH-IC.

So either someone made a stupid typo in the code? Or something more nefarious is going on. 🤨 Is this 2a86 variant a clone of the real WCH-Link?

Probably 0x2a86 is a clone. When I disassembled it I saw marking on the MCU erased. Probably that's done to make the tracking of the producer harder.

The develop branch lacks some commits from main. That's strange...

It works for me

$ python3.10 -m pyocd list 
  #   Probe/Board       Unique ID      Target  
-----------------------------------------------
  0   wch.cn WCH-Link   0001A0000001   n/a

I'm in Ukraine and have to go to sleep to not die from exhaustion. I'm not interested in having any copyrights (and recommend to follow Linux kernel sign-off practice). Please do whatever you see profitable with the code.
See you tomorrow

'Night! Take care.

I moved the script, but the rest is outside of the scope of this ticket. My adapter doesn't have bInterfaceClass == 0xff and thus it's not DAP-Linkv2.
I think of how to unify pyusb_backend.py and pyusb_v2_backend.py. This files are way too similar. The inheritance could be appropirate in this case.

Right, the pyusb v1 and v2 files are very similar and need to be refactored.

/azp run