STM32F746 Discovery ARDUINO

Hier das Example "Mandelbrot".

> Allerdings bekomme ich beim Versuch, das Beispiel "Display" für das
> STM32F746NG Discovery zu kompilieren folgende Fehlermeldung:

Hallo M.G.
das Problem hatte ich auch längere Zeit. Das liegt daran, dass die F7 
CPUs erst von neueren GCC Versionen unterstützt werden.

Ich habe das Problem folgendermaßen gelöst

Zuerst das Arduino-Framework von STM direkt installieren, wie hier 
installieren:

http://www.stm32duino.com/viewtopic.php?f=48&t=2098

Danach ist der Compiler auf dem neusten Stand und der Error sollte 
verschwinden.

Kannst Du mitteilen, wenn es geklappt hat?

Super.
Danke für die Info. Bin mal gespannt, was Du damit machst.

Weiß jemand, wie man die Touch-Funktion verwenden kann?

Von Adafruit gibt es eine Lib, aber der Controller ist nicht ganz der 
Selbe:
https://github.com/adafruit/Adafruit_FT6206_Library

Arglos zeigt sich ein Mohrhuhn auf dem TFT ....

( das Display ist eigentlich klarer, die Artefakte kommen durch meine 
Kamera )

Hallo,
das ist bestimmt ein absolut geiles Board. Die Unterstützung vom ST ist 
leider nicht so prickeld. Die Demos wie Mandelbrot, Oszi...
sind bei mir leider auch nicht da. Installation nach Anleitung.
Die Demo APP, die standardmäßig drauf ist kann ich auch nicht finden.
Wäre nett, wenn Ihr Eure Testst (Spielereien) hier hochladen  würdet.
Für den Einstieg in so ein aufgebohrtes Board brauche ich ein paar 
Demos.
Gerade für TFT und Touch.

Grüße
Lothar

>Die Demos wie Mandelbrot, Oszi...sind bei mir leider auch nicht da.

Hallo Lothar,

vom Framework von STM wird zwar bis jetzt das Board unterstützt, die 
wichtigen Treiber fehlen aber noch. Ich nehme an, dass STM das die 
nächsten Monate nachliefern wird.

Es ist besser, das FrameWork STM32GENERIC von "danieleff" wie oben 
beschreiben zu nutzen:
Beitrag "Re: STM32F746 Discovery ARDUINO"

Dort findest Du auch die funktionierenden Demos für das F7.

Hast Du das Board?

Was manchmal noch zu Problemen führt:

Die Darstellung der Examples im Menue ist "context sensitive", d.h. sie 
werden nur angezeigt, wenn man das richtige Board ausgewählt hat.

Beim Auswählen des Boards kann es dann noch mal zu einem Problem kommen: 
Wählt man das Discovery von STM sieht man natürlich nicht die Beispiele 
vom STM32GENERIC.
Deshalb also das Discovery Generic Board wählen, dann sich auch die 
Examples dafür da.

Die Uhr hat geschlagen ..

Hallo CM,

ich war ein paar Tage unterwegs, deswegen antworte ich erst heute. Ja, 
ich habe das Board, bin aber noch nicht dazu gekommen, Deine Tipps 
umzusetzen. Den Download habe ich schon gemacht.

Grüße
Lothar

So, jetzt läuft mein Board auch... nach vielen Handständen. Den GCC 
musste ich händisch aktualisieren. Läuft eben nicht alles so rund, wie 
ich mir das vorstelle. Mal sehen, was man damit so anstellen kann, der 
Zeitaufwand ist ja auch enorm.
Grüße
Lothar

Den hattest Du nicht manuel installieren muessen, wenn Du den 3.ten Posr 
hier gelesen haettest.

Hallo Markus,
das habe ich alles probiert, ohne Erfolg. Nachdem ich den "alten" GCC 
einfach mal gelöscht habe, wurde gar keiner mehr installiert. Dann habe 
ich via Bordmanager mal die F1 Unterstützung installiert. Prompt war der 
"alte" wieder installiert. Deswegen... gelöscht und die aktuelle Version 
einfach reinkopiert. Liegt vielleicht auch daran, dass ich schon viele 
Boards getestet habe und Arduino etwas verkorkst ist.

@Lothar,

falls du nicht an die Arduino umgebung gebunden bist,
kannst du zwecks Librarys für das F746 hier mal vorbeischauen:

http://mikrocontroller.bplaced.net/wordpress/?page_id=5329

