CH32V203 programmieren

Muss der Controller zuerst mittels des ISP-Tools entsperrt werden?
https://github.com/COKPOWEHEU/wch-isp

Ich wurstle mich z.Zt. durch die Risc-V von WCH. Z.Zt. spiele ich mit genau Deinem Board herum. Zusammen mit dem MounRiver IDE hatte ich noch mit keinem der Dev-Board oder mit meinen eigenen Boards irgendwelche Probleme. Das einzige was mir einfällt: der E-Link ist default für die ARM MCUs von WCH konfiguriert. Diesen musst Du auf Risc-V umstellen. Entweder mit der Windows-Tool oder falls Du wie ich mit Linux unterwegs bist: Gehäuse öffnen und vor dem Einstecken den Mode-Switch gedrückt halten. Dadurch wechselt die LED von blau auf rot.

Mehmet K. (mkmk) 24.06.2025 16:54

Das einzige was mir einfällt: der E-Link ist default für die ARM MCUs von WCH konfiguriert. Diesen musst Du auf Risc-V umstellen.

Danke. Irgendwo hatte ich gesehen, dass Programmierer die rote LED für RISC-V und die blaue LED für etwas Anderes.
Ich habe aber einen CH32V003 erfolgreich damit programmiert, deshalb müsste die Einstellung eigentlich stimmen.

Auch bei mir funktioniert der WCH-LinkE mit zwei verschiedenen CH32V003- und einem CH32V203-Board (sieht genau so wie deines) problemlos. Ich kann mich nicht erinnern, dass ich dafür mit irgendwelchen Spezialtools oder dem Mode-Switch etwas umkonfigurieren musste.

Da ich ich den WCH-LinkE im Paket mit zwei Dev-Boards und ein paar losen CH32[02]03 erworben hatte, hat vielleicht der Hersteller oder Händler die ggf. erforderlichen Konfigurationen bereits vorgenommen.

Mit welchen Kommandozeilenargumenten rufst du openocd auf?

Mit welchen Kommandozeilenargumenten rufst du openocd auf?

Ich nutze die Arduino IDE.

Dort sieht das ganze so aus:

1

packages/WCH/tools/openocd/1.0.0/bin/openocd -f /home/christoph/.arduino15/packages/WCH/tools/openocd/1.0.0/bin/wch-riscv.cfg -c init -c halt -c program {/tmp/arduino_build_205312/nix2.ino.elf} verify; wlink_reset_resume; exit;

und wch-riscvcfg:

1

2

#interface wlink

3

adapter driver wlinke

4

adapter speed 6000

5

transport select sdi

6

7

wlink_set_address 0x00000000

8

set _CHIPNAME wch_riscv

9

sdi newtap $_CHIPNAME cpu -irlen 5 -expected-id 0x00001

10

11

set _TARGETNAME $_CHIPNAME.cpu

12

13

target create $_TARGETNAME.0 wch_riscv -chain-position $_TARGETNAME

14

$_TARGETNAME.0 configure  -work-area-phys 0x20000000 -work-area-size 10000 -work-area-backup 1

15

set _FLASHNAME $_CHIPNAME.flash

16

17

flash bank $_FLASHNAME wch_riscv 0x00000000 0 0 0 $_TARGETNAME.0

18

19

echo "Ready for Remote Connections"

Gibt es eine Möglichkeit, die Verbindung über openocd schrittweise, manuell zu testen?

Muß es unbedingt openocd sein? Versuch's doch mal hiermit: https://github.com/ch32-rs/wlink

Muß es unbedingt openocd sein? Versuch's doch mal hiermit: https://github.com/ch32-rs/wlink

Danke für den Hinweis. Mittlerweile habe ich den Fehler gefunden: Das gelbe Patchkabel im Bild hatte keinen Durchgang. Unglaublich, wie schlecht die Qualität dieser Steckkabel sein kann. Da kann man dann ewig suchen ..

In meinem Benchmark sind die Risc-V weit abgeschlagen vom ARM-Cortex M33 des Pipico2. Ich hätte erwartet, dass die Kerne des Pipico2-RiscV deutlich schneller als die des CH32V203 sind, aber sie scheinen ähnlich schnell.

1

Geschwindigkeitsfaktor reltaiv zum Arduino Nano:

2

CH32V203:    : ~5.3

3

PiPico RiscV : ~6

4

PiPico ARM   : ~51

1

/*

2

Program: Float Benchmark Arduino Framework

3

4

2025-06-26 mchris

5

*/

6

7

void setup() {

8

  Serial.begin(115200);

9

}

10

11

