Forum: Mikrocontroller und Digitale Elektronik STM32H7-Disco erster Test


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 Markus H. (dasrotemopped)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

da ich gerne was mit TFT und STM32 mache aber die STmicro Disco Boards 
in Sachen Display meisst zu kleine TFTs haben musste eine eigene Lösung 
her.
Die Specs:
STM32H743IIT mit 480Mhz
128 MB SDRAM, 2x 512MBit
128 MB QSPI Flash
7" TFT 800x480 24bit RGB
VGA Port 24bit RGB
Batteriebetrieb mit 4x 18650 LiIon incl. Ladeport mit Balancing 
Anschluss
USB Uart Anschluss
ESP8266 Port
MicroSD Kartenslot
FDCAN Bus
USB2.0 Port
C64 Joystick Port digital/analog
alternativ 8 User Tasten an der Frontseite.
SPI zu 32bit parallel Wandler
2x 16Bit R2R DAC + Impedanzwandler

Erste Tests sind sehr erfolgversprechend für die Hardware Version 1.0
Jetzt muss nach getaner Hardware die Software geschrieben werden.
Warum dieses Board ? Einfach nur darum !

Meinungen ?

Gruß,
dasrotemopped.

von STK500-Besitzer (Gast)


Lesenswert?

Markus H. schrieb:
> Meinungen ?

Das Projekte-Forum hast du sauber verfehlt.

von Jo Mei (Gast)


Lesenswert?

Markus H. schrieb:
> Meinungen ?

Zeit wird's dass du endlich mal einen MS-DOS-Rechner drauf emulierst.

von dasrotemopped (Gast)


Lesenswert?

>Zeit wird's dass du endlich mal einen MS-DOS-Rechner drauf emulierst.

Chocolate Doom gibts schon nativ für den STM32

von Ralph S. (jjflash)


Lesenswert?

Markus H. schrieb:
> Warum dieses Board ? Einfach nur darum !

Okay, das ist natürlich ein absolut unschlagbares Argument (und 
natürlich das Argument für Hobby schlechthin).

Jo Mei schrieb:
> Zeit wird's dass du endlich mal einen MS-DOS-Rechner drauf emulierst.

Ist natürlich reizvoll (und C/PM ist es auch). Aber das gibts alles 
wirklich schon, aber wie wäre es mit einer "sauberen" Emulation.

Hierbei: Aus meiner Sicht "krankt" das immer auch daran, dass man eine 
handelsübliche Tastatur daran anschließt und es dann nicht mehr mobil 
ist. Vllt. sollte hier mal jemand eine nachbaubare Tastatur im Stile 
eines alten Blackberry basteln?

Das Board selbst was du da gebaut hast ist schon "massiv" und hat dann 
wirklich einen teuren Controller und ein teueres Display.

Machst du dann daraus eine Retro-Konsole im Stile von NES oder 
SEGA-Drive?

Mich würde am meisten dein Ladecontroller und das Balancing 
interessieren, die Laufzeit der Akkus auch.

von Bachus (Gast)


Lesenswert?

arkus H. schrieb:

> Meinungen ?

11. Du sollst nicht plenken.

von dasrotemopped (Gast)


Lesenswert?

>Das Board selbst was du da gebaut hast ist schon "massiv"
Es sollte halt von den Spezifikationen her keine Grenzen setzen, da es 
nicht für einen bestimmten Zweck gemacht ist. Die Grundfunktion ist 
natürlich Grafik mit Rechenpower und kein Speicherlimit so wie es auf 
vielen Disco/Eval Boards der Fall ist. Sollte sich später ein bestimmtes 
Einsatzfeld ergeben kann ich ja ein angepasstes Board machen.

>teuren Controller und ein teueres Display.
Platine mit Bauteilen liegt bei ca 200 Euro Hardwarekosten.

