wch: general maintenance status + plans for future development

[BOJIT]

Hello! I thought I'd make this discussion as a general location for tracking progress/support for the WCH platform on Zephyr.

There's recently been a few attempts to add support for some more of WCH's microcontrollers to Zephyr. The structuring of WCH's chip offerings is quite chaotic and hard to follow, so it's often unclear which peripherals are common across different chip series. WCH provide the following diagram, but the peripheral compatibility and CPU core don't seem to follow a neat pattern.

To make development/testing a bit easier, I'm proposing the following grouping of driver/binding support in Zephyr for WCH.

So far, everything added to zephyr is in the CH32 family, but there has been interest in adding CH5xx support in the future, which has mostly incompatible peripheral drivers. In future I'd suggest that drivers/bindings have a ch32- prefix unless they are guaranteed to work with the CH5xx family too.

Anything that is more specific (e.g. clock controller bindings, pinctrl, etc...) should have a prefix for the sub-family of that chip-type. This should make it less likely for us to inadvertently break something while modifying a driver for another family.

NOTE: at this point I'd like to suggest that support for any of the ARM cortex-M and 8-bit WCH MCUs is not in scope for Zephyr. These don't seem to be particularly popular chips, and supporting both these and the RISC-V chips will be an excess burden for the limited number of contributors.

Contributors for Each Family

Most of us using WCH MCUs are only using a subset of the supported SOCs. For the purposes of testing, it would be helpful if people could add which boards they have / regularly use here. This is my best first guess:

• @BOJIT : Mostly use CH32V307, occasionally use CH32V305, CH32V317.
• @nzmichaelh : CH32V006, CH32V203.
• @kholia : CH32V003.
• @VynDragon : CH32V003, CH32V006, CH32V203, CH32V208, CH32H417, CH592, CH570D. Regularly uses none of them.
• @miggazElquez : CH32V303.
• @kloenk : CH32V003, CH32X035, CH32V203.

General Tasks/Aims

It would be good to track what people want to see added / are working on adding to WCH zephyr support. For example, I'm currently trying to work on:

• CH32V305/317 support
• USB UDC driver (20x_30x family)
• Ethernet PTP Clock + fixes for CH32V317
• Add proper support for FLASH/RAM split in Zephyr runners + wlink.
• Flash controller driver for WCH (enables NVS + MCUboot usage, will be complicated by To adapt the flash driver for WCH's CH32VXX series MCUs, it is necessary to modify the definition of the variable 'uint8_t erase_value' in the existing flash driver. #100490)

Useful Links

• Open WCH Issues and PRs

It would be great to hear people's thoughts on this, plus any other suggestions for features/direction of the platform!

[nzmichaelh]

re: excluding anything except RISC-V, I agree.

re: bindings, is the plan to use a family prefix only when needed? For example, do we keep wch,gpio or does it get split?

re: names, I see some are wch,v*, wch,x* etc while some are wch,00x-, wch,20x-30x-. I'd always put the letter there, so wch,v00x- partly so any derived identifiers can start with a letter.

re: ch32v003 vs ch32v00x, the 003 is often different compared to the 00x like the 006, so I'd define a wch,v003 prefix for it

re: chips I mainly use the ch32v006, but have a few ch32v003evt's, a bluepillplus_ch32v203, and two weact linkw clones. Happy to test any patches on these.

re: plans, I don't really have any. I like writing drivers to write drivers, and like enabling all of the features on a chip and trying to get good performance out. My current WIP branch is https://github.com/nzmichaelh/zephyr/tree/ch81 / https://juju.nz/src/michaelh/zephyr/src/branch/ch81 and I'm sending those upstream ATM.

I'm also keen on testing. I could add ch32v003 and ch32v00x configurations so that Twister includes at least a "still compiles" test. I see linkw got included in the defaults sometime which is good.

[BOJIT]

Regarding the bindings prefix, as long as the driver covers all/most of the families it can stay without a prefix.

So for wch,gpio, I reckon that's fine as the GPIO controller it the same on all the CH32s. Whereas something like wch,afio seems to be specific to the ch32v003 , so should be changed.

That being said, most of the existing drivers won't work on the CH5xx series, but I think that changing all of the incompatible drivers to have a ch32- prefix is not worth the trouble it will cause. But for future drivers I'd recommend adding a ch32- prefix to drivers that aren't explicitly compatible with the CH5xx series.

Regarding the derived identifiers starting with a letter, good idea. I'll update the diagram.

[kloenk]

Do also have a 003, and a few x035. Hopefully getting a 307 soon as well, but not yet here

[miggazElquez]

I have only the 303, and I can test code on it if necessary.

About plans, short term I won't have much time to develop anything. Middle term, if @BOJIT didn't complete the USB UDC driver (20x_30x family), I will probably get back on it to get it finally working, but I don't have time for it right now, so feel free to do it if you want.

[BOJIT]

Nice - regarding the USB UDC, I did get it working (albeit not if CONFIG_PM is enabled yet).
However in Zephyr 4.4.0 there were some USB UDC driver changes that I haven't updated yet.

Currently the main thing I want to get working is 100M Ethernet on the CH32V317 (annoyingly has some quirks compared to the 307). But after that I plan to try and get the UDC driver merged.

[kloenk]

Really hope to get the clock rework working soon and then tested on the different families. Hoping we can integrate it into the new drivers directly instead of the current mess