hmm, bin ich der Einzige, der zu blöd dafür ist?
Nach Anleitung auf https://danieleff.github.io/STM32GENERIC/ 
runtergeladen und in  [Arduino]/hardware entpackt. Danach startet 
Arduino 1.8.3 nicht mehr.
Arduino_debug in der Shell gestarte meckert, daß in allen möglichen 
Unterverzeichnissen die 'platform.txt' fehlt.
Falls ich die reinkopiere startet Arduino wieder, meckert jetzt aber 
über fehlende 'boards.txt'
Die  STM32Generic-Boards stehen in der Boardauswahl nicht zur Verfügung.

Bin ich nicht Arduino-Kompatibel?

Unter Ubuntu habe ich einfach die gesamte Arduino-IDE dort enpackt:
~/Dokumente/tools/arduino-1.8.1/
und dann den STM32GENERIC Ordner dort in hardware
~/Dokumente/tools/arduino-1.8.1/hardware/STM32GENERIC$
Damit geht es bei mir einwandfrei.

Unter Win10 habe ich es so gemacht
Die IDE hier
C:\Tools\Arduino\Arduino1_8\
und dann den STM32GENERIC Ordner hier rein
C:\Tools\Arduino\Arduino1_8\hardware\STM32GENERIC

>Hallo Markus,
>das habe ich alles probiert, ohne Erfolg. Nachdem ich den "alten" GCC
>einfach mal gelöscht habe, wurde gar keiner mehr installiert. Dann habe
>ich via Bordmanager mal die F1 Unterstützung installiert. Prompt war der
>"alte" wieder installiert. Deswegen... gelöscht und die aktuelle Version
>einfach reinkopiert. Liegt vielleicht auch daran, dass ich schon viele
>Boards getestet habe und Arduino etwas verkorkst ist.

Ich glaube, da ist was durcheinander gekommen, die F1-Unerstützung ist 
glaube ich das falsche Framework.

Der Vorgang, mit dem es eigentlich gut gehen sollte:

1. das Framework von STM installieren
Das ist ja hier genau beschrieben: 
http://www.stm32duino.com/viewtopic.php?f=48&t=2098
Also:
a. den Link
https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
in die Arduino-IDE kopieren Files->Preferences->Additional Board Manager 
URLs
b. Im Board Manager "STM" eintippen und dann
STM32 Core by ST-Microelectroniks auswählen und "installieren" drücken.
Dann werden die 90MByte des GCC für die Cortex M7 Prozessoren mit 
herunter geladen und installiert. Man kann dann das F7 Disco im Board 
Manager auswählen und die LED blinken lassen.

Aber: Um das Display zu nutzen muss man danach das STM32GENERIC 
framework an die ein Post weiter oben beschriebene Stelle kopieren, die 
IDE neu starten und das Board im GENERIC framework auswählen.

Scheint dann ja doch an mir zu liegen, an verschiedenen Rechnern, unter 
Windows 7 und 10 in verschiedenen Verzeichnissen, immer der gleiche 
Fehler.

Also weiter 'zu Fuß' mit dem F7-Disco

Hast Du auch genau das richtige Board wie in dem Bild ausgewählt?
Es tauchen ja mehrere STM32F746 auf.

Bei Windows 10 gibt es noch diesen etwas versteckten Ordner, in den die 
Arduino IDE alles mögliche entpackt:
C:\Users\IchBins\AppData\Local\Arduino15

Markus schrieb:
> Hast Du auch genau das richtige Board wie in dem Bild ausgewählt?
> Es tauchen ja mehrere STM32F746 auf.

Nein, es taucht nichtmal der Menupunkt 'STM32GENERIC' auf. Da kann ich 
kein F7 auswählen.

Markus schrieb:
> Bei Windows 10 gibt es noch diesen etwas versteckten Ordner, in den die
> Arduino IDE alles mögliche entpackt:
> C:\Users\IchBins\AppData\Local\Arduino15

Ja, da kommen solche Ergänzungen ja normal rein. Dazu fehlen dem 
STM32Generic-Paket aber die Beschreibungsdateien. Die STM32Duino-Dateien 
landen da wenn man sie über den Boardmanager installiert und 
funktionieren auch.

>Ja, da kommen solche Ergänzungen ja normal rein. Dazu fehlen dem
>STM32Generic-Paket aber die Beschreibungsdateien.
>> C:\Users\IchBins\AppData\Local\Arduino15

Das Generic-Paket soll aber nicht da rein sondern in den Tools-Pfad wie 
ich es oben beschrieben habe. Ich habe auch probiert, es in dem 
Arduino15 Ordner zu installieren, das geht nicht.