Zum Bestücken hat ein Ersa Analog 60 mit Hohlkehlenspitze und ein Ersa 
Handlötkolben gereicht. Lupe und gutes Flußmittel sind natürlich auch 
nötig. Man muss schon einen vollen Tag Arbeit einrechnen für den 
Zusammenbau.

>dein Ladecontroller und das Balancing interessieren
ein SkyRC (2. Bild links oben) kann an das Board angeschlossen werden.
Die Elektronik auf das Board integrieren habe ich auf Version 2.0 
verschoben.

>Retro-Konsole, Emulation
ist eine mögliche Verwendung des Boards

Ich habe eher native Anwendungen im Sinn um die gute Rechenleistung 
nicht mit Emulationsoverhead zu verheizen. Wer denn Interesse an einer 
Retro Konsole hat kann das natürlich gerne machen, mir fehlen da die 
Vorkenntnisse.

Das Hardwaredesign ist von mir auf mobilen Betrieb ( Batterie ) 
ausgelegt, Die Bedienelemente sind wie bei einer Handheld Konsole 
angeordnet. Um den ESP8266 Port sind noch ein paar GPIOs frei so das man 
noch andere Hardware wie DCF77, GPS oder LTE nachflanschen kann.

Auf der Softwareseite benutze ich CubeMX mit einigen selbst 
programmierten Erweiterungen, besonders für FATFS und Grafik. Der 
Einstieg von weiteren Interessierten mit STM32 Vorkenntnissen sollte 
leicht möglich sein.

Ich denke die größte Hürde ist für die meisten der Preis ( dafür bekommt 
man ja schon eine Switch als Retro Konsole). Aber dafür wäre die 
Hardware frei modifizierbar und dokumentiert. Wer trotzdem Interesse hat 
kann sich ja melden.

Gruß,
dasrotemopped.

von Johannes S. (Gast)


Lesenswert?

Respekt, tolle Arbeit. Vor allem in Zeiten wo ein Projekt hier und in 
zahllosen Blogs das Zusammenstoppeln von China Modulen auf dem 
Breadboard ist.
Für die Software würde ich eher mbed-os empfehlen, der STM32H743 ist auf 
einem Nucleo und wird direkt unterstütz.
Und die lvGL Grafiklib, die ist einfach adaptiert und kann schon eine 
Menge:
https://littlevgl.com/

von dasrotemopped (Gast)


Lesenswert?

>Respekt, tolle Arbeit.
Vielen Dank !

>das Zusammenstoppeln von China Modulen auf dem Breadboard
Ja z.B. bei der Ben Heck Show waren viele Projekte mit viel Drahtverhau 
und Heißkleber, das fand ich auch nicht immer gut. Auch die 
Softwareentwicklung beschränkt sich oft auf Portierungen und Emulator. 
Das habe ich nicht vor.

>würde ich eher mbed-os empfehlen
ich verwende derzeit kein OS, tendiere aber in Zukunft zu RTOS, da in 
CubeMX enthalten. Da das Projekt aber derzeit ohne OS auskommt ist das 
Zukunftsmusik, da ich erst mal keine Zeit investieren will mich in 
irgend einem OS einzuarbeiten. Die Hardware nahen Sachen beschäftigen 
mich schon genug.

> die lvGL Grafiklib
es gibt diverse möglichen Grafik libs, aber die sind alle GUI 
orientiert. Für eine Spieleengine aber sind alle nicht ausgelegt. Ebenso 
schreckt mich die Konfigurationsorgie ohne klare Tutorials für die 
Zielplattform dazu ab.

Gruß,
dasrotemopped.

von Johannes S. (Gast)


Lesenswert?

dasrotemopped schrieb:
> ich verwende derzeit kein OS, tendiere aber in Zukunft zu RTOS, da in
> CubeMX enthalten.

