RISCV (CH32V003): GNU Assembler übersetzt "CALL" nicht korrekt (oder bin ich nur zu doof?)

[Thomas T. (knibbel)]

Hallo zusammen,

ich versuche mir seit ein paar Tagen ein kleines 
HelloWorld-Blink-Programm direkt in RISCV-Assembler für den CH32V003 zu 
bauen und bekam es erst zum Laufen, als ich Verzögerungsschleifen, die 
mit dem Pseudo-Befehl "CALL" aufgerufen wurden, direkt ins Hauptprogramm 
eingebaut hatte und somit Unterprogramme vermieden hatte.

Ich habe inzwischen das Problem auf den folgenden "Zwei 
Zeilen-Quelltext" reduzieren können, welcher bei mir falsch übersetzt 
wird:

Start:        CALL Subroutine
Subroutine:   RET

Vorweg: Zum Übersetzen benutze ich das Paket 
"xpack-riscv-none-elf-gcc-14.2.0-3", die Version des im Paket 
enthaltenen Assemblers ist "GNU assembler (xPack GNU RISC-V Embedded GCC 
x86_64) 2.43.1".

Wenn man die beiden Zeilen mittels "riscv-none-elf-as.exe myfile.s" 
übersetzt und sich danach das Ergebnis mittels 
"riscv-none-elf-objdump.exe -d a.out" anschaut, dann sieht man 
folgendes:

a.out:     file format elf32-littleriscv

Disassembly of section .text:

00000000 <Start>:
   0:   00000097                auipc   ra,0x0
   4:   000080e7                jalr    ra # 0 <Start>

00000008 <Subroutine>:
   8:   00008067                ret

Der CALL-Befehl wird hier in zwei Befehle aufgeteilt (das ist auch noch 
in Ordnung), es fehlt jedoch im zweiten Befehl (jalr) der notwendige 
Offset, damit auch zum Unterprogramm gesprungen wird.

Richtigerweise sollte meiner Ansicht nach diese Zeile so aussehen:

   4:   008080e7                jalr    8(ra) # 8 <Subroutine>

Wenn ich in meinem HelloWorld-Blink-Programm die übersetzten 
CALL-Befehle derart patche (also die jalr-Befehle mit dem notwendigen 
Offset versehe), dass sie auf das Unterprogramm mit der 
Verzögerungsschleife zeigen, dann funktioniert auch alles, so wie es 
soll...

Es ist also offensichtlich der CALL-Befehl, der nicht korrekt übersetzt 
wird. Aber kann das sein? Ich habe auch ältere Versionen des Assemblers 
getestet, es ist überall dasselbe Verhalten.

Fehlt vielleicht hier nur eine Option, die ich dem Assembler mitgeben 
muss? Oder habe ich hier wirklich einen Fehler entdeckt? Das kann ich 
mir aber bei so einem grundlegenden Befehl nicht vorstellen...

Habt ihr irgendwelche Ideen?

Gruß
Thomas

[Manuel H. (Firma: Universität Tartu) (xenos1984)]

Probier mal den Befehl:

riscv-none-elf-objdump.exe -d -r a.out

Dann siehst du, dass die erzeugte Objektdatei noch eine Relokation 
enthält, die auf das Unterprogramm verweist. Die richtige Adresse setzt 
dann der Linker ein.

[Cartman E. (cartmaneric)]

Ausserdem immer an die Effekte der Pipeline denken!
Wer schon mit MIPS zu tun hatte, ist klar im Vorteil.

[Thomas T. (knibbel)]

Manuel H. schrieb:
> Probier mal den Befehl:
>
>

riscv-none-elf-objdump.exe -d -r a.out

>
> Dann siehst du, dass die erzeugte Objektdatei noch eine Relokation
> enthält, die auf das Unterprogramm verweist. Die richtige Adresse setzt
> dann der Linker ein.

DANKE! Das ist ein wertvoller Hinweis! Ich hatte gedacht, ich komme ohne 
einen Linker klar und der Assembler macht schon alles für mich. Da lag 
also mein Denkfehler.