Was eventuell auch noch sein könnte: Irgendwo habe sie erwähnt, dass man 
den Arduino Zero/Due support installieren soll. Ich weiß aber nicht 
mehr, ob ich das gemacht habe. Eigentlich bin ich davon ausgegangen, 
dass man es nicht braucht, wenn man den orignalen STM-Core mit dem 
Board-Manager installiert.

Markus schrieb:
> Die Uhr hat geschlagen ..

Konstanten mit #define und dynamische Pufferallokierung.
Ulkig.

Markus schrieb:
> Was eventuell auch noch sein könnte: Irgendwo habe sie erwähnt, dass man
> den Arduino Zero/Due support installieren soll.

Das macht man um dem ARM-GCC zu bekommen, den bringen die STM32duinos 
aber auch mit (und aktueller)

Was ich nicht verstehe, ist daß es bei mir bei keinem Rechner klappt, ob 
komplett neu installiert oder meine beiden schon älteren 
Arduino-Installationen.
Überall die gleiche Reaktion.

>Konstanten mit #define und dynamische Pufferallokierung.
>Ulkig.

Einerseits könnte ich mich jetzt raus reden und sagen, die Uhr ist ja 
gar nicht von mir ( Ich habe sich koppiert und an den F7 angepasst ).

Andererseits: Was stört ich an "defines"

>Das macht man um dem ARM-GCC zu bekommen, den bringen die STM32duinos
>aber auch mit (und aktueller)
Das wundert mich, weil ich längere Zeit das F7 Board nicht benutzen 
konnte, bis die Leute vom STM32 Core endlich den m7 compiler ins Repo 
gepackt haben. Und ich hatte keine Lust wie Lothar oben, das ganze 
manuel hinzupfrimeln.

>Was ich nicht verstehe, ist daß es bei mir bei keinem Rechner klappt, ob
>komplett neu installiert oder meine beiden schon älteren
>Arduino-Installationen.
>Überall die gleiche Reaktion.

Irgendwas ist faul. Oben habe ich ja die IDEs 1.8.0 und 1.8.1 benutzt.
Da ich leider keine freie Windows Installation mehr habe, werde ich mir 
jetzt mal die 1.8.3 runter laden und schauen, ob die auf Ubuntu mit dem 
F7 geht.

Das Ergebnis der Neuinstallation von Arduino IDE 1.8.3 auf einem Ubuntu 
Rechner:

Installiert man den STM-Core, kann man das Blink example für das F7 
Board gleich kompilieren.
Aber: Installiert man den STM32GENERIC Core in das Hardwareverzeichnis, 
kann man das Board zwar im Menue auswählen, aber aus irgend welchen 
Gründen will er den alten Compiler verwenden, obwohl ja durch den 
STM-Core bewiesen ist, dass der neue Compiler da wäre:

 Generating function prototypes...
"/home/IchBins/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3 
-2014q1/bin/arm-none-eabi-g++"  -mcpu=cortex-m7 ..

error: unrecognized argument in option '-mcpu=cortex-m7'

Wo zum Donnerwetter setzt man den Pfad auf den richtigen Compiler? 
Irgendwie muss ich das bei den anderen System wohl gemacht und wieder 
vergessen haben ...

Ah, dieser Post bringt Abhilfe:
Autor: M. G. (looking)
>Hat geklappt. Nach der Installation des Arduino-Frameworks von STM
>musste ich allerdings erst noch den "Arduino Zero" per Boardmanager
>deinstallieren, damit dann die Version 6-2017-q1-update des
>arm-none-eabi-g++ verwendet wurde.

Auf dem Ubuntu Rechner war durch andere Arduino-IDEs auch der 
Arduino-Zero-Compiler installiert.

Fazit: Mit der 1.8.3 geht es auch ....

Das passt jetzt zwar nicht mehr zu ARDUINO, aber ein Test lohnt sich, 
habe ich am WE festgestellt. Das Board wird auch von mbed.org 
unterstützt. Arduino kastriert mir das Teil zu stark. Ich habe z.B. 
keine Möglichkeit gefunden 12Bit aus dem ADC zu kriegen. Eine bittere 
Pille von ST, die DACs sind nicht nutzbar ...

Lothar schrieb:
> Eine bittere Pille von ST, die DACs sind nicht nutzbar ...

Das ist ja schrecklich!

Da müsste man selbst Hand anlegen und drei Zeilen Code schreiben!

Welch Frevel, welch Ungemach!

>Das passt jetzt zwar nicht mehr zu ARDUINO, aber ein Test lohnt sich,
>habe ich am WE festgestellt. Das Board wird auch von mbed.org
>unterstützt. Arduino kastriert mir das Teil zu stark.

