Forum: Mikrocontroller und Digitale Elektronik GigaDevice RISC-V: DAC mit Nuclei Studio


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Angehängte Dateien:

Lesenswert?

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 https://www.mikrocontroller.net/topic/518533 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:

1
This example is based on the GD32V103V-EVAL-V1.0 board, it shows how to use DAC concurrent mode
2
output voltage. No trigger source is chosen to trigger DAC. The DAC0 output pin is configured
3
PA4 and DAC1 output pin is configured PA5. There are two different voltage in PA4 and PA5. The
4
voltage of PA4 is VREF/2 and the voltage of PA5 is VREF/8.

Die Struktur der main-Methode zeigt nun den Aufruf dreier Funktionen:

1
int main(void)
2
{
3
    rcu_config();
4
    gpio_config();
5
    dac_config();
6
    while (1){
7
    }
8
}

Analog zum STM32 hat auch der GD32VF Clock Gating - wir müssen dafür sorgen, dass die Einheiten mit Arbeitstakt versorgt werden:

1
void rcu_config(void)
2
{
3
    /* enable the clock of peripherals */
4
    rcu_periph_clock_enable(RCU_GPIOA);
5
    rcu_periph_clock_enable(RCU_DAC);
6
}

Die eigentliche Konfiguration erfolgt in folgenden Funktionen:

1
void gpio_config(void)
2
{
3
    /* once enabled the DAC, the corresponding GPIO pin is connected to the DAC converter automatically */
4
    gpio_init(GPIOA, GPIO_MODE_AIN, GPIO_OSPEED_50MHZ, GPIO_PIN_4 | GPIO_PIN_5);
5
}
6
7
void dac_config(void)
8
{
9
    dac_deinit();
10
    /* configure the DAC0 */
11
    dac_trigger_disable(DAC0);
12
    dac_wave_mode_config(DAC0, DAC_WAVE_DISABLE);
13
    dac_output_buffer_enable(DAC0);
14
    
15
    /* configure the DAC1 */
16
    dac_trigger_disable(DAC1);
17
    dac_wave_mode_config(DAC1, DAC_WAVE_DISABLE);
18
    dac_output_buffer_enable(DAC1);
19
    
20
    /* enable DAC concurrent mode and set data */
21
    dac_concurrent_enable();
22
    dac_concurrent_data_set(DAC_ALIGN_12B_L, DAC_OUT_VAL0, DAC_OUT_VAL1);
23
}

Wichtig sind noch die beiden Konstanten:

1
#define DAC_OUT_VAL0 0x7FF0
2
#define DAC_OUT_VAL1 0x1FF0

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:

1
int main(void) {
2
    rcu_config();
3
    gpio_config();
4
    dac_config();
5
    uint16_t daculator = 0;
6
    while(1) {
7
        dac_concurrent_data_set(DAC_ALIGN_12B_R, daculator, daculator);
8
        daculator+=10;
9
        if (daculator>4000)daculator=0;
10
    }
11
12
    return 0;
13
}

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.

Weitere Ressourcen

GD32VF-Evaluationsboards bei TME => https://www.tme.eu/hu/en/katalog/?s_field=1000011&s_order=desc&search=GD32VF&visible_params=2%2C367%2C2479%2C35%2C783%2C2408%2C10%2C32%2C788%2C2955%2C9%2C351&mapped_params=351%3A1530178%3B

GD32VF-Evaluationsboards bei LCSC (seriöser chinesischer Distributor) => https://lcsc.com/search?q=GD32VF

Hennessy und Pedersen - allgemeine Einführung zu RISC-V bzw seiner ISA => https://www.amazon.com/Computer-Organization-Design-RISC-V-Architecture/dp/0128122757 (Bitte keinesfalls nach dem String "Hennessy Pedersen RISC-V architecture" auf Google HU suchen)


:
von Grano U. (grano)


Lesenswert?

> 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.

von Johnny B. (johnnyb)


Lesenswert?

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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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.

von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Lesenswert?

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.

von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Lesenswert?

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???

von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Lesenswert?

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...

von Operator S. (smkr)


Lesenswert?

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.

von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Lesenswert?

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!

von Einer K. (Gast)


Lesenswert?

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.

von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Lesenswert?

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.

von Sebastian E. (der_andere_sebastian)


Lesenswert?

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.

von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Lesenswert?

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

Dieser Beitrag kann nur von angemeldeten Benutzern beantwortet werden. Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.