du meinst vermutlich FreeRTOS. In mbed-os ist auch ein RTOS, RTX von 
Keil/Arm. Und die Komponenten sind schon Threadsafe wenn nötig, beim 
nackten FreeRTOS muss man da selber drauf achten. Es gab da auch 
kostenpflichtige Zusätze, ich weiss nicht ob das nach der Amazon 
Übernahme noch so angeboten wird.

> Ebenso
> schreckt mich die Konfigurationsorgie ohne klare Tutorials für die
> Zielplattform dazu ab.

ja, das ist hauptsächlich GUI. Wenn man die Aktualisierung abschaltet 
hat man aber selber die Kontrolle über den Bildschirm, das kann man also 
kombinieren.
lvGL ist gut dokumentiert und der Chefentwickler macht auch noch Support 
im Forum.
Es ist nicht viel zu konfigurieren für den Anfang, eigentlich nur das 
Pixelformat. Für den Treiber reicht zum Start eine Funktion die ein 
DrawPixel(x, y, Farbe) kann. Beispiele für den STM DMA2D gibt es auch, 
incl. Nutzung der GPU und Alpha Blending.

von diepoetteringdie (Gast)


Lesenswert?

> C/PM

Es ist immer noch CP/M.

von dasrotemopped (Gast)


Lesenswert?

>lvGL ist gut dokumentiert
schon selbst verwendet ?

> mbed-os
ebenfalls selbst verwendet ?

Wenn ja, Beisspiele ?

Gruß,
dasrotemopped.

von Markus H. (dasrotemopped)


Angehängte Dateien:

Lesenswert?

thomas100 fragt:

>Hast du da einen Schaltplan?
Ja, siehe PDF

>Welches Display nutzt du?
Innolux AT070TN,
AT080TN und AT090TN sollten ohne große Änderung auch gehen.

Gruß,
dasrotemopped.

von Johannes S. (Gast)


Lesenswert?

dasrotemopped schrieb:
> ebenfalls selbst verwendet ?
>
> Wenn ja, Beisspiele ?

Ja, beides schon benutzt.
Kann ich die Tage gerne helfen.


Hier ist ein Anfang:
https://os.mbed.com/docs/mbed-os/v5.14/quick-start/offline-with-mbed-cli.html

Und ein Blinky:

https://github.com/ARMmbed/mbed-os-example-blinky/blob/master/README.md

Das für das Nucleo H7 übersetzen und laden. Wenn es läuft ist es 
einfach.

von dasrotemopped (Gast)


Lesenswert?

>Ja, beides schon benutzt. Kann ich die Tage gerne helfen.
Die Grafik Lib+OS ist ja nur ein kleiner Teil der nötigen Arbeit.
Und ohne einem eigenen Board bleibt die Hilfe ja sehr theoretisch.
Kann ich aber verstehen, das Board ist kein Schnäppchen.
Danke aber für das Hilfsangebot.

>Hier ist ein Anfang:
>Und ein Blinky:

Klingt erst mal einfach, aber wie verbinde ich das Ganze mit CubeMX, da 
ich ja damit die gesamte Initialisierung der Hardware mache.
Ich denke ich bleibe erst mal auf dem CubeMX Pfad.
Bis jetzt hat meine Methode mich recht weit gebracht.

Kann freeRTOS mit CubeMX immer noch einbinden wenn es mir sinnvoll 
erscheint.

Gruß,
dasrotemopped.

PS: das Board zieht derzeit übrigens 0,35A @ 14,8V, gemessen am 
Sicherungshalter. Mit den 2,6Ah Akkus kann es also 7,5 Stunden laufen.

von Johannes S. (Gast)


Lesenswert?

dasrotemopped schrieb:
> Klingt erst mal einfach, aber wie verbinde ich das Ganze mit CubeMX, da
> ich ja damit die gesamte Initialisierung der Hardware mache.

