Add Zephyr RTOS support for WCH CH32V003

[kholia]

Details

This PR adds Zephyr RTOS support for WCH CH32V003 RISC-V MCU.

https://www.wch-ic.com/products/CH32V003.html

Usage

west update

west build -p always -b wch_ch32v003evt samples/basic/blinky

west flash -r minichlink

Tested On

• Bare CH32V003J4M6 SOP-8 chip

• WCH CH32V003EVT board (CH32V003 Evaluation Kit)

Blinky Build

$ west build -p always -b wch_ch32v003evt samples/basic/blinky
...
-- Zephyr version: 3.6.99 (zephyr), build: v3.6.0-5403-g90b43c51ff3f
[101/101] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
             ROM:       10056 B        16 KB     61.38%
             RAM:        1524 B         2 KB     74.41%
        IDT_LIST:          0 GB         2 KB      0.00%
Generating files from zephyr/build/zephyr/zephyr.elf for board: wch_ch32v003evt

It is fun to see Zephyr RTOS running on a "10 cent" MCU.

[github-actions]

Hello @kholia, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

[zephyrbot]

The following west manifest projects have been modified in this Pull Request:

Name	Old Revision	New Revision	Diff
hal_wch	N/A	zephyrproject-rtos/hal_wch@1de9d3e (main)	N/A

Note: This message is automatically posted and updated by the Manifest GitHub Action.

[kholia]

All references to ch32v003fun.h filename are now confined to modules/hal_wch interface layer folder.

[dhiru@zippy zephyr]$ rg ch32v003fun                                                                        
modules/hal_wch/ch32_rcc.h
11:#include <ch32v003fun.h>

modules/hal_wch/ch32_gpio.h
11:#include <ch32v003fun.h>

modules/hal_wch/CMakeLists.txt
2:  zephyr_include_directories(${ZEPHYR_HAL_WCH_MODULE_DIR}/ch32v003fun .)

modules/hal_wch/ch32_uart.h
11:#include <ch32v003fun.h>

modules/hal_wch/ch32_soc.h
11:#include <ch32v003fun.h>

modules/hal_wch/ch32_pinctrl.h
11:#include <ch32v003fun.h>

modules/hal_wch/ch32_systick.h
11:#include <ch32v003fun.h>

modules/hal_wch/ch32_pfic.h
11:#include <ch32v003fun.h>

[fabiobaltieri]

Seems like a good starting point, would be cool to redo the clock configuration in devicetree rather than kconfig options but that can be a followup. To the other folks in the review list, can you do another pass?

[cnlohr]

The clock tree on the 003 really only has 4 reasonable configurations, XTAL/internal and PLL/no PLL. There are extra main clock divisors you can use, but their practicality is very low. Is it expected to have richer configurations in things like this?

[nzmichaelh]

The clock tree on the 003 really only has 4 reasonable configurations, XTAL/internal and PLL/no PLL. There are extra main clock divisors you can use, but their practicality is very low. Is it expected to have richer configurations in things like this?

My vote is no, but if someone wants to add it in a follow up and it (ideally) doesn't increase the flash usage, then that's all good.

I think it's reasonable for Zephyr to support the common configurations. For example, it shouldn't cover just the CH32V003JM46 but all part numbers; and it shouldn't be HSE only but both HSI and HSE.

[cnlohr]

The clock tree on the 003 really only has 4 reasonable configurations, XTAL/internal and PLL/no PLL. There are extra main clock divisors you can use, but their practicality is very low. Is it expected to have richer configurations in things like this?

My vote is no, but if someone wants to add it in a follow up and it (ideally) doesn't increase the flash usage, then that's all good.

I think it's reasonable for Zephyr to support the common configurations. For example, it shouldn't cover just the CH32V003JM46 but all part numbers; and it shouldn't be HSE only but both HSI and HSE.

All the 003 part numbers have identical cores, flash RAM and clock trees, thankfully.

[cnlohr]

It's getting very close, @fabiobaltieri !

[cnlohr]

@kholia do you have a summary for what you changed? Or who's if any's quests have been changed?

[kholia]

@cnlohr I just added select ATOMIC_OPERATIONS_C line and rebased the PR on top of latest upstream main.

The current build failure does NOT seem related to this work.

I will rebase and re-push the commits.

[kholia]

I have rebased and re-pushed the same commits in the hope of passing the CI checks!