Vielleicht sind folgende Befehle ja eine Hilfe für Gleichgesinnte, die 
ohne eine große IDE auf der Kommandozeile RISCV-Programme für den 
CH32V003 assemblieren wollen:

Assemblieren mittels:

riscv-none-elf-as.exe -agl blinken.s

Dann Linken mittels:

riscv-none-elf-ld.exe -o a.o -Ttext 0 -e Coldstart a.out

Danach die Binärdatei bauen mittels:

riscv-none-elf-objcopy.exe -O binary a.o a.bin

Und Anschauen, was der Assembler gebaut hat, geht mittels:

riscv-none-elf-objdump.exe -d -r a.o

Gegebenenfalls müssen natürlich die Dateinamen angepasst werden.

Gruß
Thomas

[Johann L. (gjlayde)]

as erzeugt aus der Assembly-Quelle eine Object Datei, was aber kein 
ausführbarer Code ist. Dazu muss mindestens Gelinkt werden, und evtl. 
braucht's noch zusätzlichen Code (Startup Code, CRT, Device 
Initialisierung, Vektor Tabellen, Linker Script, etc).

Am einfachsten bekommt man das, wenn man gcc als Treiber verwendet 
(für.S oder.sx oder mit -x assembler-with-cpp).

Weiterer Vorteil ist, dass man dann auch den C-Präprozessor im asm 
verwenden kann.

[Manuel H. (Firma: Universität Tartu) (xenos1984)]

Wenn man ohne IDE arbeiten und den Kompiliervorgang etwas vereinfachen 
möchte, kann man auch PlatformIO Core benutzen. Da kann man über die 
Kommandozeile das Projekt erstellen, und statt einzeln die einzelnen 
Programme aufzurufen, tut es ein "pio run".

https://github.com/Community-PIO-CH32V/platform-ch32v

[Harald K. (kirnbichler)]

Manuel H. schrieb:
> Da kann man über die
> Kommandozeile das Projekt erstellen, und statt einzeln die einzelnen
> Programme aufzurufen, tut es ein "pio run".

Naja, ein simples Makefile würde genügen, da muss man nicht mit so einer 
fetten Keule herumwedeln.

[Christoph M. (mchris)]

Thomas T. (knibbel)
08.06.2025 13:01

>ich versuche mir seit ein paar Tagen ein kleines
>HelloWorld-Blink-Programm direkt in RISCV-Assembler für den CH32V003 zu
>bauen und bekam es erst zum Laufen, als ich Verzögerungsschleifen, die
>mit dem Pseudo-Befehl "CALL" aufgerufen wurden, direkt ins Hauptprogramm
>eingebaut hatte und somit Unterprogramme vermieden hatte.

Eine sehr interessante Idee, sich bei diesem Prozessor auf die 
Assemblerebene zu begeben.
Kannst du ein einfaches Blink-Programm für den Einstieg posten?

[Thomas T. (knibbel)]

Christoph M. schrieb:
>
> Eine sehr interessante Idee, sich bei diesem Prozessor auf die
> Assemblerebene zu begeben.
> Kannst du ein einfaches Blink-Programm für den Einstieg posten?

Da der Thread noch nicht zerredet wurde, kann ich das gerne machen. Hier 
kommt also ein sehr einfaches Programm, was bei der Adresse 0 startet 
und auch keinerlei Rücksicht auf irgendwelche Vektortabellen für 
Interrupts nimmt. Normalerweise erfolgt wohl zuallererst bei Adresse 0 
ein Jump-Befehl zum Einsprungspunkt und dann folgen erst mal eine Reihe 
von Vektoren, falls man mit Interrupts arbeitet. Und den Stack-Pointer 
habe ich auch nicht gesetzt, das Speichern der Rücksprungadressen beim 
CALL-Befehl funktioniert hier etwas anders und auch nur für eine Ebene. 
Bei mehreren Unterprogramm-Ebenen muss man sich dann was eigenes 
basteln...