Embed ist super. Ich hab's vor einiger Zeit mal mit einem Nucleo-Board 
probiert und war erstaunt, dass die TTB noch schneller als beim Arduino 
ist.

Aber was ich überhaupt nicht leiden kann: Ein Online-Compiler. Ich will 
meine Software nicht in der Cloud haben.

>Ich habe z.B.
>keine Möglichkeit gefunden 12Bit aus dem ADC zu kriegen.
Witzigerweise ist ausgerechnet der letzte Commit im GENERIC-Repo

"add analogReadResolution"

https://www.arduino.cc/en/Reference/AnalogReadResolution

> Eine bittere
> Pille von ST, die DACs sind nicht nutzbar ..

Das hat mich auch schon geärgert. Man kann aber im Framework relativ 
Leicht HAL-Funktionen hinzufügen.
Zwei Beispiele finden sich in
.. examples/Discovery407VG/HAL/..

Dumpfbacke schrieb
>Lothar schrieb:
>> Eine bittere Pille von ST, die DACs sind nicht nutzbar ...
>Das ist ja schrecklich!
>Da müsste man selbst Hand anlegen und drei Zeilen Code schreiben!
>Welch Frevel, welch Ungemach!

Da können wir mal schauen, ob Dumpfbacke so was hinkriegt eine DAC 
anzusteuern.

Es ging mir eigentlich nicht darum, die DACs anzusprechen....
Die Pins (nur PA4,5) sind nicht herausgeführt. Vielleicht bin ich auch 
ein bisschen blind oder irgend eine Dumpfbacke muss mir erklären, wie 
ich einen BGA pimpe.

Markus schrieb:
> Aber was ich überhaupt nicht leiden kann: Ein Online-Compiler. Ich will
> meine Software nicht in der Cloud haben.

...geht mir genauso. Es gibt auch die Möglichkeit mbed lokal zu nutzen, 
habe ich aber auch noch nicht getestet.

Lothar schrieb:
> Eine bittere Pille von ST, die DACs sind nicht nutzbar ...

Lothar schrieb:
> Es ging mir eigentlich nicht darum, die DACs anzusprechen....

Ahhh ... schon klar:

Bittere Pillen die man nicht einnehmen muss sind besonders bitter.

Dumpfbacke schrieb:
> Bittere Pillen die man nicht einnehmen muss sind besonders bitter.

Und immernoch nicht kapiert was das Problem ist:

Lothar schrieb:
> Die Pins (nur PA4,5) sind nicht herausgeführt.

Aber erstmal alle beleidugen. Der Nick ist wirklich treffend

Vielleicht habe ich mich für Dumpfbacken unverständlich ausgedrückt.
Die Programmierung der DACs ist kein Problem (für mich).
Ich habe von Anfang an die PINs vermisst.
Nun nimm Deine Droge und geh keinem auf die Nerven.

Autor: Lothar (Gast)
>Es ging mir eigentlich nicht darum, die DACs anzusprechen....

Für was möchtest Du die DACs nutzen?
Vielleicht gibt es ja eine Umgehungsstrategie.
Schnelle PWM und RC-Tiefpass?

Markus schrieb:
> Autor: Lothar (Gast)
>>Es ging mir eigentlich nicht darum, die DACs anzusprechen....
>
> Für was möchtest Du die DACs nutzen?
> Vielleicht gibt es ja eine Umgehungsstrategie.
> Schnelle PWM und RC-Tiefpass?

Gah! Die DAC's sind die einfachste Peripherie der STM32. Die kann jeder 
ohne die Arduino-Library nutzen. Völlig bescheuert da einen 
Hardware-Workaround zu basteln.

1

 // Takte initialisieren

2

RCC->APB1ENR |= RCC_APB1ENR_DACEN;

3

RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN;

4

// Pin auf Analog stellen

5

GPIOA->MODER |= GPIO_MODER_MODER4_1 | GPIO_MODER_MODER4_0;

6

7

// DAC einschalten.

8

DAC1->CR = DAC_CR_EN1;

9

// Wert ausgeben (0-4095)

10

DAC1->DHR12R1 = 42;

PS: Der WM8994 Audio Codec auf dem Discovery enthält zwei DAC's und 
Class-D-Amps, und die sind sogar auf Stecker rausgeführt... Der ist 
allerdings wirklich nicht ganz einfach ans Laufen zu bringen.

>PS: Der WM8994 Audio Codec
Ja, ausgerechnet der fehlt auch noch im Arduino-Framework.
Ich habe mir schon den Treiber von hier
http://mikrocontroller.bplaced.net/wordpress/?page_id=5329
( stefanus? )
angeschaut. Der ist im Vergleich zu anderen übersichtlich programmiert.

