ch32-rs/ch32-rs

Embedded Rust device crates for WCH's RISC-V and Cortex-M microcontrollers

ch32-rs - WCH's CH32 Peripheral Access Crates

---

Embedded Rust device crates for WCH's RISC-V and Cortex-M(planned) microcontrollers.

Note This project is not affiliated with WCH. This is a hobby project.

Alternatives to PAC crates

The ch32-rs team also working on a unified "metapac" solution for all WCH's MCUs, using metadata to generate an "all-in-one" PAC crate. It's still in early stage, but you can check it out at ch32-rs/ch32-data and ch32-rs/ch32-metapac.

HAL crates

• ch58x-hal - embassy, gpio, spi, i2c, ble
• ch32x0-hal - embassy, gpio
• ch59x-hal - early stage, ch58x-hal can be used with very minor changes
• ch57x-hal - planning, ch58x-hal can be used with very minor changes
• ch32v00x-hal - early stage, requires nightly rust for RV32EC support
• ch32-hal - wip unified hal for all WCH's MCUs

Runtime Support

• qingke, qingke-rt
• wchble - planning

Roadmap

• Toolchains for Flashing and Debugging
  • wchisp for USB-ISP
  • wlink for WCH-Link probe
  • probe-rs support
    • CH32V003 support
    • CH32V307 support, should work with CH32V20x too
    • flash-algorithms
    • Support other families
• HAL crates
  • Support CH32V3x/CH32V2x family
  • Support CH32V103 family
  • Support CH32V003 family, ch32v00x-hal
• Cortex-M MCUs.

Development

# Do not use rust version of svdtools
pip install svdtools

# install xmlint

cargo install svd2rust

./scripts/generate.sh && ./scripts/update.sh

MCU list

• 32-bit General Purpose RISC-V
• 32-bit General Purpose Cortex-M3
• 32-bit High-speed Interface MCU, RISC-V or Unmentioned
• 32-bit BLE MCU, RISC-V or Coretex-M

NOTE: Will never support 8-bit MCUs.

RISC-V

Nick name: "赤菟"(Chitu). IP Core brand: 青稞(Qingke). V2A, V3A, V4A, V4B, V4C, V4F.

• CH32V003: Qingke-V2A
• CH32V103: Qingke-V3A
• CH32V203: Qingke-V4B
• CH32V208: Qingke-V4C, BLE
• CH32V30x: Qingke-V4F
• CH32L103 Qingke-V4C, Low power
• CH32X03x: Qingke-V4C, USB PD, PIOC
• CH56x: Qingke-V3A, USB 3.0 SS
• CH571, CH573: Qingke-V3A, BLE 4.2
• CH58x: Qingke-V4A, BLE 5.3
• CH59x: Qingke-V4C, BLE 5.4
• CH641: Qingke-V2A, USB PD
• CH643: Qingke-V4C RGB/LED/PWM, PIOC, USB PD
• CH645: Qingke-V4C, USB PD + USB HS

Cortex-M

CH32F uses Cortex-M3. CH577/CH578/CH579 uses Cortex-M0.

• CH32F103
• CH32F203
• CH32F205
• CH32F207
• CH32F208, BLE 5.3
• CH577/CH578/CH579, BLE 4.2

Toolchain

• MRS: MounRiver Studio
  • Precompiled binary of OpenOCD is included in MRS(Windows, Linux, and macOS)
  • WCH-LinkUtility is included in MRS
  • WCHISPTool is included in MRS
• Official Flash Tool: NanjingQinheng/WCH-Link
• OpenOCD fork with WCH-Link support(wlink)
  • Buggy, compatible with WCH-Link 2.3
• ch32-rs/wchisp
• ch32-rs/wlink

Ref

• https://github.com/openwch

ch32-rs's Issues

ch58x::Peripherals missing GPIO

Is this expected? I see FieldReader's named like PB_OUT_0_R in ch32-rs-nightlies/ch58x/src/ch58x/mod.rs, perhaps this is how they're intended to be accessed/mutated/etc?