# Assemblieren:     riscv-none-elf-as -agl blink.s
# Linken:           riscv-none-elf-ld -o blink.o -Ttext 0 -e Coldstart a.out
# Anschauen:        riscv-none-elf-objdump -d -r blink.o
# Binary bauen:     riscv-none-elf-objcopy -O binary blink.o blink.bin

                        .file    "blinken.s"
                        .section .text
                        .balign  4

                        .global  Coldstart

R32_RCC_APB2PCENR       =       0x40021018
R32_GPIOD_CFGLR         =       0x40011400
R32_GPIOD_BSHR          =       0x40011410

                        .org    0x00000000

Coldstart:              nop

Port_Setup_Clock:       li      x10,R32_RCC_APB2PCENR
                        lw      x11,0(x10)
                        li      x7,(1<<5)
                        or      x11,x11,x7
                        sw      x11,0(x10)

Port_Setup_Direction:   li      x10,R32_GPIOD_CFGLR
                        lw      x11,0(x10)
                        li      x7,0xfff0ffff
                        and     x11,x11,x7
                        li      x7,0x00030000
                        or      x11,x11,x7
                        sw      x11,0(x10)

                        li      x10,R32_GPIOD_BSHR

Led_PD4_ON:             li      x11,0b00000000000000000000000000010000
                        sw      x11,0(x10)

                        call    Delay

Led_PD4_OFF:            li      x11,0b00000000000100000000000000000000
                        sw      x11,0(x10)

                        call    Delay

                        j       Led_PD4_ON


Delay:                  li      x6,200000
DelayLoop:              addi    x6,x6,-1
                        bne     x6,zero,DelayLoop
                        ret

Viel Spaß damit.

Gruß
Thomas

[Johann L. (gjlayde)]

Auf .org würde ich komplett verzichten, weil es eben nicht die 
absolute Adresse des nächsten Kommandos setzt.

[Christoph M. (mchris)]

Thomas T. (knibbel)
09.06.2025 14:51
>Da der Thread noch nicht zerredet wurde, kann ich das gerne machen.
Wieso ist doch super. Auf die Art lernt man einen Prozessor in der Tiefe 
kennen (inclusive der Toolchains).

Johann L. (gjlayde)
> weil es eben nicht die
> absolute Adresse des nächsten Kommandos setzt.
Kannst du das mal genauer ausführen?

[Johann L. (gjlayde)]

Siehe https://sourceware.org/binutils/docs/as/Org.html

[Thomas T. (knibbel)]

Johann L. schrieb:
> Auf .org würde ich komplett verzichten, weil es eben nicht die
> absolute Adresse des nächsten Kommandos setzt.

Ich denke, man sollte hier einen Mittelweg finden...

.org setzt nicht immer die absolute Adresse des nächsten Befehls. Wenn 
man allerdings die Einschränkungen berücksichtigt, dann sollte man .org 
nicht komplett ablehnen.

Ein Grund wäre beispielsweise folgender:

Sobald ich für Interrupts eine Vektortabelle am Anfang des Flash 
hinterlege, bin ich gezwungen diese zu umgehen, da der Programmstart 
immer bei 0 beginnt und dort dann ein Jump-Befehl stehen muss. Auch wenn 
man gewöhnlich dem Linker den Programmstart vorgeben kann (oder er 
selbst _start nimmt), funktioniert dies beim Mikrocontroller nicht mehr.

Ich will die Led an PD4 als nächsten Schritt mittels eines 
Timer-Interrupts blinken lassen und bereite den Quelltext so vor, damit 
die Adresse der Interrupt-Routine auch korrekt hinterlegt ist:

                        .org 0x00000000
Coldstart:              j       Warmstart

                        .org 0x00000090
TIM1TRG_Vector:         .dc.l   Irq_Routine

                        .org 0x00000100
Warmstart:              nop

Ich werde am nächsten Wochenende mal versuchen, die Interrupt-Routine 
auszuformulieren und die Werte für den Timer zu setzen.

Was alternativ allerdings funktionieren könnte, wäre folgendes: Ich baue 
mir eine separate Vektortabelle, in der ich zu Anfang einen Jump-Befehl 
auf das Ende der Vektortabelle setze. Genauer gesagt, direkt hinter dem 
letzten Eintrag der Vektortabelle. Wenn ich diese Datei dann assembliere 
und vor meine eigentliche Objektdatei linke, dann könnte es auch ohne 
.org funktionieren...