das Init macht alles das mbed-os, das 'kennt' die CPU und die nötigen 
inits.
Mbed verwendet für die STM Targets selber die HAL, dadurch kann man 
einfach die HAL Funktionen aufrufen. Für Komponenten die das OS nicht 
unterstützt lässt sich auch CubeMX generierter Code verwenden.
Deshalb wäre ein Test mit dem Blinky ein Start, wenn das geht ist sind 
große Teile der Peripherie schon zu nutzen. Wenn das zusätzliche Ram 
auch für Code genutzt werden soll muss ein custom_target machen um ein 
eigenes Linkerscript einzubringen.

von Thomas W. (thomas100)


Lesenswert?

Markus H. schrieb:
> Ja, siehe PDF

Super. Vielen Dank dafür.
Kannst du mir die Altium Files zukommen lassen?

Schöne Weihnachten an alle!
Vg Thomas

von Pork (Gast)


Lesenswert?

Markus H. schrieb:
> thomas100 fragt:
>
> Hast du da einen Schaltplan?
>
> Ja, siehe PDF
>
> Welches Display nutzt du?
>
> Innolux AT070TN, AT080TN und AT090TN sollten ohne große Änderung auch
> gehen.
>
> Gruß,
> dasrotemopped.

Poste lieber mal deine Leiterplattendaten!

von dasrotemopped (Gast)


Lesenswert?

ich habe noch 4 unbestückte Platinen und kann die Bestückungsdaten + BOM 
mit Lieferanten anbieten.
PN bei Interesse.

Das CubeMX Projekt gibt es natürlich auch dazu mit dem aktuellen 
Entwicklungsstand.

Gebe allerdings noch keine Garantie auf den gesamten Funktionsumfang, da 
ich noch keine Zeit hatte, die Firmware weiterzuentwickeln und die 
Hardware zu testen.

die D-Sub9 Buchse für den Gameport muss noch weiter an die Platinenkante 
verschoben werden damit es 100% passt.

Gruß,
dasrotemopped.

von Nils (Gast)


Lesenswert?

Moin.
Saubere Arbeit ! Kompliment !

Eine Frage ( Keine Kritik) : Warum hast du den Audio-D/A Wandler diskret 
aufgebaut ? Der frist ja erheblich LP-Fläche.

von dasrotemopped (Gast)


Lesenswert?

1. ist wegen dem Display genug Platz übrig
2. am uC war nur noch ein SPI Bus frei, kein I2S
3. die externen Audio Controller mit I2S benötigen meist noch I2C zur 
Konfiguration und sind für reine Audio Ausgabe überdimensioniert
4. die Audio Funktion diskret aufzubauen ist auch etwas flexibler

Gruß,

dasrotemopped.

von Nils (Gast)


Lesenswert?

Hi.
Mir kam beim Anschauen des Schaltplans spontan ein D/A Wandler mit SPI 
von Microchip oder Analog in den Sinn.
Das ist aber mehr meiner Faulheit geschuldet weniger Bauteile bestücken 
zu müssen. :o)

von Stefan F. (Gast)


Lesenswert?

Johannes S. schrieb:
> Respekt, tolle Arbeit.

Ja, finde ich auch.

> Vor allem in Zeiten wo ein Projekt hier und in
> zahllosen Blogs das Zusammenstoppeln von China Modulen auf dem
> Breadboard ist.

Ich lese heraus, dass du "Zusammenstoppeln" nicht so gut findest.

> Für die Software würde ich eher mbed-os empfehlen

Würde dieses mbed nicht auf "Zusammenstoppeln" von Bibliotheken hinaus 
laufen? Das war doch der Hauptzweck von mbed, oder hat sich das 
inzwischen geändert?

von Johannes S. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Ich lese heraus, dass du "Zusammenstoppeln" nicht so gut findest.

zum Testen mache ich das auch, Platinen mache ich auch aber in der Größe 
noch nicht. Bei so einem Brett sitzt man schon ein paar Stündchen dran.

