Die Peripheriegeräte der GigaDevice-RISC-V-Mikrocontroller sind an denen des STM32F1 angelehnt. Hier wollen wir abermals auf das kostenlose Nuclei Studio zurückgreifen, um den DAC eines Evaluationsboards in Betrieb zu nehmen.
von Tam HANNA
Worum geht es hier?
Seit der Übernahme von ARM durch NVIDIA gilt, dass ARM eine „amerikanische“ Architektur ist - mit allen Vorteilen (finanzstarker Eigentümer) und allen Nachteilen (Sanktionsanfällig).
RISC-V ist eine quelloffene Prozessor-Architektur, die schon vom Konzept her sanktionssicherer ist, und ob der wegfallenden Lizenzkosten langfristig billiger ausfallen dürfte (Skalierungseffekte bevorzugen derzeit ARM, was zu „Preisparität“ führt).
GigaDevice bietet mit dem GD32VF1 seit einiger Zeit eine vergleichsweise gut verfügbare Serie von Mikrocontrollern an, die vom Aufbau der EA-Geräte am STM32 orientiert sind.
In diesem Artikel wollen wir den DAC eines Evaluationsboards in Betrieb nehmen. Die Einrichtung von der IDE haben wir dabei - im Detail - im unter Beitrag "GigaDevice RISC-V: erste Schritte ohne IAR" bereitstehenden Artikel beschrieben.
Kein Codegenerator
Wir hatten im letzten Artikel festgestellt, dass es für die GD32VF-Architektur keinen Codegenerator gibt. GigaDevice stellt stattdessen eine Sammlung leicht nutzbarer Codebeispiele zusammen – der verwendet Autor die Version 1.1.1.
Der Unterordner GD32VF103_Firmware_Library_V1.1.1\Examples enthält die in Abbildung eins gezeigte Projektstruktur, die die für die diversen Peripheriegeräte vorgesehenen Codestücke zur Verfügung stellt.
Das unter http://www.gd32mcu.com/data/documents/yingyongbiji/GD32VF103_Firmware_Library_User_Guide_V1.0.pdf bereitstehende PDF ist ebenfalls empfehlenswert, da es „alle“ Peripherietreiberfunktionen en Detail erklärt.
Wir wollen an dieser Stelle mit dem im letzten Artikel erzeugten Projektskelett weiterexperimentieren, und die in einem der DAC-Unterordner zur Verfügung stehenden Codeänderungen Tour a Tour einpflegen.
Das für uns relevante Beispiel ist Examples\DAC\DACC_output_voltage, der Inhalt des Verzeichnisses präsentiert sich wie in Abbildung zwei gezeigt.
Bei der „Analyse“ des von GigaDevice bereitgestellten Codes ist es immer empfehlenswert, mit der Datei readme.txt zu starten. Unter den Lizenzbedingungen findet sich im Fall des Beispiels folgende Funktionsbeschreibung:
Der Hinweis, dass der Wert 0x7FF0 dem Wert VREF/2 entspricht, zeigt dass der DAC eine Nominalauflösung von 12 bit bereitstellt. Mit diesem Wissen können wir die Hauptschleife unseres Programms nach folgendem Schema anpassen:
Ein weiterer Unterschied zum von GigaDevice bereitgestellten Code ist, dass wir hier die Konstante DAC_ALIGN_12B_R verwenden – das deshalb, weil der in daculator befindliche Wert rechtsbündig ist.
Lohn der Mühen ist, dass wir an den Pins PA4 und PA5 des „kleinen“ Evaluationsboard die in der Abbildung gezeigte Wellenform sehen. Die kleinen Unsauberkeiten in diesem Oszillographen stammen von EMI im Labor des Autors.
Fazit
Der Verzicht auf einen automatischen Codegenerator mag auf den ersten Blick erschrecken - in der Praxis lässt sich nach einer Umgewöhnungsphase erfahrungsgemäß genauso gut ohne ihn arbeiten. Der Autor hofft, dass die hier durchgeführten Experimente zur „Vertiefung“ ihres Interesses an RISC-V geführt haben.
> Seit der Übernahme von ARM durch NVIDIA gilt, dass ARM eine „amerikanische“
Architektur ist
Falsch. Nvidia hat ARM bis jetzt noch nicht übernommen. Der Prozess zur
Übernahme wurde angestoßen, ist aber noch am Anfang. Die britische
Wettbewerbsbehörde will bis Ende Juli einen ersten Bericht
veröffentlichen und später dann eine Entscheidung treffen. Bei den
chinesischen Behörden wurde erst kürzlich ein Antrag eingereicht und das
wird auch noch Monate dauern bis es zu einem Ergebnis kommt. Die
Übernahme wird wahrscheinlich erst nächstes Jahr erfolgen. Und falls
Nvidia scheitert, will Qualcomm sich mit anderen Firmen verbünden, ein
Konsortium gründen und ARM gemeinsam übernehmen.
Auch wenn ARM seinen Sitz in Großbritannien hat, werden sie als
amerikanisches Unternehmen gesehen. ARM hat in der Vergangenheit
amerikanische Unternehmen übernommen bzw. deren Technologien gekauft.
Die Amis wollen ihre Technologien kontrollieren und sie eigentlich nicht
ins Ausland verkaufen. Deswegen gab es Auflagen für ARM, womit sie de
facto zu einem amerikanischen Unternehmen geworden sind und auf die
Sanktionen der amerikanischen Regierung achten müssen.
Tam H. schrieb:> RISC-V ist eine quelloffene Prozessor-Architektur, die schon vom Konzept> her sanktionssicherer ist
Falsch. Die Geschichte zeigt laufend, dass Freizeitprojekte plötzlich
doch kommerzialisiert und dann die Benutzer zur Kasse gebeten werden.
Gutes Beispiel, die CD-Datenbank CDDB.
https://de.wikipedia.org/wiki/Compact_Disc_Database
Leider war ich selbst darauf hereingefallen und hatte ein paar meiner
CD's in der Datenbank erfasst, weil ich das Projekt unterstützen wollte
und nun scheffeln andere Kohle damit.
Bisher waren Tams Artikel nur schlecht und ohne viel Inhalt.
Jetzt kommen diese sogar mit groben Fehlern und direkte Falschaussagen!
Dass ARM wegen den ganzen Bedenken noch nicht von nvidia gekauft wurde
steht doch in jeder Newsseite, die etwas mit PC/Elekronik zu tun hat.
Aber im Artikel stehts so als wär das schon längst passiert.
@Johnny B
Intel überlegt ja schon sifive zu kaufen, eines der führenden
Unternehmen hinter der RISC-V Kernentwicklung.
->
https://www.heise.de/news/Milliarden-Uebernahme-Intel-soll-Interesse-an-RISC-V-Entwickler-SiFive-haben-6068890.html
Damit wäre schonmal ein großer Kernentwickler weg vom Fenster.
Die freie ISA alleine nützt einem ja nix ohne eine ASIC Fab.
Wodurch deine Aussage bestätgt ist und Tam wieder als Müllschreiber
dasteht.
Grano U. schrieb:>> Seit der Übernahme von ARM durch NVIDIA gilt, dass ARM eine „amerikanische“> Architektur ist>> Falsch. Nvidia hat ARM bis jetzt noch nicht übernommen. Der Prozess zur> Übernahme wurde angestoßen, ist aber noch am Anfang. Die britische> Wettbewerbsbehörde will bis Ende Juli einen ersten Bericht> veröffentlichen und später dann eine Entscheidung treffen. Bei den> chinesischen Behörden wurde erst kürzlich ein Antrag eingereicht und das> wird auch noch Monate dauern bis es zu einem Ergebnis kommt. Die> Übernahme wird wahrscheinlich erst nächstes Jahr erfolgen. Und falls> Nvidia scheitert, will Qualcomm sich mit anderen Firmen verbünden, ein> Konsortium gründen und ARM gemeinsam übernehmen.
Das sind alles Amerikaner, oder?
Was ihr hier nicht bedenkt: die Sanktionen, beispielsweise gegen die IR
Iran, gehen nicht nur gegen Unternehmen sondern auch gegen alles, was
USD verwendet. Das heisst, du brauchst einen in China ansässigen
Fertiger, etc pp.
Das ist ja der Grund warum ich immer GigaDevice empfehle und nicht
SiFive etc.
>> Auch wenn ARM seinen Sitz in Großbritannien hat, werden sie als> amerikanisches Unternehmen gesehen. ARM hat in der Vergangenheit> amerikanische Unternehmen übernommen bzw. deren Technologien gekauft.> Die Amis wollen ihre Technologien kontrollieren und sie eigentlich nicht> ins Ausland verkaufen. Deswegen gab es Auflagen für ARM, womit sie de> facto zu einem amerikanischen Unternehmen geworden sind und auf die> Sanktionen der amerikanischen Regierung achten müssen.
Dass die USA und UK traditionell eine sehr, naja, enge Beziehung haben
;)...bestätigt mich wieder, siehe oben.
Johnny B. schrieb:> Tam H. schrieb:>> RISC-V ist eine quelloffene Prozessor-Architektur, die schon vom Konzept>> her sanktionssicherer ist>> Falsch. Die Geschichte zeigt laufend, dass Freizeitprojekte plötzlich> doch kommerzialisiert und dann die Benutzer zur Kasse gebeten werden.> Gutes Beispiel, die CD-Datenbank CDDB.> https://de.wikipedia.org/wiki/Compact_Disc_Database> Leider war ich selbst darauf hereingefallen und hatte ein paar meiner> CD's in der Datenbank erfasst, weil ich das Projekt unterstützen wollte> und nun scheffeln andere Kohle damit.
Danke dir für dein sachliches Kommentar, auf das ich gerne eingehe.
Der Unterschied ist hier die lizenzrechtliche Lage. Open Source-Lizenzen
sind im Allgemeinen "klebrig". Das heisst, dass alles was einmal unter
OS releast ist, OS bleibt.
Selbst wenn der Anbieter zukünftige Releases "umlizenziert", kann man
immer den letzten quelloffenen Stand nehmen und damit dann selbst
weitermachen (Stichwort Fork).
Im Fall von GigaDevice bzw RISC-V denke ich, dass das sicher passieren
würde im Zweifelsfall. Außerdem, wieso - wenn RISC-V plötzlich
Lizenzspesen nimmt, wo wäre ihr Vorteil ggue ARM???
Mw E. schrieb:> Bisher waren Tams Artikel nur schlecht und ohne viel Inhalt.> Jetzt kommen diese sogar mit groben Fehlern und direkte Falschaussagen!
Bisher waren Fritzler-AVR-Kommentare nur von Ignoranz von allem abseits
des Achtbitters getrieben, nun kommt "Butthurt" dazu.
> Dass ARM wegen den ganzen Bedenken noch nicht von nvidia gekauft wurde> steht doch in jeder Newsseite, die etwas mit PC/Elekronik zu tun hat.> Aber im Artikel stehts so als wär das schon längst passiert.
Siehe oben.
>> @Johnny B> Intel überlegt ja schon sifive zu kaufen, eines der führenden> Unternehmen hinter der RISC-V Kernentwicklung.> ->> https://www.heise.de/news/Milliarden-Uebernahme-Intel-soll-Interesse-an-RISC-V-Entwickler-SiFive-haben-6068890.html> Damit wäre schonmal ein großer Kernentwickler weg vom Fenster.> Die freie ISA alleine nützt einem ja nix ohne eine ASIC Fab.
Wo fertigt GigaDevice nochmal??
> Wodurch deine Aussage bestätgt ist und Tam wieder als Müllschreiber> dasteht.
Nein, eher meine. Siehe oben.
Und ja: ich programmiere auch Achtbitter. Aber die Welt hat sich
geändert...
Tam H. schrieb:> Der Unterschied ist hier die lizenzrechtliche Lage. Open Source-Lizenzen> sind im Allgemeinen "klebrig". Das heisst, dass alles was einmal unter> OS releast ist, OS bleibt.
Das trifft aber auch (fast) nur auf die GPL zu.
Andere Open Source Lizenzen wie Apache, MIT, BSD erlauben genau das
einbetten des Opensource codes in deine Applikation, ohne dass du diesen
Code auch veröffentlichen musst.
Interessanterweise sind alle neueren Open Source Projekte mit solch
einer permissiven Lizenz versehen. Als grösstes GPL Projekt wird
vermutlich Linux bekannt sein.
Johnny B. schrieb:> Falsch. Die Geschichte zeigt laufend, dass Freizeitprojekte plötzlich> doch kommerzialisiert und dann die Benutzer zur Kasse gebeten werden.> Gutes Beispiel, die CD-Datenbank CDDB.
Hat aber trotzdem nichts damit zu tun. Hier geht es nicht um
Freizeitprojekte sondern um die Art der Lizenzierung. Natürlich, wenn
ich ein Freizeitprojekt starte, mir Leute helfen das aufzubauen, aber
ich behalte alle Rechte am Projekt: Na dann, danke für die Hilfe.
Hallo Operator,
erstmal vielen Dank!
Operator S. schrieb:> Tam H. schrieb:>> Der Unterschied ist hier die lizenzrechtliche Lage. Open Source-Lizenzen>> sind im Allgemeinen "klebrig". Das heisst, dass alles was einmal unter>> OS releast ist, OS bleibt.>> Das trifft aber auch (fast) nur auf die GPL zu.> Andere Open Source Lizenzen wie Apache, MIT, BSD erlauben genau das> einbetten des Opensource codes in deine Applikation, ohne dass du diesen> Code auch veröffentlichen musst.
Ja, schon. Aber der ursprüngliche Code ist immerdar unter der Lizenz
>> Interessanterweise sind alle neueren Open Source Projekte mit solch> einer permissiven Lizenz versehen. Als grösstes GPL Projekt wird> vermutlich Linux bekannt sein.
;) ich schreibe das unter Ubuntu ;)
>> Johnny B. schrieb:>> Falsch. Die Geschichte zeigt laufend, dass Freizeitprojekte plötzlich>> doch kommerzialisiert und dann die Benutzer zur Kasse gebeten werden.>> Gutes Beispiel, die CD-Datenbank CDDB.>> Hat aber trotzdem nichts damit zu tun. Hier geht es nicht um> Freizeitprojekte sondern um die Art der Lizenzierung. Natürlich, wenn> ich ein Freizeitprojekt starte, mir Leute helfen das aufzubauen, aber> ich behalte alle Rechte am Projekt: Na dann, danke für die Hilfe.
Danke dir!
Ich weiß nicht.....
Der von dir genannte ist quasi ein STM32 Nachbau mit RISC-V Kern.
Gut und schön....
Aber einen "riesigen" Zugewinn sehe ich da nicht.
Da gibts RISC-V Dinger, welche in einer ganz anderen Liga spielen.
z.B. der Kendryte K210
Das ist mal eine Wummbrumme!
Das Ding wird den Chinesischen Überwachungsstaat im Fluge erobern.
Nicht nur 2 64 Bit Kerne, sondern auch noch FFT und Neuronales Netz in
Hardware.
Hallo,
zu allererst danke dir für dein Kommentar, das mich sehr freut. Bitte
erlaube mir ein paar Anmerkungen - ich habe den Kendryte übrigens
hausintern in Verwendung.
Arduino Fanboy D. schrieb:> Ich weiß nicht.....> Der von dir genannte ist quasi ein STM32 Nachbau mit RISC-V Kern.> Gut und schön....> Aber einen "riesigen" Zugewinn sehe ich da nicht.
Das stimmt sicher. Aber baue mal was in Belarus oder Persien ;)
>> Da gibts RISC-V Dinger, welche in einer ganz anderen Liga spielen.> z.B. der Kendryte K210> Das ist mal eine Wummbrumme!
Sicher, außer Frage. Aber Stromverbrauch, Größe, Kosten und
Verfügbarkeit. Ich hatte insbesondere mit vierterem meine Probleme
> Das Ding wird den Chinesischen Überwachungsstaat im Fluge erobern.
Wenn es in ausreichender Menge verfügbar wäre und bei LCSC und leicht zu
kriegen.
> Nicht nur 2 64 Bit Kerne, sondern auch noch FFT und Neuronales Netz in> Hardware.
Unabhängig von der Diskussion, wem denn nun das Unternehmen ARM gehört,
kann ich nicht verstehen, wie manche hier dieses wirklich hilfreiche und
anfängerfreundliche Tutorial schlechtreden. Ich möchte mich stattdessen
persönlich bedanken für dieses Engagement, das sicher dem einen oder
anderen den Einstieg erleichtern wird.
Sebastian E. schrieb:> Unabhängig von der Diskussion, wem denn nun das Unternehmen ARM gehört,> kann ich nicht verstehen, wie manche hier dieses wirklich hilfreiche und> anfängerfreundliche Tutorial schlechtreden. Ich möchte mich stattdessen> persönlich bedanken für dieses Engagement, das sicher dem einen oder> anderen den Einstieg erleichtern wird.
Hallo,
danke dir!
Tam
Thread beobachten
Seitenaufteilung abschalten