Gruß
Thomas

[Cartman E. (cartmaneric)]

Warum lässt du den Linker nicht einfach seine Arbeit machen?

Die Grösse der Vektortabelle ist bekannt, und gehört neben ihrer
Adresse einfach in eine Section der Linkdefinitionen.
Dazu dann eine Assemblerquelle, die den Inhalt aufdröselt und
genau dieser Section zugeordnet wird.
Die braucht dann eventuell auch eher Aligns statt Org.

Genauso wie der Main- und der Interruptcode in eine Section
gehören. Die richtigen Adressen setzt dann schon der Linker ein.

Die Sections wiederum liegen in Regions der Linkertabelle.

Deine Beispiele werden nicht immer so einfach bleuben, und
willst du ernsthaft in grösseren Projekten immer mit Absolutadressen
hantieren?

Also mach es gleich richtig.

[Christoph M. (mchris)]

Cartman E. (cartmaneric)
11.06.2025 01:10

>Deine Beispiele werden nicht immer so einfach bleuben,
Ich finde es besser, erst einfach anzufangen und sich nicht auf die 
Komplexität des Link-Prozesses zu verlassen.

[Christoph M. (mchris)]

Gibt es irgendwo eine Befehlsübersicht? Am besten wäre, wenn man auch 
die Kodierung sehen könnte.

[Thomas T. (knibbel)]

Christoph M. schrieb:
> Gibt es irgendwo eine Befehlsübersicht? Am besten wäre, wenn man auch
> die Kodierung sehen könnte.

Keine vollständige Befehlsübersicht, aber in dem rvalp.pdf, auf den 
nachfolgender Link zeigt, hat man auf den letzten Seiten auch ein paar 
Tabellen zur Kodierung der Befehle:

https://github.com/johnwinans/rvalp

[Christoph M. (mchris)]

> https://github.com/johnwinans/rvalp

Danke für den Link. Ich hatte mir schon ein paar Videos von John's 
Basement dazu angeschaut:

Introduction to RISC-V and the RV32I Instructions
https://www.youtube.com/watch?v=LKB5I12LctU

Die sind zwar etwas langwierig,aber sehr informativ.

[Christoph M. (mchris)]

Vielleicht könnte der Assemblercode auf einem PiPico2 laufen. Der hat 
zwei
RV32IMACZ eingebaut, die sollten ja abwärtskompatibel sein.

[Bernhard K. (bkom)]

Christoph M. schrieb:
> Gibt es irgendwo eine Befehlsübersicht? Am besten wäre, wenn man auch
> die Kodierung sehen könnte.

Eine Übersicht über das RiscV Befehlsformat mit Kodierung:
https://www.cs.sfu.ca/~ashriram/Courses/CS295/assets/notebooks/RISCV/RISCV_CARD.pdf

[Christoph M. (mchris)]

Die Compiler Toolchain zu installieren war für mich relativ umständlich.
Einfacher ist es, die Arduino IDE mit der passenden Toolchain zu 
installieren und dann einfach den vorhandenen Assembler mit einem Script 
zu nutzen.
Den Pfad zur Toolchain kann man einfach aus der Arduino-IDE heraus 
kopieren, wenn man einmal ein leeres Programm compiliert hat.

Das folgende Script assembliert und flashed den Mikrocontroller in einem 
Rutsch:

#!/bin/bash

# CH32V003 on Ubuntu
# To assemble programms for the CH32V003 microcontroller, you can use
# the assembler toolchain provide by this Arduino Framework:
# https://github.com/AlexanderMandera/arduino-wch32v003/tree/master
# Just follow the installation instructions and then run the script.

# This script compiles bink.s and flashes the microcontroller

#2025-06-28 mchris

# Define toolchain directory
DIR="/home/christoph/.arduino15/packages/WCH/tools/riscv-none-embed-gcc/8.2.0/bin"

# Add toolchain to PATH only if not already present
case ":$PATH:" in
    *":$DIR:"*) :;; # already in PATH, do nothing
    *) export PATH="$DIR:$PATH";;