> Das war doch der Hauptzweck von mbed, oder hat sich das
> inzwischen geändert?

Das hat sich zu einem sehr seriösen OS entwickelt, da wurde und wird 
viel von ARM reininvestiert, siehe auch die Case Studies auf der 
Homepage.
Aber das war nur ein Angebot, möchte den Thread damit nicht entführen.

von dasrotemopped (Gast)


Lesenswert?

>Mir kam beim Anschauen des Schaltplans spontan ein D/A Wandler
>mit SPI von Microchip oder Analog in den Sinn.
welcher zum Beispiel ? Hast du den schon selbst verwendet ?

Gruß,
dasrotemopped.

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


Lesenswert?

16Bit mit einem R2R Netzwerk sind durchaus sportlich.
Durch dein 32Bit DRAM Interface ist I2S wohl zugebaut.
Da ist jetzt die Frage ob der STM dadurch wirklich schneller wird wegen 
den Caches.

Ich hab sowas ähnliches vor, nämlich eine Universal UI Platine für meine 
Geräte.
Da habe ich nur ein 16Bit DRAM Interface vorgesehen und da ist dann noch 
viel  frei an anderen IOs.
(Natürlich nehm ich auch den im LQFP208, schade, dass der H/ dualcore 
nur BGA hat).

von Datargnan (Gast)


Lesenswert?

Mw E. schrieb:
> STM dadurch wirklich schneller wird wegen
> den Caches.

Auch, aber sogar eher wegen den Bussen... der H7 hat mehrere Ebenen von 
Bussen intern und daher ist der direkte Zugriff auf die Peripherie etwas 
langsamer als z.B. noch beim F7. Dafür geht große Datenmengen hin und 
herschieben aber schneller...

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


Lesenswert?

@Datargnan:
Um das auszunutzen müssteste den SDRAM aber mit 64Bit anbinden ;)
Der großteil der Zugriffe sollte nicht langsamer sein, der M7 Kern hat 
nicht nur den "AXIM", sondern auch den "AHBP" Busport.
Dieser geht direkt an die 32Bit AHB Bus Matrix, also wie mans von den 
F1-F7 her schon kennt.
Nur der Zugriff auf AHB4/APB4 geht immer durch 2 Matritzen, das dauert 
dann etwas länger.
"Dedicated low-latency AHB-Lite peripheral bus (AHBP) to connect to 
peripherals."

von Nils (Gast)


Lesenswert?

dasrotemopped schrieb:
>>Mir kam beim Anschauen des Schaltplans spontan ein D/A Wandler
>>mit SPI von Microchip oder Analog in den Sinn.
> welcher zum Beispiel ? Hast du den schon selbst verwendet ?
>
> Gruß,
> dasrotemopped.

Moin.
Spontan sind mir da z.B. der LTC1655(16Bit), DAC8551IDGKT (16) sowie der 
MCP4921 (12Bit) eingefallen. Da gibt es verschiedenste auf dem Markt.
Das sind keine ausgewiesenen Audio-DACs aber du willst, vermute ich mal, 
keinen HiFi Hi-End Dolby-Sourround damit erzeugen!?

Nein, verwendet habe die noch nicht.

von Datargnan (Gast)


Lesenswert?

Mw E. schrieb:
> Nur der Zugriff auf AHB4/APB4 geht immer durch 2 Matritzen, das dauert
> dann etwas länger.


Rate mal wo beim H7 die I/O Ports angebunden sind :-P
Die sind tatsächlich deutlich langsamer beim direkt in Software drauf 
zugreifen. Aber bei Peripherie wie SPI wird das eher nicht auffallen, 
daher für die meisten Anwendungen unkritisch.

von dasrotemopped (Gast)


Lesenswert?

>>Hast du den schon selbst verwendet ?
>Nein, verwendet habe die noch nicht.
Schade.

