Announcement: there is an English version of this forum on 
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.
Angehängte Dateien:
-
STM32H7-Disco_full.JPG
500 KB -
STM32H7-Disco_Back.JPG
240 KB -
STM32H7-Disco_Front.JPG
190 KB
Markus H. schrieb: > Meinungen ? Zeit wird's dass du endlich mal einen MS-DOS-Rechner drauf emulierst.
>Zeit wird's dass du endlich mal einen MS-DOS-Rechner drauf emulierst. Chocolate Doom gibts schon nativ für den STM32
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.
>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.
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/
>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.
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.
>lvGL ist gut dokumentiert schon selbst verwendet ? > mbed-os ebenfalls selbst verwendet ? Wenn ja, Beisspiele ? Gruß, dasrotemopped.
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.
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.
>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.
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.
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
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!
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.
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.
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.
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)
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?
:
Bearbeitet durch User
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.
>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.
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).
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...
@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."
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.
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.
>>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.
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.
>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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.