esac

# Assemble, link, and create binary
echo "Assembling blink.s..."
riscv-none-embed-as -o blink.o blink.s

echo "Linking to create blink.elf..."
riscv-none-embed-ld -o blink.elf -Ttext=0 -e Coldstart blink.o

echo "Creating blink.bin..."
riscv-none-embed-objcopy -O binary blink.elf blink.bin

# OpenOCD variables
OPENOCD_BIN="$HOME/.arduino15/packages/WCH/tools/openocd/1.0.0/bin/openocd"
CFG_FILE="$HOME/.arduino15/packages/WCH/tools/openocd/1.0.0/bin/wch-riscv.cfg"

# Erase chip (optional, but recommended)
echo "Attempting to erase chip (this will fail if write protected)..."
"$OPENOCD_BIN" -f "$CFG_FILE" -c init -c halt -c "flash erase_address 0x0 0x400" -c exit 2>&1 | tee erase_output.log

if grep -q "write protected" erase_output.log; then
    echo "Chip is write protected. Aborting flash."
    exit 1
else
    echo "No write protection detected, or unable to determine."
fi

# Flash blink.bin to the microcontroller
echo "Flashing blink.bin to the microcontroller..."
"$OPENOCD_BIN" -f "$CFG_FILE" -c init -c halt -c "program blink.bin 0x0 verify reset exit"

echo "Done."

[Johann L. (gjlayde)]

Paar Anmerkungen:

OpenOCD versteht ELF.  Der Zwischenschritt über iHex / Binary ist also 
überflüssig: https://openocd.org/doc/html/Flash-Commands.html
Teilweise ist Binary auch kontraproduktiv, etwa wenn etwas Code ab 0x0 
liegt und etwas Daten ab 0x1000000.  Das ELF file ist dann klein um 
überschaubar, aber das Binary ist riesig weil es keine Section o.ä. 
darstellen kann.

Assemble und Link lassen sich mit einem Kommando ausführen, indem man 
riscv-none-embed-gcc als Treiber verwendet:

$ riscv-none-embed-gcc blink.s -o blink.elf -Ttext=0 -e Coldstart -nostartfiles

In reinen Asm Programmen will man i.d.R keinen C Startup Code, daher das 
-nostartfiles (Mit den RISCV Tools kenne ich mich nicht aus, und ich 
weiß nicht ob da überhaupt Startup Code anbei ist).

Um Argumente an den Linker zu übergeben wird normalerweise -Wl 
verwendet, also zum Beispiel -Wl,-e,Coldstart.  Hier ist das nicht nötig 
weil gcc weiß, dass -e für den Linker ist.  Dito für -Ttext.  Ein 
Map-File wird man etwa mit -Wl,-Map,blink.map vom Linker erstellen 
lassen.

