Nachdem ich so meine Hard- und Software sortiere, möchte ich hier meine "Spielekonsole" (zumindest soll es mal eine werden) veröffentlichen. Für andere Controller habe 5 der insgesamt 7 Spiele schon veröffentlicht, mein Ziel war und ist es immer noch, alle Spiele auf einem Controller zu vereinigen, und hier soll es ein STM32F4 sein (weil es den mit viel Flash-Speicher gibt). Auslagern auf eine SD-Card und Spiel aus dem RAM laufen lassen wäre zwar auch eine Option, braucht es aber zumindest noch nicht. die 7 Spiele benötigen derzeit 152 kByte. Über den Code nicht wundern (speziell beim Three A Color): Das Spiel hatte ich zum ersten mal 1992 für MCGA 320x200 / 256 Farben geschrieben und viele (wirklich viele) Leute haben das dann anstelle von Tetris oder Klax gespielt (und grunsätzlich ist das eine Kombination aus beiden). Der Code war damals noch unter Turbo-Pascal und jetzt habe ich, nachdem ich den alten Code wieder gefunden habe, 1 zu 1 nach C portiert und die Grafik auf das kleine Display angepasst. Also nicht schimpfen, ich weiß dass das "besser / schöner" geht, aber: Never touch a running system ... und damals hatte ich lange "gefummelt", bis das vom Timing her gut spielbar war. Grundsätzlich habe ich die Software auf einem Nucleo F446, F401 ... einem schwarzen Board mit F407, einer Blackpill mit F401 und auf meiner eigenen Platine mit STM32F402 (ja, den gibt es wirklich, ist scheinbar für den chinesischen Markt only gemacht) laufen lassen und es gab keinen Unterschied. Ich werde mir wohl eine neue PCB routen, weil ich festgestellt habe, dass 4 Tasten (speziell beim MineSweeper) zu wenig sind: Eine Auswahl (als Ersatz für eine Return-Taste dient ein Doppelklick nach oben... was manchmal zu einer Fehlbedienung führen kann ... und bei MineSpweeper ist ein Doppelklick links das Aufdecken eines Feldes und ein Doppelklick rechts das Markieren eines Feldes... auch manchmal ungewollte "Aktion"). Das Programm selbst ist ein (von mir so genanntes) Make-File Projekt, das heißt es unterlag keiner IDE, und ist unter Linux entstanden. Zum Übersetzen benötigt es ein systemweit erreichbarer arm-none-eabi-gcc Compiler und zum hochladen des Codes ein systemweit erreichbare STM32_CubeProgrammer, bei dem auch die Kommandozeile verfügbar sein soll. Ansonsten gibt es relativ wenig zu sagen, es reicht ein Controller in der Standardbeschaltung und ein TFT-Display mit 160x128 Pixel. Das Display selbst ist über ein Header konfigurierbar, so dass Displays mit unterschiedlichen Controllern funktionieren sollten. Getestet sind ST7735 (default) sowie S6D02A1 und ILI9163.
Angehängte Dateien:
Ralph S. schrieb: > Grundsätzlich habe ich die Software auf einem Nucleo F446 extrem cool! Der Zufall will dass ich gerade einen Nucleo F446RE vor mir habe und probieren will, ein SPI Display daran zu betreiben. Da will ich gerne mal Deine Software sichten und probieren! Danke!
Ralph S. schrieb: > Über den Code nicht wundern Warum hast du nicht die heute üblichen LL-Libraries verwendet? Das macht es extrem "lästig" das Ganze in eine heute machbare Version zu bringen.
Wastl schrieb: > Ralph S. schrieb: >> Über den Code nicht wundern > > Warum hast du nicht die heute üblichen LL-Libraries verwendet? > Das macht es extrem "lästig" das Ganze in eine heute machbare > Version zu bringen. Ich hab mir das auch mal angeschaut. Es sollte kein unlösbares Problem sein, das auf HAL umzustellen. LL ist dazu gar nicht nötig.
Wastl schrieb: > Warum hast du nicht die heute üblichen LL-Libraries verwendet? > Das macht es extrem "lästig" das Ganze in eine heute machbare > Version zu bringen. weil die ganzen Sourcen über die Jahre hinweg entstanden / gewachsen (und selbst geschrieben) sind und von daher mir dann natürlich auch liegen. Ursprünglich waren die auch von der Namensgebung her an das BGI-Interface von Borland angelegt (Turbo-Pascal und Borland-C waren meine ersten ernsthaften Programmierunternehmnungen). Von daher: Never touch a running System. Harry L. schrieb: > Es sollte kein unlösbares Problem sein, das auf HAL umzustellen. > LL ist dazu gar nicht nötig. Na ja, das ganze basiert hier ja auf libopencm3 (welches im Archiv ja enthalten ist). Zudem glaube ich, dass da nicht wirklich ein Mensch (außer mir) daran etwas "rumfummeln" mag. Die Grafiksourcen habe ich hier in einem anderen Thread zu CH32V003 beschrieben: es sind dieselben.
Gunnar F. schrieb: > extrem cool! Der Zufall will dass ich gerade einen Nucleo F446RE vor mir > habe und probieren will, ein SPI Display daran zu betreiben. Da will ich > gerne mal Deine Software sichten und probieren! Danke! Danke für das Lob hier solltest / kannst du im Makefile deinen Controller angeben, wobei das jedoch in dieser Software nicht wirklich eine Rolle spielt, weil der größere Flash- und RAM-Speicher des F446 sowieso nicht genutzt wird. Ein Display kannst du im Verzeichnis include in der Header-Datei tftdisplay.h konfigurieren (für bspw. die Farbreihenfolge rgb oder bgr) und auch grundsätzlich den Controllertyp des Displays. Weil ich (leider) im Laufe der Zeit unterschiedliche Platinen und Aufbauten gemacht habe, habe ich auch viele unterschiedliche Anschlussbelegungen zu dem Display. Aus diesem Grund habe ich die Pindeklarationen der Anschlüsse zum Display in der Datei tft_pindefs.h (ebenfalls im Verzeichnis include) ausgelagert. Hier kannst du entweder eine weitere Pinbelegung angeben, oder eine für dich passendere Belegungen aus den vorgegebenen verwenden. Bis heute habe ich es nicht geschafft, ein PCB für ein Nucleo-Board für ein Display mit Tasten zu erstellen (liegt wohl daran, dass ich mittlerweile den Controller auf meine eigenen PCB platziere). Wenn du das ausprobierst wäre ich über eine Rückmeldung dankbar, ob das so auch geklappt hat. Im Moment sitze ich immer wieder einmal an Sokoban und an Snake... wobei mir beim einen die Displaygröße zu schaffen macht -Sokoban- und zum anderen, dass eine langgewordene Schlange noch flüssig dargestellt wird. Hier machen mir meine relativ langsamen Sourcen Probleme... schauen wir mal)
... vergessen habe zu schreiben: Wenn es nur darum geht, ein Display am F446 zu betreiben, kann ich dir auch gerne hier ein kleines Display-Demo einstellen, dann mußt du dich nicht durch den ganzen Wust durchkämpfen.
Ralph S. schrieb: > ... vergessen habe zu schreiben: Wenn es nur darum geht, ein Display am > F446 zu betreiben, kann ich dir auch gerne hier ein kleines Display-Demo > einstellen, dann mußt du dich nicht durch den ganzen Wust durchkämpfen. Moin Ralph, herzlichen Dank! Mag sein dass ich beim Displaykauf nicht gut aufgepasst habe: https://joy-it.net/de/products/RB-TFT3.2V2 Das nahm ich weil es günstig ist und mir das Paket aus Touch, Buttons (und Preis) gut paßte. Bei der Recherche gestern fiel mir dann auf, dass da offenbar ein Joy-It-spezifischer Controller drin ist, der das SPI auf die parallele Schnittstelle des LCD-Controllers umsetzt. Das könnte erklären, warum ich kaum eine Library für STM32 finden konnte. Vielleicht hat ja auch hier jemand damit Erfahrung und weiß, wie die Anbindung funktioniert. Es soll ja am Raspberry funktionieren und das werde ich dann auch mal probieren. Vielleicht kann ich aus den Sourcen des Linux-Treibers dann die entsprechenden Informationen gewinnen. Mein erstes Display-Experiment war das SSD1306-OLED und das ist ja auch günstig und hübsch, aber halt arg klein. Mit der Bibliothek hatte ich keine Probleme.
Gunnar F. schrieb: > Moin Ralph, herzlichen Dank! Mag sein dass ich beim Displaykauf nicht > gut aufgepasst habe: > https://joy-it.net/de/products/RB-TFT3.2V2 > Das nahm ich weil es günstig ist und mir das Paket aus Touch, Buttons > (und Preis) gut paßte. Ach herjeh, das tut mir leid. Ich habe für dieses Display die Pinbelegung nicht heraus gefunden. In meinen Grafik-Sourcen ist auch rudimentär die Ansteuerung für parallele Displays enthalten (diese aber noch ohne DMA Unterstützung), aber nur unter Verwendung von Bitbanging. Bei den typischen Vertretern, die man auf ein Nucleo aufstecken kann, ist die Anordnung der Datenleitung leider so daneben (scheinbar für Arduino-UNO gemacht), dass die GPIO's hier auf mehrere Ports verteilt werden. Das macht das ganze dann leider etwas langsam und das Display fällt hier dann auf das Niveau eines SPI-Displays in der Geschwindigkeit zurück. Nach meiner Recherche gibt es dieses Display auch mit ST7735r Controller und parallelem Anschluss, aber leider habe ich die Pinbelegung dieses Displays nicht herausgefunden. Wenn diese bekannt wären, könnte ich die Grafiksourchen um ein parallels ST7735 Display erweitern, allerdings könnte ich das dann nicht testen. Gunnar F. schrieb: > Mein erstes Display-Experiment war das SSD1306-OLED und das ist ja auch > günstig und hübsch, aber halt arg klein. Mit der Bibliothek hatte ich > keine Probleme. Die Displays habe ich natürlich auch, aber für die Spiele ungeeignet, da sie nur 128x64 Pixel in sw haben.
Ralph S. schrieb: > Ich habe für dieses Display die > Pinbelegung nicht heraus gefunden. Die habe ich schonmal: https://www.lcdwiki.com/3.2inch_RPi_Display
Gunnar F. schrieb: > Die habe ich schonmal: > https://www.lcdwiki.com/3.2inch_RPi_Display Das ist EIN Display für den RaspBerry PI, aber nicht dein Display (welches du oben als von Joy-It) verlinkt hast. Das, was im Link von lcdwiki steht, ist kein parallels Interface, sondern ein SPI-Interface mit ILI9341 Controller. Da ich ein ILI9341 Display nur als paralleles habe, habe ich das meinen Sourcen auch nicht als SPI-Interface mit eingefügt. Vielleicht sollte ich meine Beschreibung für die Displays noch einmal überarbeiten, damit jeder nach gutdünken das erweitern kann. Für dein Display habe ich 2 unterschiedliche Angaben zu Controllertypen des Displays gefunden. Schreibe doch Joy-It an und frage: 1.) welcher Controller-Typ verbaut ist 2.) Pinbelegung ansonsten kann man dir nicht weiter helfen
Harry L. schrieb: > Es sollte kein unlösbares Problem sein, das auf HAL umzustellen. Das dürfte es wirklich nicht sein, ich habe mir, mal wieder beim Aufräumen und erweitern (andere Projekte), meine Sachen noch einmal angeschaut). Die wenigen Dinge die mit dem HAL gemacht werden müssen sind: In Datei sysf4xx_init.c - in Funktion sys_init den Coreclock auf 84 MHz einstellen (oder mehr, je nachdem welcher F4 das ist), dort den Takt für die Ports A, B und C einschalten - in Funktion systick_setup die Systemtickerzeit auf 1 ms stellen In Datei tftdisplay.c die Funktionen für das SPI umstellen, die da sind: - spi_init - spi_in - spi_lcdout In Datei tft_pindefs.h - die Makros zum Initialisieren einzelner GPIO's als Output sowie das Setzen und Löschen eines GPIO-Pins ... und das war es schon, alle anderen Funktionen sind von der Hardware unabhängig! Allerdings: Ich mag den HAL halt einfach nicht.
Ralph S. schrieb: > Allerdings: Ich mag den HAL halt einfach nicht. Ich auch. Deswegen sag ich ja: Wastl schrieb: > Warum hast du nicht die heute üblichen LL-Libraries verwendet? Die würden auch besser zu den von dir verwendeten "alten" Libraries passen.
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.