systick::sr is writable

NOTE: There is a second copy of the systick register block exposed from pfic.

I have manually edited the fixup here (together with interrupts), should be possible to be generated:
orangecms/ch32-rs-nightlies@c2a821c

No firmware for Micropython for this ch32v003

Running and flashing this microcontroller board with MicroPython requires firmware associated with this part number CH32V003. Unfortunately, [https://micropython.org/download/] or [https://github.com/micropython/micropython?tab=readme-ov-file#supported-platforms--architectures] does not have firmware for this Microcontroller.

Please help in creating a firmware for supporting micropython.

CH32V003: TIM2RST missing from APB1PRSTR register definition

ch32-rs/svd/vendor/CH32V003xx.svd

Lines 494 to 523 in b9d28b1

	<register>
	<name>APB1PRSTR</name>
	<displayName>APB1PRSTR</displayName>
	<description>APB1 peripheral reset register
	(RCC_APB1PRSTR)</description>
	<addressOffset>0x10</addressOffset>
	<size>0x20</size>
	<access>read-write</access>
	<resetValue>0x00000000</resetValue>
	<fields>
	<field>
	<name>WWDGRST</name>
	<description>Window watchdog reset</description>
	<bitOffset>11</bitOffset>
	<bitWidth>1</bitWidth>
	</field>
	<field>
	<name>I2C1RST</name>
	<description>I2C1 reset</description>
	<bitOffset>21</bitOffset>
	<bitWidth>1</bitWidth>
	</field>
	<field>
	<name>PWRRST</name>
	<description>Power interface reset</description>
	<bitOffset>28</bitOffset>
	<bitWidth>1</bitWidth>
	</field>
	</fields>
	</register>

如何参与项目维护

您好：
我最近在使用ch32-rs社区提供的PAC库进行开发，但发现目前由svd2rust生成的PAC库存在缺陷，在浏览https://github.com/ch32-rs/ch32-rs
项目后，发现项目中并没有svd文件。请问您有计划像stm32-rs社区那样，通过一系列patch来不断修复svd文件中的bug吗？或者我有什么方式可以参与到这个项目中来维护完善ch32-rs吗？

谢谢

Adding "derivedFrom" for various types

Consider UART1 in CH58Xxx.svd, I believe we want the addition of derivedFrom="UART0", giving us:

<peripheral derivedFrom="UART0">
   <name>UART1</name>

Similarly for other UARTs and likely some other types. Any thoughts on how best to approach this? e.g. shall we just send around PRs as needed?

interrupt issues

The interrupt! macro is currently not exported. I tried using the nightlies repo, and for the ch32v3, I tried adding this:

diff --git a/ch32v3/src/lib.rs b/ch32v3/src/lib.rs
index 7246166..58eef19 100644
--- a/ch32v3/src/lib.rs
+++ b/ch32v3/src/lib.rs
@@ -22,4 +22,5 @@ pub use self::generic::*;
 
 #[cfg(feature = "ch32v30x")]
 pub mod ch32v30x;
-
+#[cfg(feature = "ch32v30x")]
+pub use ch32v30x::interrupt;

Now I can use the macro. But I'm not seeing the handler invoked yet when I register one. I think I am always running into the DefaultHandler.
I can use the DefaultHandler when overriding it - though I have no clue how to clear the pending interrupt then, so the handler keeps running infinitely.

And I found that some IRQs are missing, namely those before the watchdog:
https://gitlab.com/eta-for-ci/ch32v307-gnumake/-/blob/945a34b9cf168c2dc8451b044c51f47053528d54/wch/hal_libraries/ch32v307_hal/include/ch32v30x.h#L29

 /******  RISC-V Processor Exceptions Numbers *******************************************************/
  NonMaskableInt_IRQn         = 2,       /* 2 Non Maskable Interrupt                             */
  EXC_IRQn                    = 3,       /* 3 Exception Interrupt                                */
  Ecall_M_Mode_IRQn           = 5,       /* 5 Ecall M Mode Interrupt                             */
  Ecall_U_Mode_IRQn           = 8,       /* 8 Ecall U Mode Interrupt                             */
  Break_Point_IRQn            = 9,       /* 9 Break Point Interrupt                              */
  SysTicK_IRQn                = 12,      /* 12 System timer Interrupt                            */
  Software_IRQn               = 14,      /* 14 software Interrupt                                */

 /******  RISC-V specific Interrupt Numbers *********************************************************/
  WWDG_IRQn                   = 16,      /* Window WatchDog Interrupt 

I can confirm SysTicK_IRQn to be correct. I set up a simple counter, and it triggers (I am logging the IRQ number in DefaultHandler). See here:
orangecms/ch32v307-rust@e063217

error when taking peripheral, using example for CH32V3

I am getting the following error:

error[E0599]: `Peripherals` is not an iterator
      --> src/main.rs:62:50
       |
62     |     let mut peripherals = ch32v30x::Peripherals::take().unwrap();
       |                                                  ^^^^ `Peripherals` is not an iterator
       |
      ::: /home/dama/.cargo/registry/src/github.com-1ecc6299db9ec823/ch32v3-0.1.4/src/ch32v30x/mod.rs:138670:1
       |
138670 | pub struct Peripherals {
       | ---------------------- doesn't satisfy `Peripherals: Iterator`
       |
       = note: the following trait bounds were not satisfied:
               `Peripherals: Iterator`
               which is required by `&mut Peripherals: Iterator`

For more information about this error, try `rustc --explain E0599`.

It looks like the generated Cargo.toml is missing the feature declaration for "critical-section".

how is the svd binary installed?

cargo install svd mentioned in
https://github.com/ch32-rs/ch32-rs/blob/main/scripts/generate.sh#L6 does not install anything.

CH32V003 (RV32EC) support

The README states

Support CH32V003 family (RV32EC is not supported by Rust)

but rustc --target=riscv32i-unknown-none-elf -Ctarget-feature=help shows:

Features supported by rustc for this target:
    a                    - 'A' (Atomic Instructions).
    c                    - 'C' (Compressed Instructions).
    d                    - 'D' (Double-Precision Floating-Point).
    e                    - Implements RV32E (provides 16 rather than 32 GPRs).
    f                    - 'F' (Single-Precision Floating-Point).
    m                    - 'M' (Integer Multiplication and Division).
    v                    - 'V' (Vector Extension for Application Processors).

which seems to suggest that the embedded base ISA is supported by using -Ctarget-feature=e.

Is there something I'm misunderstanding here? Or would that mean we can actually use rust with the Ch32V003?

How can I control GPIO using ch57x crate?

I am new to embedded development.
In ch32v3 crate, I can use ch32v3::ch32v30x::gpioa::outdr::ODR4_W to set the output data of PA4, but I haven't found a similar type in ch57x crate. I only found ch57x::ch57x::sys::pa_out::PA_OUT_0_W and ch57x::ch57x::sys::pa_out::PA_OUT_1_W in it. How can I set the output data of PA4? Does anyone have an idea?

CH58X(CH582M) BLE Support

I've been playing around with BLE in 582m.
Here's an rt using some elements from wch: https://github.com/Slappy2022/ch58x-ble-rt
I also got started on a hal: https://github.com/Slappy2022/ch58x-hal

Some notes...
I've only attempted to use peripherals, there are three examples in the rt with linux-based "centrals" to test.
I've tried pin-based pairing as a one-off and it seems to work.
Hand-crafted assembly is used for some safe mode registers. I'm not sure how/if the pac should handle this.
There are a few things that belong in the pac that were absent or buggy, the hal hits some of these registers directly.
I'm not sure how licenses should work here. The rt steals some things from the wch repo, I don't think this is proper.
Critical section works in the default riscv runtime, but not in my ble runtime.
ble doesn't work in the default riscv runtime, this seems to be related to the handling of "highcode", but I haven't figured it out.

Please let me know how we might align this work with the rest of ch32-rs, assuming there's interest.