Ein Vorteil bei der Verwendung von gcc ist, dass man neben .macro von 
GAS noch einen zweiten Makro-Prozessor nutzen kann, nämlich den C 
Präprozessor (#include, #define, #if, #ifdef, ...).  Dazu muss man 
allerdings .S oder .sx als Suffix verwenden, oder man kann auch mit -x 
die "Sprache" explizit angeben:

$ riscv-none-embed-gcc -x assembler-with-cpp blink.asm -o blink.elf -Ttext=0 -e Coldstart -nostartfiles

Liegt die Applikation in mehreren Modulen vor, dann kann man einfach 
alle Module in einem Rutsch übersetzen, anstatt für jedes Modul händisch 
einen GAS-Aufruf zu bemühen:

$ riscv-none-embed-gcc -x assembler-with-cpp blink.asm sound.asm grafik.asm -o blink.elf <options>

Um die Ausgaben / Ergebnisse des C Präprozessors zu behalten dient 
-save-temps.  Die Zwischenergebnisse werden dann als blink.s, sound.s 
und grafik.s gespeichert.

Wenn man Assembler mit C kombinieren will, dann gibt man einfach die 
C-Quellen beim Aufruf mit an.  Zu beachten ist, dass -x die Sprache für 
alle folgenden Inputs setzt.  Mit -x none erreicht man, dass die 
Sprache wieder vom Suffix abgeleitet wird:

$ riscv-none-embed-gcc modul1.c -x assembler-with-cpp blink.asm sound.asm grafik.asm -x none modul2.c -o blink.elf <options>

Bei vielen[tm] Modulen nimmt man üblicherweise ein Makefile anstatt 
eines Shell Skripts.

[Christoph M. (mchris)]

Johann L. (gjlayde) Benutzerseite

> Paar Anmerkungen

Danke für die vielen wertvollen Hinweise.
Für mich ist die Erstellung der Makefiles immer etwas mühsam, deshalb 
mach ich der Einfachheit halber Bash-Scripts.

Aber: Dank Perplexity sind Makefiles nun auch kein unlösbares Problem 
mehr.

Im Anhang das Makefile. Ich musste es ein wenig "tweaken" weil unter 
anderem "make clean" frecherweise gleich mein Sourcefile gelöscht hat.

Jetzt gehen die Kommandos ziemlich gut und der Pfad zur Toolchain im 
Arduino-Ordner ist schön separiert, sodass es jeder selbst leicht an 
seinen Pfad anpassen könnte.

Kommandos u.a. sind:
make
make clean
make flash

[Christoph M. (mchris)]

Weiß eigentlich jemand, mit welcher Taktfrequenz die MCU im obigen 
Blinkbeispiel läuft? Ich habe das Assemblerfile auf einen Quarz-Losen 
CH32V003 geflasht und es blinkt recht schnell.
Eigentlich wäre es besser, als Referenz den Systemtimer statt der 
Delay-Loop zu verwenden.

Ich habe mal versucht, ein 1Hz Blinken mit dem obigen Assemblerprogramm 
zu erzeugen
Beitrag "Re: RISCV (CH32V003): GNU Assembler übersetzt "CALL" nicht korrekt (oder bin ich nur zu doof?)"

Dazu muss man x6 mit 1e6 laden:

 
Delay:                  li      x6,1000000

Tja, wie hoch ist jetzt FCPU?

[Thomas T. (knibbel)]

Christoph M. schrieb:
> Weiß eigentlich jemand, mit welcher Taktfrequenz die MCU im obigen
> Blinkbeispiel läuft? Ich habe das Assemblerfile auf einen Quarz-Losen
> CH32V003 geflasht und es blinkt recht schnell.
> Eigentlich wäre es besser, als Referenz den Systemtimer statt der
> Delay-Loop zu verwenden.

Die Taktfrequenz sollte gemäß Datenblatt bei ca. 24 MHz liegen. Sie 
kommt vom "24 MHz HSI RC" und wird - ohne weiter geteilt zu werden - zu 
FCLK geleitet.

Ja, es wäre wesentlich besser einen Timer für die Erzeugung der 
Blink-Impulse zu verwenden. Ich habe dazu mal ein wenig mit Interrupts 
gespielt und das Umschalten des LED-Ausgangs in eine Interrupt-Routine 
verlegt. Das Hauptprogramm macht jetzt nur noch ein paar 
Initialisierungen und verweilt dann in einer Endlosschleife.

# Assemblieren:     riscv-none-elf-as -agl blink.s
# Linken:           riscv-none-elf-ld -o blink.o -Ttext 0 -e Reset_Entry a.out
# Anschauen:        riscv-none-elf-objdump -d -r blink.o
# Binary bauen:     riscv-none-elf-objcopy -O binary blink.o blink.bin


                        .file           "blinken.s"
                        .section        .text
                        .balign         4

                        .global         Reset_Entry

                        .list

                        .include        "CH32V003_reg1.asm"


                        .org 0x00000000
Reset_Entry:            j       Coldstart

                        .org 0x00000098
TIM2_Vector:            .dc.l   Interrupt_Routine

                        .org 0x00000100
Coldstart:              nop
                        li      t0,0x00000003                   # "Interrupt Vectortable Recognition Mode" und "Entry Address Mode" aktivieren
                        csrw    mtvec,t0
                        li      t0,0x00000008                   # Global Interrupts freigeben
                        csrw    mstatus,t0

Port_Setup_Clock:       li      x10,R32_RCC_APB2PCENR           # Takt für Port D einschalten
                        lw      x11,0(x10)
                        li      x7,(1<<5)
                        or      x11,x11,x7
                        sw      x11,0(x10)

Port_Setup_Direction:   li      x10,R32_GPIOD_CFGLR
                        lw      x11,0(x10)
                        li      x7,0xfff0ffff
                        and     x11,x11,x7
                        li      x7,0x00030000
                        or      x11,x11,x7
                        sw      x11,0(x10)

Port_Setup_LED_off:     li      x10,R32_GPIOD_OUTDR
                        lw      x11,0(x10)
                        ori     x11,x11,0x0010
                        sw      x11,0(x10)


Timer_Setup:            li      x10,R32_RCC_APB1PCENR           # Takt für Timer 2 einschalten
                        lw      x11,0(x10)
                        ori     x11,x11,0x00000001
                        sw      x11,0(x10)

                        li      x10,R16_TIM2_PSC                # Prescaler auf 7999 (0x1F3F) setzen: 24MHz/(3*8000) => Taktfrequenz=1000Hz
                        li      x11,7999
                        sw      x11,0(x10)

                        li      x10,R16_TIM2_BASE               # Reload-Value und Counter-Value setzen (bestimmt die Interrupt-Frequenz)
                        li      x11,250
                        sw      x11,44(x10)                     # speichern in R16_TIM2_ATRLR
                        sw      x11,36(x10)                     # speichern in R16_TIM2_CNT

                        li      x10,R16_TIM2_CTLR1              # Reload-Funktion einschalten und rückwärts zählen
                        lw      x11,0(x10)
                        ori     x11,x11,0x0090
                        sw      x11,0(x10)

                        li      x10,R16_TIM2_DMAINTENR          # Interrupts einrichten (1)
                        li      x11,0x0001
                        sw      x11,0(x10)
                        li      x10,R32_PFIC_IENR2              # Interrupts einrichten (2)
                        li      x11,0x00000040
                        sw      x11,0(x10)


                        li      x10,R16_TIM2_CTLR1              # Timer 2 aktivieren
                        lw      x11,0(x10)
                        ori     x11,x11,0x0001
                        sw      x11,0(x10)


Endless_Loop:           j       Endless_Loop



Interrupt_Routine:      li      x10,R32_GPIOD_OUTDR
                        lw      x11,0(x10)
                        xori    x11,x11,0x00000010
                        sw      x11,0(x10)

                        li      x10,R16_TIM2_INTFR
                        li      x11,0x00000000
                        sw      x11,0(x10)
                        mret

Die Adressen der einzelnen Register sind ausgelagert und finden sich in 
der beigefügten Include-Datei wieder.

[Christoph M. (mchris)]

Danke für das Code-Beispiel :-)