Eigentlich muss man "nur" den Codec konfigurieren, I2S wird vom 
STM32GENERIC-Arduino Framework schon voll unterstützt ( incl. DMA ).

Aber ich dachte dann: zwei Tage ist man wahrscheinlich trotzdem 
unterwegs, bis das geht.

CM schrieb:
> Der ist im Vergleich zu anderen übersichtlich programmiert.

Oha, ich kenn nur noch den von ST selbst.

CM schrieb:
> Eigentlich muss man "nur" den Codec konfigurieren
Tja, das "nur" ist gut. Das Teil hat ziemlich viele 
Konfigurationsregister, und aus der Doku wird nicht immer so ganz klar 
was man wofür braucht... Die Initialisierungs Sequenz funktioniert 
überhaupt nicht, die kann man nur aus dem ST Beispiel klauen.

CM schrieb:
> Aber ich dachte dann: zwei Tage ist man wahrscheinlich trotzdem
> unterwegs, bis das geht.
Ich hab 4 gebraucht ;-)

I2S auf dem STM32 ist dagegen flugs eingerichtet auch ohne Library. Nur 
das benötigte Frame Format ist nicht so ganz klar...

Wenn ich das F746 disco anstecke, öffnet sich ein Explorer-Fenster.
Witzigerweise kann man dann einfache eine Binärdatei auf dieses Laufwerk 
schieben und das Board programmiert sich dann.

Das ist aber bei allen aktuellen Disco-Boards so. Der ST-Link kann das 
afair seit V2.0. Wird auch von der Arduino-IDE unterstützt.

Gerade gesehen:
Es gibt jetzt einen Nachtrag zur F7 installation:
https://danieleff.github.io/STM32GENERIC/

1.    Download the latest GNU ARM Embedded Toolchain
2.    Change compiler.path in platform.txt to point to that you 
downloaded.

Wahrscheinlich ist der Punkt 2 der Wichtige.

hiermit möchte ich mich für die wertvollen Tipps bedanken.
Vor allem für den Link vom Markus!

Dank Daniel Fekete's Dokumentation habe ich das 32F746 Disco unter 
Arduino problemlos ans Laufen gebracht.

Gruß
Thomas

Danke für die Mitteilung. Es freut mich, dass es bei Dir gut geklappt 
hat.
Das STM32F746 Discovery ist mein Lieblingsboard weil es ein großes 
Display hat und ordentlich schnell ist.
Das einzige was mir bezüglich Arduino Unterstützung noch fehlt, ist der 
Codec.

Markus, eine Frage:
bei Textausgaben fiel mir negativ auf dass die in den Beispielen das 
gesamte Display mit jeder Aktualisierung zunächst mit 
"tft.fillScreen(LTDC_BLACK)" neu schreiben, also erst komplett in 
Hintergrundfarbe und dann die gewünschten Zeichen.
Beim Voltmeter fällt das besonders auf....das Zucken stört schon 
irgendwie.
Kommentiert man das aus, entsteht mit jeder neuen Messung ein Pixelbrei 
wenn sich der A/D Wert ändert.

das kenne ich von anderen Zeichenausgaben so nicht.
Dort wird mit jedem neuen Zeichen an der Stelle wo es erscheinen soll 
ein ungenutztes Pixel automatisch in Hintergrundfarbe ausgegeben.

Eine Eigenart der Adafruit GFX Bibliothek???

Kann man das abändern?

EDIT:
ich lese mich gerade ins Arduino Adafruit GFX Library User Guide ein....
ich denke ich sehe schon was man da wie ändern muss.

http://henrysbench.capnfatz.com/henrys-bench/arduino-adafruit-gfx-library-user-guide/

>Eine Eigenart der Adafruit GFX Bibliothek???

Ja, das macht die Bibliothek. Mich hat das zwar auch immer schon 
gestört, ist aber wahrscheinlich eine Philosophiefrage: schreibt man den 
Text, werden einfach nur die neuen Pixel gesetzt, damit entsteht dann 
ein Zeichenmatsch, wenn da die alten Zeichen noch stehen.
Es hat aber auch einen Vorteil: man kann z.B. zuerst ein Rechteck 
beliebiger Größe und Farbe als Hintergrund zeichnen und dann die Schrift 
darüber legen.
Für das Update von Zahlen ist das dann immer lästig, weil es zum 
"flickern" führen kann.