>ob der STM dadurch wirklich schneller wird wegen den Caches.
Der Sinn von 32bit SDRAM ist der LTDC.
fast alle Eval Boards von ST haben nur 16 bit SDRAM.
Für den LTDC ist der Cache nicht verfügbar, da der Cache nur für die CPU 
sichtbar ist. Das macht auch Probleme bei DMA Operationen.
Der stm32f4@180MHz+90MHzSDRAM ist bei Grafikoperationen per DMA nicht 
durch die Rechenleistung begrenzt:
https://www.youtube.com/watch?v=miGGfDeDFWU
der STM32F7@200MHz+100MHzSDRAM ist nur unbedeutend schneller bei 
ebenfalls 16 bit SDRAM
https://www.youtube.com/watch?v=bcilZYgYLjk
Mein STM32H7@480MHz+160MHzSDRAM Board wird bei Grafik 3x schneller weil 
das SDRAM schneller ist ( Takt + breiterem Bus).

ST hat das in diversen AppNotes zum LTDC episch ausdiskutiert.
Leider ist das STM32F769i-Disco das einzige Board mit 32bit SDRAM 
allerdings ist der LTDC durch einen DSI mit Closed source HDMI 
Controller blockiert.
Da musste ich halt ein eigenes Board machen.

>Bei so einem Brett sitzt man schon ein paar Stündchen dran.
Hardware ist die kleine Baustelle, Software ist die große.
Aber jeder macht lieber seine eigene Hardware und dann bleibt nicht 
genug
Zeit für die Software. Darum lege ich auch den Schaltplan offen damit 
jeder mit programmieren kann. Aber bis jetzt sind selbst 4 verfügbare 
Platinen noch  mehr als genug Vorrat für Monate.

Gruß,
dasrotemopped.

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


Lesenswert?

dasrotemopped schrieb:
> Der Sinn von 32bit SDRAM ist der LTDC.
> fast alle Eval Boards von ST haben nur 16 bit SDRAM.
> Für den LTDC ist der Cache nicht verfügbar, da der Cache nur für die CPU
> sichtbar ist. Das macht auch Probleme bei DMA Operationen.

Ja, der LTDC ist ein eigener Busmaster mit FIFO.
Da wollt ich eh ersteinmal experimentieren mit einem F429 Disocovery ob 
1024x800 gehen mit Ausnutzung der Bursts des LTDC DMA (so lang wie die 
DRAM Bursts).
Immer schön ein großen Block aus dem DRAM lesen, damit die RowActive, 
Precharge und CL Zeiten nicht so nerven.
Aber das haste alles schon so gemacht nehm ich mal an?

Datargnan schrieb:
> Rate mal wo beim H7 die I/O Ports angebunden sind :-P
> Die sind tatsächlich deutlich langsamer beim direkt in Software drauf
> zugreifen. Aber bei Peripherie wie SPI wird das eher nicht auffallen,
> daher für die meisten Anwendungen unkritisch.

Zum Glück wohnt direkt daneben der BDMA mit SRAM
Wer also shcnell auf den GPIO trommeln will, der packt da Bitmuster rein 
und lässt den BDMA auf die GPIO los.

von dasrotemopped (Gast)


Lesenswert?

>experimentieren mit einem F429 Disocovery ob 1024x800 gehen
wie im Video zu dem Board zu sehen geht 1280x720@8bit@60Hz

>Aber das haste alles schon so gemacht nehm ich mal an?
Die Burstreads nutzen die nutzbare Speicherbandbreite optimal.
Aber mit 16bit SDRAM ist die Auflösung das absolute obere Limit.
Darum muss auch 32bit SDRAM her um die Farbtiefe zu erhöhen.

Noch nicht verwendet habe ich den DMA2D, der könnte die CPU noch 
entlasten.
Der STM32H7 hat noch einen MDMA zum Abarbeiten von Display Listen, da 
muss ich mich aber erst einarbeiten.

Gruß,
dasrotemopped.

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? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.