Thomas T. (knibbel)
29.06.2025 15:09
>Die Taktfrequenz sollte gemäß Datenblatt bei ca. 24 MHz liegen. Sie
>kommt vom "24 MHz HSI RC" und wird - ohne weiter geteilt zu werden - zu
>FCLK geleitet.

Die Delay-Loop mit dem Zählerwert 1 Million ergibt die Verzögerung von 
500ms, die für das 1Hz Blinken gebraucht werden. Bei 24MHz ( 24 
Millionen Zyklen/Sekunde) wären das 12 Taktzyklen für die beiden Befehle 
addi und bne.
Dann wäre diese RISC-V Implementierung definitv schnarchlangsam.

Delay:                  li      x6,1000000

DelayLoop:              addi    x6,x6,-1
                        bne     x6,zero,DelayLoop

                        ret

[Christoph M. (mchris)]

Ich versuche mehr über den Prozessor herauszufinden.
Die Firma QingKeV scheint ein wenig von den normalen RISC-V Konventionen 
abzuweichen.
Laut Prozessor-Manal sollte das Ding einen Hardwaremultiplizierer haben:

QingKeV2_Processor_Manual

RISC-V Kern:
RV32ECZmmul 

RV32:   32-bit architecture
E:         16 registers
C:         16-bit compressed instructions
XW:      16-bit compression instruction for self-extending byte and half-word operations
m:         hardware multiplication, i.e., Zmmul extension.