Gerade entdeckt:
Jetzt gibt es ein Beispiel für's on-Board Ethernet.
https://github.com/danieleff/STM32GENERIC/blob/master/STM32/libraries/BoardExamples/examples/Discovery746NG/Ethernet/Ethernet.ino

hi
konnte mir jemand helfen
ich henge bei zweite punkt
Change compiler.path in platform.txt to point to that you downloaded.

wo wie was  ? ? ?

danke

> >PS: Der WM8994 Audio Codec
Hat es mittlerweile schon mal jemand geschafft, den AudioCodec auf dem 
Board in Betrieb zu nehmen?

Markus schrieb:
> Hat es mittlerweile schon mal jemand geschafft, den AudioCodec auf dem
> Board in Betrieb zu nehmen?

Ja, wie gesagt...

Dr. Sommer schrieb:
> Ich hab 4 [Tage] gebraucht ;-)

>Dr. Sommer schrieb:

>Ja, wie gesagt...
>> Ich hab 4 [Tage] gebraucht ;-)

Wenn Du Deinen Treiber ins Arduino-Framework einbindest, hat das den 
Vorteil, dass viele Leute sehr einfach Sound mit dem Board erzeugen 
können.

Wenn Du den Treiber closed Source hältst, hat das für Dich den Vorteil, 
dass nur Du Sound auf dem Board erzeugen kannst.

Bei so einer Ausdrucksweise hab ich richtig Lust meine knappe Freizeit 
dafür aufzuwenden... Außerdem gibt es auch schon diverse Treiber und 
Beispiele. Die kannst du auch gerne in Arduino einbinden.

Dr. Sommer (Gast)
>Bei so einer Ausdrucksweise hab ich richtig Lust meine knappe Freizeit
>dafür aufzuwenden...

So richtig schlecht scheint es um Deine Freizeit aber auch nicht 
bestellt:
>> Ich hab 4 [Tage] gebraucht ;-)

Markus schrieb:
> Ich hab 4 [Tage] gebraucht ;-)

Ja, Lebensumstände ändern sich.

Ja, bei mir auch. Das STM32F746 Disco ist ein sehr schönes Board. Es hat 
ein großes Display und allerlei nützlich Peripherie. Ich habe vor einer 
Weil angefangen, ein wenig damit zu spielen.
Von Zeit zu Zeit hohle ich es wieder mal aus dem Schrank und schaue, was 
es neues an Treibern gibt. Töne kann man damit auch erzeugen, wenn man 
direkt einen I2S-Wandler anschließt. Allerdings ist das natürlich ein 
wenig schade, weil auf dem Board ja schon ein Codec ist. Aber ein paar 
Tage in die Adaption eines Treibers für meine Spielereien zu stecken, 
ist mir dann doch auch zu viel.

Hier verwendet einer das Board als Soundkarte:
http://www.tjaekel.com/DiscoveryF7Audio/index.html

Mal sehen, was wir alles für den Codec brauchen.

1. das Datenblatt:
http://www.st.com/content/ccc/resource/technical/document/user_manual/f0/14/c1/b9/95/6d/40/4d/DM00190424.pdf/files/DM00190424.pdf/jcr:content/translations/en.DM00190424.pdf

Enorm, wie aufwendig der Codec ist ...

2. Die Peripheriebelegung auf dem STM32F7 Disco

1

#define LCD_I2C_ADDRESS                  ((uint16_t)0x70)

2

#define CAMERA_I2C_ADDRESS               ((uint16_t)0x60)

3

#define AUDIO_I2C_ADDRESS                ((uint16_t)0x34)

4

#define EEPROM_I2C_ADDRESS_A01           ((uint16_t)0xA0)

5

#define EEPROM_I2C_ADDRESS_A02           ((uint16_t)0xA6)

6

#define TS_I2C_ADDRESS ((uint16_t)0x70)

3. Den Treiber mit Beispielconfigurationen der Codecregister:
https://github.com/jaz303/stm32f746g-discovery-gcc/blob/master/lib/Drivers/BSP/Components/wm8994/wm8994.c

Markus schrieb:
> Enorm, wie aufwendig der Codec ist ...