void loop() {

12

  float sum = 0;

13

  float x, y;

14

  Serial.println("start");

15

  uint32_t start = micros();

16

  for (uint32_t n = 0; n < 10000; n++) {

17

    float r = random(0, 1000) * 1e-6; // random float between 0 and 0.001

18

    x = sin(2 * PI * n / 1000 + r);

19

    y = cos(2 * PI * n / 1000 + r);

20

    sum += sqrt(x * x + y * y);

21

  }

22

  uint32_t dt = micros() - start;

23

  Serial.print("sum: ");

24

  Serial.println(sum, 6); // more decimals for float

25

  Serial.print("calculation time [us]: ");

26

  Serial.println(dt);

27

  Serial.println();

28

  delay(1000); // avoid flooding serial

29

}

Die Frage ist, ob beim CH32V203 und beim Pipico2 wirklich Float-Libraries bentutzt werden. Vielleicht sind sie deshalb so langsam.

Beitrag "Re: CH32V003, float wirklich langsam?"

Christoph M. schrieb:

Das gelbe Patchkabel im Bild hatte keinen Durchgang.

Das hatte ich schon zweimal. Die haben in dem Fall einfach auf die Isolation gecrimpt.

Nemopuk schrieb:

Christoph M. schrieb:

Das gelbe Patchkabel im Bild hatte keinen Durchgang.

Das hatte ich schon zweimal. Die haben in dem Fall einfach auf die Isolation gecrimpt.

Nemopuk schrieb:

Das hatte ich schon zweimal. Die haben in dem Fall einfach auf die Isolation gecrimpt.

Ich hatte dieses Problem auch schon mehrfach vorliegen und es hat lange gedauert bis es entdeckt wurde!

Apollo M. schrieb:

Ich hatte dieses Problem auch schon mehrfach vorliegen und es hat lange gedauert bis es entdeckt wurde!

Wahrscheinlich ist es besser, sich diese Steckkabelchen selbst zu machen. Es gibt ja diese Dupont-Stecker (bzw. -Buchsen) und -Zangen zu kaufen. Dann kann man auch gleich vernünftige Litze mit 0,25mm² oder so nehmen, statt der AWG200 aus Eisen...

Johannes F. schrieb:

AWG200

Das sind homöopathische Litzen.

Harald K. schrieb:

Johannes F. schrieb:

AWG200

Das sind homöopathische Litzen.

Yô, darauf wollte ich mit meiner überspitzten Aussage hinaus.

Muss ich jetzt noch explizit auf den Gebrauch des stilistischen Mittels der Hyperbel hinweisen? ;-)

Christoph M. schrieb:

Die Frage ist, ob beim CH32V203 und beim Pipico2 wirklich Float-Libraries bentutzt werden. Vielleicht sind sie deshalb so langsam.

Die Frage lässt sich leicht beantworten: Weder der Hazard3-RISC-V-Kern des RP2350 noch der QingKe V4B vom CH32V203 haben eine FPU. Der Cortex-M33 hat aber eine. Damit ist das Ergebnis so zu erwarten :)

Christoph M. schrieb:

CH32V203: : ~5.3

Schade. Wollte mit dem CH32V203 eine quadcopter basteln, aber mit langsam float wird die sensor fusion acc & gyro schwierig, da sind massig floats. https://ieeexplore.ieee.org/abstract/document/6213549 Die 4-kanal servo-ausgabe hatte schon funktioniert :(

Oder den uralt multiwii code mit int ausgraben ?

Chris schrieb:

Der Cortex-M33 hat aber eine.

Schon, das Problem wird aber sein, dass damit die interrupt-latency wesentlich größer wird... immerhin musst du, sobald ein interrupt eine FPU instruktion verwendet alle FPU register sichern und beim verlassen wieder zurückschreiben.

Das sollte man auf keinem Fall vernachlässigen!

Hadmut F. schrieb:

aber mit langsam float wird die sensor fusion acc & gyro schwierig, da sind massig floats.

Kommst du mit fixed-point nicht zurecht? Ein paar wenigen Nachkommastellen sollten doch reichen, oder?

Bei den Winkelfunktionen brauchst du eigentlich nur 0-90° in einer Lookup-Table. Also bei 0.1° Genauigkeit 910 Stützpunkte also <4k im Flash bei 4-byte-"floats".

Ansonsten hätte der CH32V307 eine FPU... (+ ein paar nette interfaces)

73

Chris schrieb:

Der Cortex-M33 hat aber eine. Hans Schon, das Problem wird aber sein, dass damit die interrupt-latency wesentlich größer wird... immerhin musst du, sobald ein interrupt eine FPU instruktion verwendet alle FPU register sichern und beim verlassen wieder zurückschreiben.

Der PiPico2 ist aber ein Dual-Core. Da kann man einen Kern als Numbercruncher ohne Interrupts betreiben.

Hans W. schrieb:

Kommst du mit fixed-point nicht zurecht? Ein paar wenigen Nachkommastellen sollten doch reichen,

Die alte multiwii auf atmel 328 hat das so gemacht.

Da der fehler aber kumuliert, das addiert sich mit der zeit, weiss der integer copter nie so genau welche schräglage er hat.