Zmmul extension
https://five-embeddev.com/riscv-user-isa-manual/Priv-v1.12/m.html  
XW: QingKeV vendor specific extension

Was mich vor allem interessiert, ist der Systick-Timer. Den verwendet 
man normalerweise in Echtzeitsystemen für alles Mögliche als Zeitbasis. 
Man kann ihn z.B. auch sehr gut für die 'delay' Funktion verwenden.

Hier ist die Initialisierung im Arduino-Core, was für die 
Assemblerimplementierung hilfreich sein könnte:
https://github.com/openwch/arduino_core_ch32/blob/main/cores/arduino/ch32/hw_config.c

Um im Reference-Manual fündig zu werden, muss man nach R32_STK suchen.

[Johannes F. (jofe)]

Christoph M. schrieb:
> Die Firma QingKeV scheint ein wenig von den normalen RISC-V Konventionen
> abzuweichen.

'QingKeV' ist keine Firma, sondern eine Reihe von Mikrocontroller-Serien 
bzw. -Kernen. Das Unternehmen nennt sich 'Nanjing Qinheng 
Microelectronics'.

[Joachim B. (jar)]

Thomas T. schrieb:
> sollte

Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

nicht auch bei seitenlangen Listing gelten?

[Christoph M. (mchris)]

Manuel H. (Firma: Universität Tartu) (xenos1984)
08.06.2025 18:06
>Wenn man ohne IDE arbeiten und den Kompiliervorgang etwas vereinfachen
>möchte, kann man auch PlatformIO Core benutzen. Da kann man über die
>Kommandozeile das Projekt erstellen, und statt einzeln die einzelnen
>Programme aufzurufen, tut es ein "pio run".
>https://github.com/Community-PIO-CH32V/platform-ch32v

Wie kriege ich Platform-IO dazu, nur mein Assembler-File zu verwenden?
Das Arduino-Framework kann ich selektieren und mit dem ini-File

[env:ch32v003f4p6_evt_r0]
platform = ch32v
board = ch32v003f4p6_evt_r0
framework = arduino
upload_protocol = wch-link

und einen rohen, auf einen TSSOP-Adapter aufgelöteten CH32V003F4P6 und 
sonst keine Bauteile außer der LED mit Vorwiderstand blinkt es auch 
schön:

#include <Arduino.h>

#define LED PD4 // TSSOP 20 Board

void setup() {
  pinMode(LED, OUTPUT);
}

void loop() {
  digitalWrite(LED, HIGH);   
  delay(1000);                    
  digitalWrite(LED, LOW);    
  delay(1000);                    
}

Ich will aber nicht das dicke Framework, sonder das rohe blink.s

[Christoph M. (mchris)]

Bei diesem Blink-Beispiel nutze ich den systick-Timer als Zeitbasis. Die 
LED blinkt zu langsam, woraus ich schließe, dass der CH32V003 nicht mit 
24Mhz, sondern mit 8Mhz startet und läuft.

Thomas T. (knibbel)
29.06.2025 15:09
>Die Taktfrequenz sollte gemäß Datenblatt bei ca. 24 MHz liegen. Sie
>kommt vom "24 MHz HSI RC" und wird - ohne weiter geteilt zu werden - zu
>FCLK geleitet.

Das wird dann wohl nicht stimmen, 8Mhz ist wohl eher richtig.

[Christoph M. (mchris)]

Im Clock-Tree gibt es ein durch 3 geteiltes Signal, welches zum Flash 
geht.
Vielleicht ist das der Grund für die 8MHz.

[Thomas Z. (usbman)]

Christoph M. schrieb:
> Vielleicht ist das der Grund für die 8MHz.

Ich sehe nicht, dass du das RCC_CFGR0 irgendwo anfasst.
Damit ist HPRE[3:0] = 0010b = /3 für den HP Clock. Das würde zu deiner 
Beobachtung passen.