Der ist für Smartphones und so... Frage Nr. 1 ist welche Art von Betrieb 
man überhaupt nutzen will. Nur DAC+ADC via I2S? Analoges und/oder 
digitales Durchleiten von Eingang zu Ausgang? DSP-Funktionen, 
Verstärkung, Anti-Pop-Funktion? Welche Kanal-Zuordnung der Ein-und 
Ausgänge (analoge vs digitale Mikrofone, Line-In/Out, 
Kopfhörer-Verstärker, Speaker Ausgänge,...)? Je nach Platine und 
Codec<->uC Konstellation hat man andere Möglichkeiten. Man müsste der 
Bibliothek mitteilen welche SAI und I2C Peripherie man nutzen will. Das 
alles über ein API dem Nutzer zur Verfügung zu stellen dürfte ziemlich 
aufwendig werden, und dann auch noch kompliziert zu nutzen, und damit 
nicht sehr Arduino-konform. Für das Setzen der Register haben die ja 
sogar eine eigene GUI-Software, die ist leider nur begrenzt hilfreich. 
Man muss erstmal festlegen was der Nutzer damit tun können soll...

> Das alles über ein API dem Nutzer zur Verfügung zu stellen dürfte ziemlich
> aufwendig werden, und dann auch noch kompliziert zu nutzen, und damit
> nicht sehr Arduino-konform.

Da sehe ich ein wenig das generelle Problem der heutigen Technik: zu 
viele Möglichkeiten anstatt sich auf wenige zu konzentrieren. Das führt 
in der Software immer zur Komplexität, Aufwand, falschen Einstellungen 
und Fehlersuche. Ich beobachte das seit Jahren und angefangen hat es mit 
den Videorekordern, die keiner mehr einstellen konnte, weil durch das 
Aufkommen der Mikroprozessoren die Menütiefe zu groß war und da 
Marketing der Meinung, dass man dem Kunden doch noch dieses, jenes und 
das bieten müsse, weil er sonst das Produkt nicht kauft.

Ich denke, es gibt langsam einen Trend dagegen ... Retro .. zurück zu 
Einfachheit und dem was man braucht. Und Arduino scheint mir ein Teil 
dieses Trends zu sein.

Deshalb fange ich meisten mit der Frage an, was brauche ich eigentlich? 
Und in dem Fall wird es wohl auch das sein, was die meisten 
Arduino-Nutzer erst mal brauchen: Die Möglichkeit, am Line-Out-Ausgang 
einen Ton zu erzeugen.
Selbst die Lautstärkeeinstellung ist nachrangig, da man diese einfach 
über eine Skalierung der Werte, die man an die I2S-Schnittstelle 
schreibt.

Die I2S-Schnittstelle des STM32Generic Frameworks funktioniert, ebenso 
die I2C-Schnittstelle. Was man also tun muss, ist die Einstellungen für 
das Durchrouten der I2S-Schnittstelle auf den Lineout-Ausgang via 
I2C-Schnittstelle in den Codec zu schreiben.

Markus schrieb:
> Da sehe ich ein wenig das generelle Problem der heutigen Technik: zu
> viele Möglichkeiten anstatt sich auf wenige zu konzentrieren

Dafür erlaubt wo ein Chip halt die Verwendung in allen möglichen Geräten 
und Konstellationen, was ihn billiger macht als zig verschiedene Spezial 
IC's. Ein selbstfahrendes Auto ist auch nicht mit minimaler Technik 
machbar...

Markus schrieb:
> angefangen hat es mit den Videorekordern
Das war nur schlechtes UX-Design. Wenn man das gut macht, kann man auch 
komplexe Produkte bedienbar machen. Apple z.B. hat das gut raus. Nur auf 
Entwickler wird noch nicht überall so viel Rücksicht genommen...

Markus schrieb:
> Und Arduino scheint mir ein Teil dieses Trends zu sein.
Aber Arduino versteckt die Komplexität lediglich. Es geht hier auch der 
Trend weg vom einfachen AVR zum komplexen ARM.

Markus schrieb:
> Die Möglichkeit, am Line-Out-Ausgang einen Ton zu erzeugen.

Das F7-Discovery hat aber gar keinen Line-Out; das ist ein 
Kopfhörer-Ausgang. Man muss also den eingebauten Class-D-Verstärker 
nutzen.

Dr.Sommer schrieb:
>Das F7-Discovery hat aber gar keinen Line-Out; das ist ein
>Kopfhörer-Ausgang. Man muss also den eingebauten Class-D-Verstärker
>nutzen.

