Da ich am evaluieren von CH32V003 bin, habe ich im Zuge dessen jetzt
auch einmal die Ausführungszeiten für ein Apfelmännchen gemessen /
getestet. Hier bin ich jetzt erstaunt / verwundert und denke ich habe
irgendwo einen Denkfehler.
Zuerst einmal die Ausführungszeiten:
1
Ausfuehrzeiten fuer das Programm: Fraktal-Speedtest:
2
3
Display: 160x128 ST7735
4
Interface: Hardware-SPI
5
6
Controller | Zeit [Sekunden]
7
-------------------------------------------------
8
STM32F401 / 84MHz | 2.8
9
STM32F401 / 96MHz (uebertaktet) | 2.6
10
STM32F103 / 72MHz | 11.4
11
STM32F030 / 48MHz | 34.0
12
CH32V003 / 48MHz | 80.5
13
CH32V003 / 24MHz | 123.0
14
ATmega328 / 16Mhz | 63.0
Alle werden mit denselben Grafikroutinen betrieben, alle mit
Hardware-SPI (wobei im Falle von CH32V003 und dem Apfelmännchen relativ
unerheblich ist, ob das mittels Hardware-SPI oder Bitbanging betrieben
wird, Bitbanging braucht ca. 2 Sekunden länger).
Alle laufen mit einem Systemticker, im Falle vom ATmega generiert Timer1
einen 1 Millisekundenintervall in dem ein Zähler hochgezählt wird.
Dann traute ich meinen Systemtickern nicht so recht über den Weg und
habe das handgestoppt, die Zeiten stimmen.
Noch betreibe ich den CH32V003 über das Setup des Frameworks CH32FUN
(und ersetze nach und nach dessen Routinen durch eigene, bis ich das
Framework dann nicht mehr benötige).
Ist im CH32FUN im Clocksetup etwas grundsätzlich nicht richtig (ich bin
hier auf der Suche), oder ist der CH32V003 hier wirklich so lahm, dass
sogar ein ATmega das Apfelmännchen schneller zeichnet?
Compileroptimierungsschalter steht auf -Os (natürlich habe ich auch -O1
und -O2 ausprobiert, aber außer an der Codegröße hat sich nicht viel
geändert).
Compiler für den CH32V003 ist riscv-none-elf-gcc.
Im Anhang hier ist der Programmcode des Apfelmännchens enthalten.
Wie kompilierst du den Quelltext? Benutze mal float Konstanten, also
statt 2.0 2.0f oder benutze -fsingle-precision-constant.
1
ty= 2.0f*wx*wy+jy;
Diese Stelle müsste (ohne das ..f) beim STM32 (evtl. auch beim RISC-V)
in doubles berechnet werden. Die Kovertierung auf float findet erst beim
abspeichern in ty statt.
Ich denke, dass der Compiler bei den STM32 an bestimmten Stellen doubles
einbaut, evtl. auch beim CH32V003. Vermutlich hat dieser RISC-V Kern
(v2a) auch nur eine langsamere (keine Single Cycle) Integer
Multiplikation. Diese wird ja auch benötigt, um die Gleitkommabefehle
auzuführen.
Christoph M. schrieb:> Die STM32F4xx haben eine Fließkommaeinheit.
Das weiß ich!
Klaus R. schrieb:> Wie kompilierst du den Quelltext? Benutze mal float Konstanten, also> statt 2.0 2.0f oder benutze -fsingle-precision-constant.ty=> 2.0f*wx*wy+jy;
Es ging mir vor allen Dingen darum, wie schnell ein CH32V003 den Code im
Vergleich zu STM32F030 und ATmega ausführt.
Den Versuch mit 2.0f werde ich aber machen!
So, die Versuche für einfache Genauigkeit und 2.0f habe ich jetzt mal
gemacht:
STM32F401 / 84 MHz => 0.5 Sekunden
STM32F103 / 72 MHz => 9.2 Sekunden
STM32F030 / 48 MHz => 24.9 Sekunden
CH32V003 / 48 MHz => 62.9 Sekunden
ATmega328 / 16 MHz => 63 Sekunden
Dass ATmega nicht schneller wird war anzunehmen, da meines Wissens der
AVR-GCC Compiler bei Angabe 2.0 keine doubles berechnet.
Dennoch finde ich das Ergebnis für CH32V003 etwas enttäuschend:
Float-Berechnungen nicht schneller als auf einer alten 8-Bit MCU mit nur
16 MHz !!
Wenn ich das richtig nachgeschaut habe, hat der CH32V003 nur das
institution set "RV32EC". Somit hat der noch nichtmal für integer eine
Multiplikation bzw. Division und die dürften hier recht häufig genutzt
werden.
- "RV32E" Base integer instruction set (embedded), 32-bit, 16 registers
- "C" Standard extension for compressed instructions
- "M" = Standard extension for integer multiplication and division
- https://en.wikipedia.org/wiki/RISC-V#Standard_extensions
Irgend W. schrieb:> Somit hat der noch nichtmal für integer eine Multiplikation bzw.> Division und die dürften hier recht häufig genutzt werden.
Naja ein Cortex-M0 ist IMHO nicht so verschieden...
Abseits des Taktes bleibt noch die Frage ist, ob es für den Risc-V eine
optimierte float library gib...
Der F0 und der AVR sind auf den Takt normalisiert in etwa gleich auf.
Den CH32v003 würde ich in etwa in der gleichen Liga sehen...
73
Ralph S. (jjflash)
>Dennoch finde ich das Ergebnis für CH32V003 etwas enttäuschend:>Float-Berechnungen nicht schneller als auf einer alten 8-Bit MCU mit nur>16 MHz !!
Wie ist denn der CH32V003 implementiert? Es könnte ja sein, dass der
Kern aus Kostengründen eine Bit-Slice-Architektur wie ein Z80 früher
ist.
Dann bräuchte er einige Takte mehr pro Befehl.
Gibt es irgendwo Angaben, wie viele Takte er für ein Integer-Add
braucht?
Hans W. schrieb:> Stimmt der SPI clock (nicht, dass du unabsichtlich einen viel> langsameren clock verwendest)?
Der SPI-Clock ist garantiert nicht das "Problem", da die Zeiten nicht
viel schneller sind, wenn es gar keine Ausgabe auf dem Display gibt (und
man nur die Berechnungen durchführt).
Irgend W. schrieb:> Wenn ich das richtig nachgeschaut habe, hat der CH32V003 nur das> institution set "RV32EC". Somit hat der noch nichtmal für integer eine> Multiplikation bzw. Division und die dürften hier recht häufig genutzt> werden.
Das, glaube ich, wird des Pudels Kern sein !
Hans W. schrieb:> Der F0 und der AVR sind auf den Takt normalisiert in etwa gleich auf.> Den CH32v003 würde ich in etwa in der gleichen Liga sehen...
Im Moment sehe ich das eher nicht so!
Harald K. schrieb:> Das ist ein RISC-V, QingKe V2A core, RV32EC, Details finden sich im> Reference Manual:>> https://www.wch-ic.com/downloads/CH32V003RM_PDF.html> https://www.wch-ic.com/downloads/QingKeV2_Processor_Manual_PDF.html
... und das schaue ich mir jetzt einmal an, vielen Dank
Harald K. (kirnbichler)
14.04.2025 09:50
>Das ist ein RISC-V, QingKe V2A core, RV32EC, Details finden sich im>Reference Manual:
Siehst du da irgendwelche Angaben zu den Taktzyklen pro Befehl?
Christoph M. schrieb:> Siehst du da irgendwelche Angaben zu den Taktzyklen pro Befehl?
Nope.
Auf "reddit" gefunden:
CH32V003 fetches 4 bytes of instructions in 1 clock cycle at 24 MHz, or
2 clock cycles at 48 MHz. Then it executes whatever instructions are in
those 4 bytes (plus maybe the last 2 byte of the previous instruction
fetch, if it started a 4 byte instruction) at (usually) 1 clock cycle
per instruction.
So at 48 MHz you can execute one 4-byte instruction in 3 clock cycles,
or two 2-byte instructions in 4 clock cycles.
(in einer der Antworten auf
https://www.reddit.com/r/RISCV/comments/12qocw4/example_assembly_code_for_the_ch32v003/)
>CH32V003 fetches 4 bytes of instructions in 1 clock cycle at 24 MHz, or>2 clock cycles at 48 MHz.
Interessant: Bei doppeltem Clock gleich schnell beim Fetch. Liegt
wahrscheinlich am Flash.
Falls ein AVR-Assembler Experte mitliest: Wieviel Zyklen braucht ein
Atmega für ein 32Bit add ?
Christoph M. schrieb:> Interessant: Bei doppeltem Clock gleich schnell beim Fetch. Liegt> wahrscheinlich am Flash.
Nehm ich auch an. Ob sich das ändert, wenn man den Code aus dem RAM
ausführt? Viel hat er davon ja nicht, aber ...
Ralph S. schrieb:> Hans W. schrieb:>> Stimmt der SPI clock (nicht, dass du unabsichtlich einen viel>> langsameren clock verwendest)?>> Der SPI-Clock ist garantiert nicht das "Problem", da die Zeiten nicht> viel schneller sind, wenn es gar keine Ausgabe auf dem Display gibt (und> man nur die Berechnungen durchführt).
Ich meinte damit eigentlich: "Stimmen die 48MHz überhaupt"?
Also indirekte Messung über den SPI-CLK, da der ja aller
Wahrscheinlichkeit nach vom CPU CLK abgeleitet wird.
73
Ralph S. schrieb:> Dennoch finde ich das Ergebnis für CH32V003 etwas enttäuschend:> Float-Berechnungen nicht schneller als auf einer alten 8-Bit MCU mit nur> 16 MHz !!
Das sollte man aber ein wenig kontextualisieren:
Der ATMega ist eine extrem gut ausgestattete moderne 8-Bit-CPU, die
recht gut optimiert ist. Das lässt sich der Hersteller aber auch
bezahlen. Der CH32V003 ist ein absolutes Lowcost-Produkt. Der ATMega328
kostet so um die 1.50, der CH32V003 sagen wir mal so etwa 30 Cent. Da
kriegst du also für ein Fünftel des Preises halbwegs vergleichbare
Performance. Viele Anwendungen brauchen keine
Hochleistungs-Microcontroller, sondern müssen nur ein paar Sensoren
auswerten und Transistoren schalten, da wird sowas dann natürlich höchst
interessant.
In der Mounriver-Toolchain für die CH32-Controller wird die generische
soft-fp der glibc verwendet. Diese ist in C implementiert und in
keinster Weise an spezifische CPU-Typen angepasst. Die AVR-FP-Routinen
hingegen sind in Assembler speziell für diesen CPU-Typ geschrieben.
Das alleine macht schon einen Riesenunterschied. Dazu kommt dann noch
der fehlende Hardwaremultiplizierer im CH32V003. Immerhin ist ist die
Integermultiplikation beim CH32V003 in Assembler geschrieben.
Vielleicht erinnert sich noch jemand an die Zeiten, wo auch für den AVR
die soft-fp der glibc verwendet wurde. Da hat man um jeden Preis
versucht, auf FP-Arithmetik komplett zu verzichten.
Evtl. gibt es für den CH32V003 irgendwo eine optimierte FP-Bibliothek,
ich kenne aber keine.
PS: Vielleicht möchte sich mal jemand das da anschauen:
https://www.segger.com/news/risc-v-embedded-variant-rv32e-now-fully-supported-by-seggers-floating-point-library/
Hans W. schrieb:> Abseits des Taktes bleibt noch die Frage ist, ob es für den Risc-V eine> optimierte float library gib...Yalu X. schrieb:> CH32-Controller wird die generische> soft-fp der glibc verwendet.
Danke für die Antwort!
Das erklärt den Unterschied voll und ganz!
Gerade hat DHL mein 1. Design mit einem CH32V003 geliefert... hatte
schon Sorgen, dass ich bei der Komponentenauswahl für den Kunden
irgendwas übersehen habe :)
Ohne ASM-soft-fp und ohne Hardware Multiplier ist die Geschwindigkeit
aber eigentlich ok :)
73
Hans W. schrieb:> ch meinte damit eigentlich: "Stimmen die 48MHz überhaupt"?>> Also indirekte Messung über den SPI-CLK, da der ja aller> Wahrscheinlichkeit nach vom CPU CLK abgeleitet wird.
Das war die erste Überlegung, ob die 48MHz überhaupt stimmen. Erst im
Framework gesucht (war alles in Ordnung ... und ich habe wieder etwas
über die Register gelernt) und dann zusätzlich auf der SPI natürlich den
Klassiker 0x55 und 0xAA ausgegeben... kommt mit dem Clock-Prescaler so
hin. Das Teil läuft wirklich mit 48MHz!
F. schrieb:> Der ATMega ist eine extrem gut ausgestattete moderne 8-Bit-CPU, die> recht gut optimiert ist. Das lässt sich der Hersteller aber auch> bezahlen. Der CH32V003 ist ein absolutes Lowcost-Produkt. Der ATMega328> kostet so um die 1.50, der CH32V003 sagen wir mal so etwa 30 Cent. Da> kriegst du also für ein Fünftel des Preises halbwegs vergleichbare> Performance.
Na ja, es ging ja nicht darum (zumindest hier nicht) was das Teil
kostet. Ich beschäftige mich mit dem Dingelchen ja eigentlich nur aus
"sportlichem" Antrieb heraus weil das so billig ist. Allerdings hätte
ich angenommen, dass RISCV den ATmega um längen schlägt. Ob ATmega jetzt
als "extrem gut ausgestattet" und "modern" bezeichnet werden kann, lass
ich jetzt mal unkomentiert. Optimiert ist sie sicherlich. AVR sind
momentan - verglichen mit ihrer Leistung - sowieso relativ teuer:
günstigste Teile ATmega328 eher schon 2€, CH32V003 0,22€, allerdings
auch STM32F030 0,62€.
Aber wie gesagt sind das eher sportliche Gründe. Mir gefallen
mittlerweile die Gehäuseformen TSSOP20 und dann (für mehr Pins) LQFP48
und auch LQFP64.
Yalu X. schrieb:> In der Mounriver-Toolchain für die CH32-Controller wird die generische> soft-fp der glibc verwendet. Diese ist in C implementiert und in> keinster Weise an spezifische CPU-Typen angepasst. Die AVR-FP-Routinen> hingegen sind in Assembler speziell für diesen CPU-Typ geschrieben.
Das dürfte dann wohl die "Ursache" sein und vielen vielen Dank für die
Info (meine ich absolut ohne Ironie - schade, dass man das immer dazu
schreiben muß). Schön - auch wenn andere das anderst sehen - wenn hier
wieder gezeigt wird, wie kompetent die Moderatoren sind: Daumen sowas
von nach oben !
Yalu X. schrieb:> Vielleicht erinnert sich noch jemand an die Zeiten, wo auch für den AVR> die soft-fp der glibc verwendet wurde. Da hat man um jeden Preis> versucht, auf FP-Arithmetik komplett zu verzichten.
Die Zeiten kenne ich noch!
Hans W. schrieb:> Gerade hat DHL mein 1. Design mit einem CH32V003 geliefert... hatte> schon Sorgen, dass ich bei der Komponentenauswahl für den Kunden> irgendwas übersehen habe :)
Was wirst du damit anstellen ?
Ralph S. schrieb:> F. schrieb:>> Der ATMega ist eine extrem gut ausgestattete moderne 8-Bit-CPU, die>> recht gut optimiert ist. Das lässt sich der Hersteller aber auch>> bezahlen. Der CH32V003 ist ein absolutes Lowcost-Produkt. Der ATMega328>> kostet so um die 1.50, der CH32V003 sagen wir mal so etwa 30 Cent. Da>> kriegst du also für ein Fünftel des Preises halbwegs vergleichbare>> Performance.>> Na ja, es ging ja nicht darum (zumindest hier nicht) was das Teil> kostet. Ich beschäftige mich mit dem Dingelchen ja eigentlich nur aus> "sportlichem" Antrieb heraus weil das so billig ist.
Es geht nicht darum, was es kostet, du beschäftigst dich aber damit,
weil es billig ist?
Der CH32V003 ist ein sehr einfacher RISC-V, den der Hersteller extrem
kostengünstig produzieren kann. Dass man da keine großartige Leistung
erwarten kann, ist irgendwie klar. RISC-V ist nicht auf absurde
Performance optimiert, sondern darauf, eine möglichst einfache, aber
dennoch praktikable Architektur zu sein, die zudem auch frei ist.
> Allerdings hätte> ich angenommen, dass RISCV den ATmega um längen schlägt.
Warum? Der wirklich schnelle Hardware-Multiplier des ATMega macht ihn
sehr leistungsstark, dazu noch gute, optimierte Compiler und Libraries.
Der CH32V003 kann im Gegensatz dazu tatsächlich echt absolut gar nichts,
da er einen ziemlich basalen RISC-V implementiert. Muss er aber
natürlich auch nicht, das Teil überzeugt über den Preis. Ich begrüße das
tatsächlich, anstatt überall den gruseligen 80C51 einzubauen. Außerdem:
Der CH32V003 schlägt den ATMega, er kostet ca. 20% des Preises. Bei
anspruchsvollen Echtzeitanforderungen mit gleichzeitig viel
Gleitkommaarithmetik ist man selbstverständlich mit anderen Prozessoren
besser bedient, für solche Dinge wie langsame Auswertung von
Umweltsensoren eignet sich aber beides.
> Ob ATmega jetzt> als "extrem gut ausgestattet" und "modern" bezeichnet werden kann, lass> ich jetzt mal unkomentiert.
Ich nicht: Du hast nämlich den "8-Bit-Microcontroller" vergessen.
Natürlich gibt's Moderneres, unter den 8-Bittern ist er aber der
Modernste.
Denk nur mal an den grausigen 80C51 (schlimme, teure Compiler; wenig
Register; schwieriges instruction set) oder den PIC (ich sag nur: banked
memory!), da ist der AVR im Vergleich ja eine echte Wohltat.
> Optimiert ist sie sicherlich. AVR sind> momentan - verglichen mit ihrer Leistung - sowieso relativ teuer:> günstigste Teile ATmega328 eher schon 2€, CH32V003 0,22€, allerdings> auch STM32F030 0,62€.
Ich hatte bei Digikey und LCSC nachgeschaut, meine Preise sind etwa
aktuell. Bei deinen Preisen ist der CH32V003 ja sogar noch besser, da
kostet der nur etwas leistungsfähigere ATMega328 ja bereits das
Neunfache.
> Aber wie gesagt sind das eher sportliche Gründe. Mir gefallen> mittlerweile die Gehäuseformen TSSOP20 und dann (für mehr Pins) LQFP48> und auch LQFP64.
Das ist ja durchaus verständlich, aber der CH32V003 ist eben ein echtes
Lowcost-Produkt für Anwendungen, in denen man bisher wahrscheinlich
irgendeinen 80C51 verwendet hat. Dafür ist er definitiv deutlich besser.
Mich wundert ehrlich gesagt, dass er an den ATMega328 rankommt.
F. schrieb:> Der wirklich schnelle Hardware-Multiplier des ATMega
Naja... Der stm32f0 hat einen 1-cycle multiplier... Halb so viele Takte
wie der verhältnismäßig uralte AVR.
Aber gut, die AVRs laufen anscheinend in einem 320nm Prozess und der
stm32 in 180nm. Da bekommst du einfach viel mehr auf viel weniger Fläche
hin.
Beim CH32V... hab leider noch keine Referenzen zum Halbleiter Prozess
gefunden.
Mit einem alten AVR (also im Alter von m328) würde ich wirklich kein
neues Projekt mehr starten wollen.
Die ganzen F103, die es so gibt, sind z.B IMHO fast immer die bessere
Alternative.
Die Auswahl des Controllers ist halt immer ein trade-off...
F. schrieb:> Der CH32V003 ist ein sehr einfacher RISC-V, den der Hersteller extrem> kostengünstig produzieren kann.
Das stimmt. Im CH32v307 ist ein wesentlich potenterer Risc-V... Ca 1€
teurer als der mega328, dafür mit FPU, USB und Ethernet phy (10mbit
Ethernet, 480mbit USB) usw.
Risc-V und ARM gibt's halt von extrem einfach bis ultra performant... Da
muss man schon recht genau schauen welchen Befehlsatz der Core
tatsächlich implementiert.
Es wär' wirklich interessant wie sich die soft-fp lieb von segger
schlagen würde...
73
Die eine Sache ist der Floating-Point-Benchmark, der stark durch die
Implementierung bestimmt ist.
Die andere Sache ist die grundsätzliche Geschwindigkeit des Prozessors.
Wie oben beschrieben, erhöht sich die Geschwindigkeit
Kommando-Byte-Fetch nicht beim Umstellen von 24Mhz auf 48MHz.
Ich würde mal einen standardisierten Benchmark wie den
Drystone-Benchmark laufen lassen, um zu sehen, ob es nur an der
Floating-Point Implementierung liegt. Damit erhält man etwas bessere
Einblicke als die in diesem Thread beschriebenen Vermutungen.
https://github.com/oomlout/oomlout-BMAR
Christoph M. schrieb:> Wie oben beschrieben, erhöht sich die Geschwindigkeit> Kommando-Byte-Fetch nicht beim Umstellen von 24Mhz auf 48MHz.>> Ich würde mal einen standardisierten Benchmark wie den> Drystone-Benchmark laufen lassen, um zu sehen, ob es nur an der> Floating-Point Implementierung liegt.
Einen "standardisierten" Benchmark braucht's eigentlich nicht, da wir ja
(erstmal) nur sehen wollen, was der Unterschied zwischen 24 MHz und
einer 48 MHz Clock bei CH32V003 ausmacht. Da es ja keine FPU Hardware
gibt, würde auch das Apfelmännchen taugen. Evtl. wäre Ralph so nett und
lässt mal das Apfelmännchen mit nur 24 MHz auf dem CH32V003 laufen und
postet die Ergebnisse.
Der Dhrystone ist wohl dann sinnvoll, wenn wenn man die Performance von
verschiedenen µC im integer Bereich vergleichen will. Wobei ich nicht
weiß, was ein aktueller gcc (je nach Optimierungsstufe) aus dem
Dhrystone macht.
Mir würde erstmal sowas reichen:
CH32V003 / 48 MHz => 62.9 Sekunden
CH32V003 / 24 MHz => ? Sekunden
Fyi: mich hat das nicht ganz in Ruhe gelassen mit der float library und
etwas weiter gegoogelt.
Ans Tageslicht kam das hier: https://github.com/pulp-platform/RVfplib
Dazu gibt's auch ein paper von der ETH zürich...
https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/582612/rvfplib.pdf;jsessionid=1B9CB0AB1B260620F676C7FD38A2C5F9?sequence=1
Die scheint auch in der esp32-idf zum Einsatz zu kommen. So ich Zeit
habe, werde ich das in den nächsten Tagen Mal testen...
Wenn man dem Benchmarking im paper traut, dann sollten sich die
Ausführungszeit mit dieser lib im Vergleich zur glibc in etwa halbieren.
Interessant ist auch der Vergleich zur segger-lib...die dürften da
teilweise wirklich jeden taktzyklus rausgequetscht haben... Vor allem
bei den Divisionen...
73
Hans W. schrieb:> Der F0 und der AVR sind auf den Takt normalisiert in etwa gleich auf.
Ist das nicht auch erstaunlich? Ein 8-bitter muss doch vermutlich viele
Zwischenschritte berechnen um auf die volle Float-Bitbreite zu kommen.
Thorsten M. schrieb:> Ist das nicht auch erstaunlich?
Eigentlich überhaupt nicht.
Die ARM Cortex-M Architektur ist bei byteweisen Zugriffen auf den
Speicher nicht gerade für seine Effizienz bekannt.
Genau dieses Bit-Verdrehen brauchst du aber bei IEEE754 haufenweise.
Nebenbei ist gerad der Cortex M0 als billiger 8-bit Ersatz entwickelt
worden.
Daher hat er auch nur einen 32x32=32bit Multiplier verbaut.
Nachdem die 32bitter typischerweise in neueren Halbleitertechnologien
gefertigt werden, ist es auch klar, warum die chips tendenziell billiger
sind als alte 8-bitter.
Beim CH32V003 ist es wahrscheinlich so, dass der Großteil der Kosten im
Packaging und nicht im Chip liegen.
Im übrigen: Wer so kleine Chips verbaut, der hat einfach keine Ansprüche
an die Hardware. Selbst ein 32F103 von ST kostet ca 1,50 bei LCSC. Das
ist in etwa der Preis von einem ATMega328.
Was aber den CH32V003 so interessant macht: Er kann mit 5V betrieben
werden.
In meiner Anwendung "brauche" ich das, weil ich alles direkt von einem
Lipo versorge. Also 3...4,2V.
Übrigens: Ich habe mir so ein combi-devboard-angebot mit CH32V003 und
CH32V203 geholt. Damit werde ich mal versuchen, die Zahlen von oben zu
verifizieren.... Die SPI Ausgabe werde ich dabei aber auskommentieren...
es sei denn, ich bekomme das komplette Projekt vom TO :)
Der CH32V203 ist nämlich dem STM32F103/STM32F203 ähnlich... nur RISC-V.
Dort wäre auch eine FPU mit drinnen und er kann 144MHz. Preislich ist er
bei 60Cent. Damit sollte er in diesem "Benchmark" eigentlich die
Geschwindigkeit vom F401 erreichen.... Das ist eigentlich schon ein
Hammer um den Preis!
73
Hans W. schrieb:> Der CH32V203 ist nämlich dem STM32F103/STM32F203 ähnlich... nur RISC-V.> Dort wäre auch eine FPU mit drinnen und er kann 144MHz. Preislich ist er> bei 60Cent.
Nur hört dann der Spaß mit 5 V wieder auf ;-)
FP beim CH32V003 würde mich (eher als Ersatz für einen ATtiny) nur am
Rande interessieren. Augenscheinlich ist seine Stromaufnahme nicht
sonderlich klein und mehr Interruptprioritäten würden nicht schaden.
Mehr Details hatte ich mir noch nicht angesehen.
Der Preis ist aber sehr nett, wenn man größere Stückzahlen braucht ;-)
Klaus R. schrieb:> Mir würde erstmal sowas reichen:>> CH32V003 / 48 MHz => 62.9 Sekunden> CH32V003 / 24 MHz => ? Sekunden
Mit der Zeile
ty= 2.0f*wx*wy+jy;
für float-Berechnung (und nicht double) benötigt das Apfelmännchen mit
24 MHz dann 95.6 Sekunden! (für welche Betrachtungen auch immer).. :-)
Hans W. schrieb:> Übrigens: Ich habe mir so ein combi-devboard-angebot mit CH32V003 und> CH32V203 geholt. Damit werde ich mal versuchen, die Zahlen von oben zu> verifizieren.... Die SPI Ausgabe werde ich dabei aber auskommentieren...> es sei denn, ich bekomme das komplette Projekt vom TO :)
:-) :-) :-) ich bin noch am "evaluieren" und am für mich anpassen.
Natürlich kann ich das in ein ZIP-File einpacken und zur Verfügung
stellen (habe ich sowieso irgendwann vor, weil es aus meiner Sicht der
Dinge kein wirklich gutes "Getting started" gibt ... und schon überhaupt
nicht auf Deutsch).
In meinem "Paket" habe ich im ch32fun Framework herumgewerkelt, das
Grundgerüst des Makefiles für mich angepasst. Ich mag zum Bsp. nicht,
bei einem "make" oder "make all", dass der Code compiliert, gelinkt und
gleich noch upgeloadet wird. Meine Editoren und meine Toolchain sind so
ausgelegt, dass ein einfaches einfach nur ein "build" durchführt und ein
"make flash" das ganze hochlädt. Außerdem habe ich aus meinem Paket
Dateien entfernt, die nicht "ch32v003" heißen (irgendwann möchte ich
auch den #define-Wust aus den .c .h so säubern, dass es eben nur noch
ch32v003 heißt, einfach um besser bestimmte Dinge kontrollieren oder
ändern zu können).
Außerdem sind meine Funktionen nur in den Quellcodes dokumentiert (die
Funktionsschnittstelle). D.h. momentan muß man da dann eben in die
Sources schauen.
Uuuuund wenn es dann kein "Gemecker" über den Stil wie ich etwas
realisiere gibt, kannst du gerne mein "Paket" haben. Schmunzeln muß:
mein eigenes printf ist häufig Stein eines Anstoßes. Das Fun-Paket hat
ein printf automatisch integriert, welches Debug-Informationen auf der
seriellen Schnittstelle ausgibt. Allerdings nur TxD und kein RxD ... und
zu dem im Code auch größer als meiner. Also habe ich ein eigenes printf
und in der Main-Datei muß dann stehen: void my_putchar(char ch) ... und
in meiner my_printf.c Datei ist das dann als extern deklariert.
Wenn Dir das nichts ausmacht: gerne !
F. schrieb:> Denk nur mal an den grausigen 80C51
Die waren nicht grausig, ich habe die "geliebt". Zudem bin ich bis heute
dem Intel-Stil der Mnemonic verhaftet, egal ob das 8080, MCS-48 (jaja,
den habe ich auch noch gemacht), MCS-51 oder später am PC für 8086 und
dann 80286 gemacht habe. Ein MOV und ein JMP war mit immer lieber als
ein ld und ein br. Und die kleinen Dinger habe ich dann eh nicht mit
Hochsprache programmiert.
Hans W. schrieb:> Der CH32V203 ist nämlich dem STM32F103/STM32F203 ähnlich... nur RISC-V.> Dort wäre auch eine FPU mit drinnen und er kann 144MHz. Preislich ist er> bei 60Cent. Damit sollte er in diesem "Benchmark" eigentlich die> Geschwindigkeit vom F401 erreichen.... Das ist eigentlich schon ein> Hammer um den Preis!
Das werde ich dann mal später evaluieren, bei der letzten Bestellung
hatte ich mir aus diesen Gründen genau einen V203 mitbestellt.
Grundsätzlich funktioniert der zwar ähnlich dem V003, aber eben nur
ähnlich.
Im übrigem ist es so eine Sache mit dem STM32F401 ... aus blanker
Neugierde hatte ich mir bei lcsc.com einen STM32F402 mitbestellt, der
bei ST scheinbar gar nicht gelistet ist, es aber ein chinesisches
Datenblatt dafür gibt (von ST). Es scheint auch keine Fake-MCU zu sein
und so habe ich ein Board damit aufgebaut und darauf Programme laufen
lassen, die ansonsten auf einem F401 laufen. Es gab keine Unterschiede:
Ein Binärfile ließ sich einfach hochladen und die Programme laufen alle
(Kennung vom F402 ist auch die vom F401). Warum nun F402?
STM32F402RCT => 84MHz, Floatingpoint, 256 kB Flash, 64 kB Ram
Preis: 1,46€
(auf dem F402 läuft das Apfelmännchen im übrigen mit exakt derselben
Geschwindigkeit wie mit dem F401: 0,5 Sekunden ... und von dieser MCU
bin ich dann wirklich ein FAN)
>(auf dem F402 läuft das Apfelmännchen im übrigen mit exakt derselben>Geschwindigkeit wie mit dem F401: 0,5 Sekunden ... und von dieser MCU>bin ich dann wirklich ein FAN)
Da wäre jetzt noch der PiPico 2 mit dem Apfelmänchen auf 2 Kernen und
auf 200MHz übertaktet interessant.
>warum ?
Um zu sehen, ob er schneller ist. Die STM-Architekturen sind ja nicht so
schlecht und es könnte für den PiPico schwierig sein, die selben
Geschwindigkeiten zu erreichen.
Außerdem sind Apfelmännchen ideal für die Parallelverarbeitung.
So, :-) auf einfachen Wunsch einer einzelnen Person habe ich jetzt mal
das ganze Projektpaket zusammengefasst auf das nötigste.
Als Compiler benötigt man: riscv-none-elf-gcc (bei mir ist es die
Version 14.2.0-3
Dieser sollte im systemweit verfuegbar sein. Das schöne an diesem
Compiler ist (wie auch beim arm-none-eabi-gcc) dass er in "irgendein"
Verzeichnis gelegt werden kann (bei mir ist es /usr/local/) und in der
.bashrc nur der Pfad erweitert sein muss.
So, das Archiv enthält alle Dateien um das Apfelmännchen für einen
CH32V003 zu übersetzen, befindet sich im Order:
- fraktal_speedtest
Dem ganzen Paket habe ich Teile des CH32fun mit eingefügt und manche
Dinge daraus auch geändert. Allen voran das Makefile fraktal_speedtest
Aaaaber: für diejenigen (wie mich) die immer auch die Bastler sind
(heißt das heute Maker?) sind in dem ganzen CH32Fun Paket Dinge
versteckt, die nicht so wirklich richtig beschrieben sind. Die
Kurzfassung:
- es gibt eine Programmersoftware für Arduino-Uno / Nano, die in der
Lage ist, einen CH32V003 zu programmieren. Der ist zwar schnarchlangsam,
aber er kann es. Nennt sich ardulink. Bei näherem Hinsehen, läuft das
Programm auch auf ATmega88, ATmega168 und bei noch genauerem Hinsehen
sogar auf ATtiny2313. Dort habe ich Quellcode manipuliert und es kann im
Verzeichnis ./ardulink eine Firmware für AVR erstellt werden, die den
Programmer für einen CH32V003 darstellt
- das Uploadprogramm zu einem CH32V003 heißt minichlink und ist im
Ordner minichlink. Dieses Programm compilieren und im systemweit
verfügbar machen (bei mir im selben Ordner wie der Compiler
- in den Ordner bootloader ist ein wirkliches Schmankerl: Ein
Bootloader, der in einem CH32V003 installiert werden kann (nimmt noch
nicht einmal Programmflashspeicher weg) und fortan braucht es keinen
Programmer
- im Ordner rvswdio_programmer ist die Firmware für einen Programmer,
der in einem CH32V003 arbeitet und in der Lage ist, als Programmer eben
für diesen Chip zu dienen.
Die originale Zeichnung wie das zu beschalten ist, finde ich
"dahingerotzt" (Entschuldigung an die, die das CH32FUN Framework
aufgebaut haben) und aus diesem Grund habe ich einen saubereren
Schaltplan gezeichnet. Die Schaltung habe ich nach allerfeinster V-USB
Manier für AVR-Controller (also eher kein so gutes USB :-) ) erweitert,
so dass ein Programmer oder Bootloader mit 3.3V oder mit 5V laufen kann
und das ganze umschaltbar gemacht. Hier ist (wie bei diesem V-USB Sachen
immer) darauf zu achten, dass das Zenerdioden kleinerer Leistung sind,
da ich die Erfahrung gemacht habe, dass die Kurve in Sperrrichtung nicht
so senkrecht nach unten geht wie es wünschenswert wäre und von daher
sollten das kleine Z-Dioden mit 1/4W Leistung sein).
Interessanterweise kann man mit dem Bootloader eben die
Programmerfirmware flashen aber bei Bedarf auch andere Programme laufen
lassen.
-----------------------------------------
So, wer hier also gerne mitevaluieren möchte kann das hier gerne
herunterladen, außer einem Chip (wenn man den als Bootloader betreibt)
und einen AVR mit USB-Bridge (Arduino) braucht es nicht!
By the way: Wäre fast schon etwas für ein Projekt oder einen Artikel
Christoph M. schrieb:> Da wäre jetzt noch der PiPico 2 mit dem Apfelmänchen auf 2 Kernen und> auf 200MHz übertaktet interessant.
200 sind nach neuer Zeitrechnung (laut Raspberry ltd) nicht übertaktet.
Die 420MHz hier, die sind's allerdings. ;-)
Edit: Fipptehler
... eigentlich ging es mir ja nur um "float". Weil aber in der
Diskussion grundsätzlich über Geschwindigkeit diskutiert wurde habe ich
einen weiteren Test gemacht.
An sich wollte ich drystone oder whetstone implementieren, was daran
scheiterte, dass bei einbinden der Math-Bibliothek mit -lm schon alleine
die Berechnung eines einzelnen Sinus nicht in den Flashspeicher des
CH32V003 passt (produziert ein Compilat > 18 kByte).
Okay, aber für einen Test war ja das Apfelmännchen nicht gaaaanz so
schlecht.
Also wollte ich wissen wie es sich denn mit Integer-Berechnungen
verhält.
Damit die Ergebnisse vergleichbar sind, habe ich einen
Pseudozufallszahlengenerator implementiert, der seine Werte mittels 2
linear rückgekoppelten 32-Bit Schieberegister die miteinander
"ver-xoder-d" erzeugt.
Als Rechentest werden 2000 Linen und 2000 Kreise nach dem
Bresenham-Algorithmus berechnet, die mittels 16-Bit Integerberechnung
erfolgen.
So gibt es hier einen Mix an 32-Bit und 16-Bitberechnungen. Die
Programme, für die, die das wirklich interessiert habe ich hier
angefügt.
Die Ergebnisse sind:
ATmega328p / 16 MHz : 41,0 Sekunden
CH32V003 / 48 MHz: 8,1 Sekunden
CH32V003 / 24 MHz: 13,5 Sekunden
Kuriosität am Rande:
Compilat für ATmega328p (okay, alter Compiler) avr-gcc v. 7.3.0 : 8586
Bytes
Compilat für CH32V003 riscv-none-elf-gcc v. 14.2.0 : 3768 Bytes
Eigentlich hätte ich erwartet, dass der V003 mehr Speicher als der 328p
benötigt.
Andererseits ist mir positiver Weise mit dem V003 aufgefallen gewesen,
dass der Speicherbedarf für 2 der Spiele, die auf einem STM32F030 laufen
und dort beide knapp über 18 kByte benötigen für den CH32V003 hierfür
knapp unter den 16 kByte liegen (und auch ausführbar sind).
F. schrieb:> Das ist ja durchaus verständlich, aber der CH32V003 ist eben ein echtes> Lowcost-Produkt für Anwendungen, in denen man bisher wahrscheinlich> irgendeinen 80C51 verwendet hat. Dafür ist er definitiv deutlich besser.> Mich wundert ehrlich gesagt, dass er an den ATMega328 rankommt.
Hierzu --meine-- Meinung:
Der CH32V003 kommt nicht nur an den ATmega328 heran, unterm Strich
überholt er ihn auf fast allen Gebieten oder ist überlegen.
Vorteile für den ATmega328p:
+ 32kByte Flash (anstelle 16kByte beim V003)
+ internes EEProm
+ Geschwindigkeit bei float auf demselben Niveau wie V003
Vorteile für den CH32V003
+ für Integerberechnungen sehr viel schneller
+ SPI sehr viel schneller als AVR
+ extrem billig
+ relativ speicherplatzschonend
+ läuft mit 3,3V und mit 5,0V
+ voller Takt auch ohne Quarz
+ USART (hat mich überrascht) habe ich getestet bis 460800 Bd und das
funktionierte
problemlos
Beim vielen Testen des CH32V003 (ich bin da noch nicht fertig) ist
aufgefallen:
- I2C ist ähnlich doof wie bei STM32F0, der Controller will vorher schon
wissen, wieviel Bytes auf dem Bus transferiert werden (habe Codes vom
STM32F0 dann adaptiert, kommt aber meiner früheren Vorgehensweise nicht
so sehr entgegen, funktioniert aber)
- ADC hat leider nur 10-Bit Auflösung, die 12-Bit eines STM32 wären
schön. Bei konstant gehaltener Betriebsspannung und Eingangsspannung am
ADC-Pin nach Laufzeit 3 Stunden (Zimmertemperatur) Abweichung von 2
Digits
- wirklich schön ist Timer 2. Hier gibt es einen wirklich sehr
komfortablen Prescaler, der komplett mit 16-Bit beschreibbar ist. Hier
können wirklich "krumme" Taktvorteiler eingetragen werden. Eine
Kombination von Prescaler= 48000 und einem Compare auf 1000 ergibt hier
tatsächlich eine Sekunde mit der es dann möglich ist, den Timer 2
Interrupt wirklich nur jede Sekunde aufzurufen.
Summasumarum ist von daher der CH32V003 nicht nur eher ein Ersatz für
ATtiny sondern eher auch für ATmega, wenn die Pinanzahl und der
Speicherplatz ausreichend ist
--------------------------
Okay, ich wollte eigentlich gar nicht so viel schreiben, entschuldigung
!
--------------------------
PS: Nachtrag für obigen Post:
riscv - Compiler gibt es unter:
https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases/
Ralph S. schrieb:> ADC hat leider nur 10-Bit Auflösung, die 12-Bit eines STM32 wären> schön.> Summasumarum ist von daher der CH32V003 nicht nur eher ein Ersatz für> ATtiny sondern eher auch für ATmega, wenn die Pinanzahl und der> Speicherplatz ausreichend ist
Für etwa den doppelten Preis eines CH32V003 bekommst du den CH32V203.
Der hat den gewünschten 12-Bit-ADC, mehr Pins (37 GPIOs), mehr Flash (64
KiB), mehr RAM (20 KiB) sowie Hardwaremultiplikation und -division.
Darüberhinaus hat er im Vergleich zum CH32V003 doppelt so viele Timer,
I²C, SPI und OPAs. Die Taktfrequenz ist dreimal so hoch, USARTs hat er
sogar viermal so viele. Damit nicht genug: Es gibt auch noch 2×USB,
1×CAN und 10×TouchKey.
Für den Preis von etwa fünf CH32V003 (immer noch deutlich billiger als
der ATmega328P) bekommst du den CH32V303. Diese hat neben einer FPU noch
deutlich mehr Flash (256 KiB), RAM (64 KiB), Timer (10), USARTs (8),
GPIOs (80), OPAs (4), ADC-Kanäle (16) und ein zusätzliches SPI (3).
Hinzukommen 2×DAC (12 Bit), 2×I²S, SDIO, FSMC und ein TRNG.
Speziell für Lottogewinner (also etwa so teuer wir der ATmega328P) gibt
es den CH32V307, bei dem man noch Ethernet sowie Highspeed für eines der
beiden USB-Interfaces obendrauf bekommt.
Somit decken die CH32Vxxx neben der Apfelmännchenmalerei auch noch eine
recht große Palette weiterer Anwendungen ab ;-)
Yalu X. schrieb:> Für etwa den doppelten Preis eines CH32V003 bekommst du den CH32V203.> Der hat den gewünschten 12-Bit-ADC, mehr Pins (37 GPIOs), mehr Flash (64> KiB), mehr RAM (20 KiB) sowie Hardwaremultiplikation und -division.
Den V203 habe ich hier und nur mal superkurz darüber gesehen. Register
sind zwar ähnlich, aber eben nur ähnlich. Immerhin kann der 144 MHz und
die Hardwaremultiplikation/Division auch als Floatingpoint-Unit (FPU).
:-) :-) :-) vllt. male ich dann darauf ja auch Apfelmännchen (obschon es
sch ja auch zum Zeichnen von Linien und Kreisen eignet).
Aber irgendwie bin ich dann in dieser "Leistungsklasse" den STM32
verhaftet (hier sind dann mein "Lieblinge" STM32F402, STM32F407 und
STM32F429)
Spaß beiseite: Mir ging es eigentlich ursprünglich nur darum
herauszufinden, was denn an diesem V003 dran ist, weil der des öfteren
erwähnt wird. Für eine Anwendung sucht man sich den Controller heraus,
von dem man annimmt dass er den Ansprüchen die an ihn gestellt werden
gewachsen ist. Hier ist es dann vllt. nicht schlecht, mehrere zur
Auswahl zu haben.
Im Fall vom V003 im TSSOP20 Gehäuse ist super von Vorteil, dass er
Pinkompatibel zum STM3S003 / S103 ist. Hier habe ich spaßeshalber den
V003 (in besonderen Fall für Panelmeter für DS18B20 Temperatursensor) au
eine Platine gelötet, die eben für den STM8 entwickelt war. Das Programm
angepasst (eigentlich keine Änderung bis auf die Systeminitialisierung)
und die Schaltung lief sofort in der "fremden" Platine.
Von daher ist der (wie in irgendeinem Thread hier) erwähnt wurde der
V003 dann der Ersatz für STM8, wenn diese - wie schon einmal -
abgekündigt werden. Platinen wären weiter nutzbar.
>ATmega328p / 16 MHz : 41,0 Sekunden>CH32V003 / 24 MHz: 13,5 Sekunden
41Sec*16/24= 27.333 Sec // Atmega, wenn 24MHz
Interessant: Könnte der Atmega328 24MHz wäre er etwas halb so schnell
wie der CH32V003
Christoph M. schrieb:> Interessant: Könnte der Atmega328 24MHz wäre er etwas halb so schnell> wie der CH32V003
Um die generelle Leistung eines µC zu bewerten, sollte man eine größere
Applikation mit einer breiter aufgestellten Nutzung der Maschinenbefehle
vergleichen.
Es ist problemlos möglich, ein Programm zu schreiben, welches einen 6502
bei 1 MHz verdammt gut aussehen lässt. (Schneller als ein ATMega bei
16 MHz)
Dennoch käme niemand auf die Idee zu behaupten, dass ein oller 6502 auch
nur annähernd die Leistung eines Mega erreicht.
>Es ist problemlos möglich, ein Programm zu schreiben, welches einen 6502>bei 1 MHz verdammt gut aussehen lässt. (Schneller als ein ATMega bei>16 MHz)
Das musst du mir mal zeigen.
Christoph M. schrieb:> Das musst du mir mal zeigen.
Gerne. Später.
Aber ich lass' es erst einmal ein wenig so stehen.
Einige der Älteren werden sich gewiss schmunzelnd erinnern.
PS. Kleiner Tipp ist aber erlaubt.
Obwohl … Ach egal … Zum Beispiel Fibonacci.
Yalu X. schrieb:> Für etwa den doppelten Preis eines CH32V003 bekommst du den CH32V203.
Der läuft halt nicht mehr mit 5V, und 5V-tolerant sind seine I/Os wohl
auch nicht.
Oberhalb des CH32V003 aber gibt es auch noch den CH32V006 - mit 8 kB
RAM, 62 kB Flash-ROM, 12-Bit-ADC, 2 UARTs, Betriebsspannungsbereich 2 ..
5 V. Und im QFN32 hat er dann auch mehr gleichzeitig nutzbare I/O-Pins.
https://github.com/ch32-riscv-ug/CH32V006?tab=readme-ov-file
Ralph S. schrieb:> Den V203 habe ich hier und nur mal superkurz darüber gesehen. Register> sind zwar ähnlich, aber eben nur ähnlich. Immerhin kann der 144 MHz und> die Hardwaremultiplikation/Division auch als Floatingpoint-Unit (FPU).
Sicher, dass der eine FPU hat? Ich dachte, die gibt es erst beim V3xx.
Harald K. schrieb:>> Single cycle multiplication, hardware division,> hardware FPU
Das dürfte ein Fehler sein und ist wohl darauf zurückzuführen, dass in
dem Datenblatt Informationen zum CH32V203 (ohne FPU) und CH32V3xx (mit
FPU) vermischt sind.
Hmmm.. der CH32B203 hat einen Qingke V4B Kern.
Laut dem Qingke V4 Manual hat er tatsächlich keine FPU... Die hätte nur
der V4F...
Hmm... Guter Hinweis mit dem Datenblatt misch-masch
73
Yalu X. schrieb:> Das dürfte ein Fehler sein und ist wohl darauf zurückzuführen, dass in> dem Datenblatt Informationen zum CH32V203 (ohne FPU) und CH32V3xx (mit> FPU) vermischt sind.
Oh. Das spricht nicht für WCH, denn das steht gleich auf der ersten
Seite des Datenblatts in der Featureliste. Vermutlich sind die
chinesischen Unterlagen besser korrigiert, die wird man dann in solchen
Fällen mit einem Übersetzer à la Google Translate hinzuziehen müssen.
Hmpf.
Harald K. schrieb:> Vermutlich sind die chinesischen Unterlagen besser korrigiert,
Mit DeepL vom Chinesischen ins Englische übeersetzt:
Datenblatt CH32V203 (V2.8)
Kernel Core:
- Green Barley 32-bit RISC-V kernel with multiple instruction set
combinations
- Fast Programmable Interrupt Controller + Hardware Interrupt Stack
- Branch Prediction, Conflict Handling Mechanisms
- Single Cycle Multiplication, Hardware Dividing
- System Frequency 144MHz:
Datenblatt CH32V303/305/307/317 (V3.5)
Kernel Core:
- Green Barley 32-bit RISC-V4F kernel with multiple instruction set
combinations
- Fast Programmable Interrupt Controller + Hardware Interrupt Stack
- Branching Prediction, Conflict Handling Mechanisms
- Single Cycle Multiplication, Hardware Dividing, Hardware Floating
Point
- System Frequency 144 MHz, Zero-Waiting
Die englischen Datenblätter haben die gleichen Versionsnummern und sind
jeweils ein paar Tage jünger als die chinesischen. Die Abweichungen in
der englischen Version spricht damit immerhin dafür, dass die
Übersetzung nicht komplett automatisch erfolgt ist :)
Meine Wahl ch32x033/35, gibt es in tssop20, hat 62/20kB flash/ram,
12bit-adc, 14xtouch, pioc, 2xopa/pga, 3xcmp, usb/serial bootloader, den
besseren 4c core mit hw-mul und ist billig zu bekommen.
Besonder der pioc 2K/8bit-slave ermöglicht performante Interface
Realisierungen.
Zur Zeit mein Lieblingsspielzeug ...
Mehmet K. schrieb:> @majortom> Dem wäre noch der 3,3V/5V Spannungsbereich hinzuzufügen.
...und der integrierte vollständige Controller für USB-C PD.
Man kann mit den ch32x033/35 also einen vollständig programmierbares
USB-C PD Triggerboard bauen. Und das für insg. weniger Geld als die
Fertiglösungen.
Siehe hier:
https://github.com/wagiminator/CH32X035-USB-PD-Adapter
Sind schon nett die Dinger...
Ich glaube es wurde ja oben schon geschrieben
- der CH32V003 hat einen sehr einfachen RISC-V Core ohne
Multiplikationshardware. Außerdem ist die Ausfühung aus dem Flash nicht
sehr schnell, da kein Cache.
Schneller wird es mit:
- CH32V002 / CH32V006, denn die haben einen RISC-V core mit multiplier
- Du kannst mit ch32fun funktionen aus dem RAM ausführen lassen, was die
Flash-waitstates eliminiert. Dazu muss man bei der Funktiondeklaration
das attribut unten setzen.
1
2
void function (...) __attribute__((section(".srodata"))) __attribute__((used));
- Code optimieren, um die floating point operationen durch fixed point
zu ersetzen, bzw. einer eigenen floating-point implementierung. IEEE754
ist durch viele special cases langsam.
Noch schneller ist CH32V203 mit cache usw.
Thread beobachten
Seitenaufteilung abschalten