Da das Board so schön eingefärbte Klinkebuchsen wie ein PC hat, bin ich 
einfach davon ausgegangen, dass man dort ganz normal seine aktiven 
Audioboxen ( ak "Brüllwürfel ) anschließen kann.
Im Manual für das STM32F7 Disco Board findet sich folgendes:

>>8.8 Audio An audio codec WM8994ECS/R from CIRRUS with 4 DACs and 2 ADCs is
>>connected to the SAI interface of the STM32F746NGH6 microcontroller.

>>• The analog line input is connected to the ADC of WM8994ECS/R through the blue 
audio jack CN11.

>>• The analog line output is connected to the DAC of WM8994ECS/R via the*green 
audio jack* CN10.

>>• Two external speakers can be connected to WM8994ECS/R via JP3 for rightspeaker 
and JP4 for left speaker

Dr. Sommer schrieb:
>Markus schrieb:
>> Und Arduino scheint mir ein Teil dieses Trends zu sein.
>Aber Arduino versteckt die Komplexität lediglich. Es geht hier auch der
>Trend weg vom einfachen AVR zum komplexen ARM.

Um auf mit Matlab auf dem PC ein weises Rauschen hörbar zu machen, 
verwende  ich folgende Zeilen:

1

sig=randn(1,10000);

2

sound(sig)

Wie man die Register des jeweiligen Soundchips im PC einstellen muss, 
hat mich dabei noch nie interessiert. Deshalb bin ich der Meinung, dass 
ein Arduinotreiber das leisten soll.

>Markus schrieb:
>> angefangen hat es mit den Videorekordern
>Das war nur schlechtes UX-Design. Wenn man das gut macht, kann man auch
>komplexe Produkte bedienbar machen. Apple z.B. hat das gut raus. Nur auf
>Entwickler wird noch nicht überall so viel Rücksicht genommen...

Das liegt daran, das Apple per se den Fokus bei der Entwicklung auf die 
Benutzbarkeit legt. Es wird immer unter der Fragestellung entwickelt 
"Ist das für den Käufer benutzbar? Ist das einfach? Ist das angenehm zu 
bedienen?"

Mir scheint, das die meisten Microcontroller HALs weit weg von dieser 
Philosophie entwickelt wird, den deren Umsetzung kostet Zeit.

Markus schrieb:
> Im Manual für das STM32F7 Disco Board findet sich folgendes:

ST weiß offenbar selbst nicht was sie da gebaut haben. Auf S. 32 im 
Schaltplan sieht man eindeutig, dass die Buchse am "HPOUT" hängt 
(HP=HeadPhone) und der Line Out Ausgang vom IC offen ist.

Markus schrieb:
> Deshalb bin ich der Meinung, dass ein Arduinotreiber das leisten soll.

Es gibt einen Linux-Treiber für den Codec direkt vom Hersteller, der 
leistet das. Wenn man natürlich den Linux-Mainstream ignoriert...

Markus schrieb:
> Mir scheint, das die meisten Microcontroller HALs weit weg von dieser
> Philosophie entwickelt wird, den deren Umsetzung kostet Zeit.

Ja. Die meisten MCU-Hersteller sehen sich selbst noch zu stark als 
Halbleiter-Fertiger. Die Software ist für die nur Beiwerk. Wenn man eine 
Diode verkauft reicht es ein paar Zahlen dazu anzugeben. Das würden die 
bei MCU's auch gerne so machen. Dazu kommt dass die ganze 
MCU-Entwicklung sich um C dreht (Arduino ist C++!) womit man keine 
besonders schönen APIs machen kann.
Außerdem haben die Hersteller kein Interesse an echten HAL's, welche die 
tollen Features der Hardware wegabstrahieren. Solche HAL's gibt es in 
Form von z.B. ChibiOS. Das was ST als HAL bezeichnet ist keine HAL 
sondern nur ein Zugriffs-Layer. Da dieser alle Features der Hardware 
abbilden soll wird er relativ kompliziert.

PS: mbed.org hat auch einen Treiber für den Codec. Damit sind doch alle 
Wünsche erfüllt, es muss ja nicht unbedingt Arduino sein.

>Markus schrieb:
>> Im Manual für das STM32F7 Disco Board findet sich folgendes:

>ST weiß offenbar selbst nicht was sie da gebaut haben. Auf S. 32 im
>Schaltplan sieht man eindeutig, dass die Buchse am "HPOUT" hängt
>(HP=HeadPhone) und der Line Out Ausgang vom IC offen ist.

Vielleicht macht das sogar Sinn, wenn man den Headphone Anschluss auch 
als LineOut verwenden kann. Der Headphone Anschluss hat einen Verstärker 
für die niederohmigen Orhörer. Leider finde ich im Datenblatt keine 
Spannungspegel, aber ich nehme mal an, man kann es ohne größere Probleme 
als LineOut verwenden.

Markus schrieb:
> Vielleicht macht das sogar Sinn, wenn man den Headphone Anschluss auch
> als LineOut verwenden kann.

Äh ja, das kann man natürlich wie bei jedem anderen Kopfhörer-Ausgang 
auch. Habe ich auch schon ausprobiert aber vergessen zu schreiben.