Hallo, für ein Schulprojekt wollen ein freund und ich eine Art "Gameboy" mit dem STM32F4 entwickeln. Es sollen kleinere Spiele wie Tetris, Pacman und Pong umgesetzt werden. Die Games sollen alle aus einem Hauptmenü aufrufbar sein. Außerdem haben wir noch ein paar Kleinigkeiten wie ein Malprogramm oder Bilder von einer SD Karte angucken. Dazu erstmal eine Frage: Dass man die Spiele/das Programm nicht von einem externen Flash starten kann, ist mir klar. Aber wäre es möglich, die Spiele an verschiedenen Stellen im Flash zu speichern und dann in das jeweilig Programm zu springen? Geht ja auch mit dem In-Application-Programming Bootloader. Grafiken (z.b. Ms. Pacman) und andere spiel bezogene Daten werden auf einem externen NAND Flash gespeichert und bei bedarf abgerufen. Das aktuelle Bild für den Bildschrim wird auf einem externen SRAM abgelegt und auch direkt an dieser Stelle aktualisiert. Jedoch wissen wir noch nicht so richtig, wie wir das Display nutzten sollen: Mit oder ohne Controller? Wir hängen gerade zwischen 2 Displays. 1 mit und 1 ohne Controller. http://www.ebay.com/itm/3-2inch-320x240-Touch-LCD-B-3-2-TFT-LCM-Display-Module-Graphic-Screen-Panel-/261054618017?pt=LH_DefaultDomain_0&hash=item3cc81159a1 http://www.ebay.com/itm/4-3inch-480x272-Touch-LCD-B-4-3-TFT-Display-Module-Graphic-LCM-Screen-Panel-/251173169883?pt=LH_DefaultDomain_0&hash=item3a7b166adb Von der größe her, ziehen wir eindeutig das ohne Controller vor. Laut dieser Dokumentation "TFT-LCD direct drive" http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00278141.pdf sind beim STM32F1 mit 320x240 Pixel Display nur 1% Auslastung. Beim STM32F4 müsste das dann ja noch weitaus weniger sein. Jedoch wo liegen die Vor-/Nachteile und was würdet ihr mir Empfehlen? Ich hoffe ich kann hier eine kleine Diskussion anregen. MfG GamerBoy
Hallo, wie gut sind eure Vorkenntnisse, wieviel Zeit habt ihr zur Verfügung, wieviele Personen seid ihr? Wenn ihr nicht bereits gut programmieren könnt, ist jedes Spiel für sich schon ein Schulprojekt. > Die Games sollen alle aus einem Hauptmenü aufrufbar sein. [...] > Aber wäre es möglich, die Spiele an verschiedenen > Stellen im Flash zu speichern und dann in > das jeweilig Programm zu springen? Eine Funktion rufst du auf und wenn sie endet, kommst du wieder zurück. Also kannst du jedes Spiel/Programm als Funktion programmieren und wenn die endet (du das Spiel beendest), kommst du zurück ins Hauptprogramm. > Außerdem haben wir noch ein paar Kleinigkeiten wie ein > Malprogramm oder Bilder von einer SD Karte angucken. Vergiss das erstmal. Hauptmenü mit zwei funktionierenden Einträgen ("Hallo Welt" und "Pong") ist erstmal genug Arbeit. Erweitern kannst du später immer, solange noch genug Flash vorhanden ist. > Grafiken (z.b. Ms. Pacman) und andere spiel bezogene Daten werden auf > einem externen NAND Flash gespeichert und bei bedarf abgerufen. Muss nicht sein. Pro Bild reichen 16x16 Pixel bei 4 Bit Farbtiefe (16 Farben), also 128 Byte. Du hast mindestens 512 KILOByte Flash, also programmiere etwas geschickt und du brauchst keine zusätzliche Hardware (die kostet Geld). > Das aktuelle Bild für den Bildschrim wird auf einem externen SRAM > abgelegt und auch direkt an dieser Stelle aktualisiert. Das heißt, dass dein Programm zusätzlich zum Spiel auch noch 50 Bilder pro Sekunde auf das Display schieben muss. Das ist möglich, macht aber die Sache nur noch komplizierter. Nimm ein Display mit Controller und spare dir den zusätzlichen SRAM-Baustein. Der Framebuffer ist im Controller schon mit drin. > Von der größe her, ziehen wir eindeutig das ohne Controller vor. Für Pong und Tetris brauchst du keine großen Pixelmengen. Der originale Gameboy hatte 160x144 Pixel. Dafür nimmt dir ein Controller viel Arbeit ab. > Jedoch wo liegen die Vor-/Nachteile und was würdet ihr mir Empfehlen? Erstmal die Ansprüche runterschrauben auf ein realistisches Niveau. Gruß, Svenska
GamerBoy schrieb: > sind beim STM32F1 mit 320x240 Pixel Display nur 1% Auslastung. Beim > STM32F4 müsste das dann ja noch weitaus weniger sein. Beim STM32F4 sollen ext. RAM + FSMC + DMA nicht funktionieren. Aber vielleicht ist das Problem mittlerweile behoben. Falls das discovery-board verwendet werden soll: hier fehlen die Leitungen A0-A15. Latches sind notwendig. > Jedoch wo liegen die Vor-/Nachteile und was würdet ihr mir Empfehlen? Falls 6-8 Bit Farbtiefe ausreicht, gibt's eine einfache Lösung fürs discovery-board. Beitrag "TFT-direct-drive, WQVGA-TFT an STM32F4" Svenska schrieb: > Erstmal die Ansprüche runterschrauben auf ein realistisches Niveau. Das kann ich nur unterstreichen!
Hi, sorry hab ich vergessen. 2 Personen. Ca. 0,75 - 1 Jahr. Am ende mit Projektarbeit. Ich: Arbeite schon länger mit dem STM32F4. Habe parallel noch ein zusätzliches größeres Projekt mit dem Ding laufen. Und habe den Programmablauf sozusagen schon im Kopf. Freund: Anfänger bis Fortgeschrittener Programmierer. Erfahrung mit Atmegas. Aber schnell lernfähig. Es soll einer erweiterter Gameboy werden mit etwas mehr Möglichkeiten. Sollten die Hardware erstmal funktionieren, wäre die größte Hürde also schon geschafft. Da wir weder so genau ätzen, fräsen (wir haben eine in der Schule) noch löten können, werden wir wahrscheinlich als Basis das hier verwenden: http://www.ebay.com/itm/STM32F407IGT6-STM32F407-STM32-ARM-Cortex-M4-Development-Core-Board-Full-IOs-/251145392549#payId Darunter kommt dann ein Board zum drunterstecken. Flash und Ram das gleiche: http://www.ebay.com/itm/IS62WV51216BLL-SRAM-Board-Memory-Storage-Module-CMOS-Evaluation-Development-Kit-/261009984105?pt=LH_DefaultDomain_0&hash=item3cc5684a69 http://www.ebay.com/itm/K9F1G08U0C-NandFlash-Board-Nand-Flash-Memory-Storage-Module-Development-Kit-Tool-/261009997422?pt=LH_DefaultDomain_0&hash=item3cc5687e6e Wir nutzen den STM32F407IG (176 Pins, Flash: 1Mbyte) Externer SRAM und Flash sind nicht teuer. Da wir das Projekt als Ersatz machen für eine Atmega Platine, weil wir schon weiter sind. Wollen/Sollen wir einfach möglichst viel damit Demonstrieren und Zeigen was wir können. Nachteihaft wärs nicht, wenn wir das einfach noch dazu nehmen. Nun zum Display. Der DMA schiebt sämtliche Daten aus dem ext. SRAM in das Display. Und durch FPU, DSP und ihren geschickter Einsatz sollten wir eigentlich kaum merken, dass da noch was im Hintergrund passiert. Wir hatten min 24Hz angepeilt, damit wir noch etwas Luft nach oben haben, was z.b. das darstellen von Bildern/Videos von SD angeht. MfG GamerBoy
[Gelöscht. Bitte nicht auf Trolle reagieren.] m.n. schrieb: > GamerBoy schrieb: >> sind beim STM32F1 mit 320x240 Pixel Display nur 1% Auslastung. Beim >> STM32F4 müsste das dann ja noch weitaus weniger sein. > > Beim STM32F4 sollen ext. RAM + FSMC + DMA nicht funktionieren. Aber > vielleicht ist das Problem mittlerweile behoben. > Falls das discovery-board verwendet werden soll: hier fehlen die > Leitungen A0-A15. Latches sind notwendig. > >> Jedoch wo liegen die Vor-/Nachteile und was würdet ihr mir Empfehlen? > > Falls 6-8 Bit Farbtiefe ausreicht, gibt's eine einfache Lösung fürs > discovery-board. Beitrag "TFT-direct-drive, WQVGA-TFT an STM32F4" > > Svenska schrieb: >> Erstmal die Ansprüche runterschrauben auf ein realistisches Niveau. > > Das kann ich nur unterstreichen! Im Errata Sheet steht nichts drin.
GamerBoy schrieb: > Im Errata Sheet steht nichts drin. Dann hätte ich es ja auch nicht schreiben müssen :-)
>Und durch FPU, DSP und ihren geschickter Einsatz sollten >wir eigentlich kaum merken, dass da noch was im Hintergrund passiert. Das musst du jetzt mal näher erklären. Ich glaube du hast keine Ahnung was eine FPU ist. Für Tetris oder Pacman braucht man die nicht.
m.n. schrieb: > GamerBoy schrieb: >> Im Errata Sheet steht nichts drin. > > Dann hätte ich es ja auch nicht schreiben müssen :-) Ich konnte auch bei google nichts finden. Hast du da vielleicht ne Link? holger schrieb: >>Und durch FPU, DSP und ihren geschickter Einsatz sollten >>wir eigentlich kaum merken, dass da noch was im Hintergrund passiert. > > Das musst du jetzt mal näher erklären. > > Ich glaube du hast keine Ahnung was eine FPU ist. > Für Tetris oder Pacman braucht man die nicht. Auch für Pacman muss man zumindest kleine Berechnung durchführen. Bei Pacman ist die zwar rein von der Rechenleistung nicht notwendig aber es soll nicht dabei bleiben, sondern noch die ein oder andere Rechenintensivere Idee dazukommen. Und da wird die FPU den Core auf jedenfall entlasten.
> Ebay-Artikel Nr. 261054618017
Das Display ist gut. Habe es selber schon ausprobiert und kann es daher
empfehlen. Ansprechen geht via FSMC recht komfortabel. Von Waveshare
gibts auch ein größeres Evaluation Kit wo das Display bei ist(zusammen
mit dem stm32F4Discovery)
GamerBoy schrieb: > Ich konnte auch bei google nichts finden. Hast du da vielleicht ne Link? Vielleicht geht es ja jetzt. Daher ist es am besten, die Schaltung aufzubauen und zu testen. Falls es dann nicht funktioniert: da muß man als Entwickler durch!
Hallo, > sorry hab ich vergessen. 2 Personen. Ca. 0,75 - 1 Jahr. Am ende mit > Projektarbeit. Also vermutlich Abiturstufe. Könnte machbar sein. Schreibt in das Pflichtenheft nur "Pong", "Tetris" und "Display" rein, dann ist das nicht schlimm, wenn ihr nicht alles schafft. Bugs finden und fixen dauert ewig. > Es soll einer erweiterter Gameboy werden mit etwas mehr Möglichkeiten. Sollen Spiele von SD-Karte geladen werden können? Falls ja, verkompliziert das Softwaredesign extrem. > Wir nutzen den STM32F407IG (176 Pins, Flash: 1Mbyte) In 1 MB Flash solltest du sämtliche deiner Anforderungen reinkriegen. Zusätzlicher NAND-Flash ist nicht notwendig, den kann die SD-Karte übernehmen. Den kannst du wirklich einsparen. Ein zusätzlicher SRAM sollte auch nicht notwendig sein, wenn du beim Programmieren ein bisschen aufpasst. Wenn es sein muss, nimm ihn rein; ob er am Ende auch benutzt wird, ist noch ein anderer Stern. > Wollen/Sollen wir einfach möglichst viel damit Demonstrieren und Zeigen > was wir können. Nachteihaft wärs nicht, wenn wir das einfach noch dazu > nehmen. Viel hilft nicht immer viel. Lieber wenig und gut, als bei der Demonstration ein peinlicher Crash, weil der Code nach den ununterbrochenen Nachtschichten der letzten zwei Projektwochen stinkt... Design es erweiterbar, dann kannst du deine verbleibende Zeit für Erweiterungen nutzen. Wichtig ist (bei Schulprojekten) die Dokumentation. Zumindest bei uns war die immer wichtiger als das Projekt selbst, allein weil die Lehrer sich nicht in das Projekt einarbeiten wollten bzw. den Nachweis wollten, dass du es selbst kannst. > Nun zum Display. Der DMA schiebt sämtliche Daten aus dem ext. SRAM in > das Display. Und durch FPU, DSP und ihren geschickter Einsatz sollten > wir eigentlich kaum merken, dass da noch was im Hintergrund passiert. Das ist Unsinn. Du hast eine begrenzte Bandbreite, wenn du die mit dem DMA zupflasterst, wirst du es definitiv irgendwann merken. Die FPU hat damit auch nix zu tun. Nimm ein Display mit Controller und implementiere ein Damage-System, dann reicht es, wenn der DMA-Baustein nur die geänderten Teile automatisch per SPI ins Display bläst. Um Framerate und Jitter/Ruckeln musst du dich dann nicht mehr kümmern. Wenn du willst, kannst du ein RTOS verwenden, ein controllerloses Display verwenden und die Komplexität weit nach oben aufblähen. Dann zieh aber zwei Monate von der Zeit für Funktionalität ab. :-) > Wir hatten min 24Hz angepeilt, damit wir noch etwas Luft nach oben > haben, was z.b. das darstellen von Bildern/Videos von SD angeht. Am besten noch MP4-codiert. Wenn du dich mit AVRs auskennst, dann weißt du, was innerhalb einer bestimmten Zeit realistisch ist. Was du beschreibst, ist mit Vorkenntnissen in nem halben Jahr machbar (plus Vierteljahr Dokumentation!). Aber du wirst sicher nicht 4-8h/Tag in das Projekt investieren, wenn du noch ein Leben hast. Ansonsten: Viel Glück. Gruß, Svenska
Jo discovery schrieb: >> Ebay-Artikel Nr. 261054618017 > > Das Display ist gut. Habe es selber schon ausprobiert und kann es daher > empfehlen. Ansprechen geht via FSMC recht komfortabel. Von Waveshare > gibts auch ein größeres Evaluation Kit wo das Display bei ist(zusammen > mit dem stm32F4Discovery) Danke, werd mir das Teil nochmal genauer angucken. Gibt es für den Controller eine Lib, die wir als Referenz einsetzten könnten? m.n. schrieb: > GamerBoy schrieb: >> Ich konnte auch bei google nichts finden. Hast du da vielleicht ne Link? > > Vielleicht geht es ja jetzt. > Daher ist es am besten, die Schaltung aufzubauen und zu testen. > > Falls es dann nicht funktioniert: da muß man als Entwickler durch! Ich gucke mich noch etwas um. Wenn wirs testen sollten meld ich mich nochmal.
> Danke, werd mir das Teil nochmal genauer angucken. Gibt es für den > Controller eine Lib, die wir als Referenz einsetzten könnten? Es gibt Beispielcode von Waveshare der auch schon direkt für den stm32F4 ist. Ich habe das Open407V-D wo das alles dabei ist. http://www.wvshare.com/product/Open407V-D-Standard.htm Wenn ihr etwas Geld hinlegen könnt wäre das vielleicht ganz gut zum Spielen und kennenlernen. Display anstöpseln, Beispielprogramm laden und schon gehts. Das Display ist ein Farbdisplay.
Schaut euch mal die Hardware DSO203 an. Gibt es für kleines Geld und hat schon alles drin. Prozessor könnt Ihr ja raus löten/tauschen oder das Mainboard neu designen. Gibt es bei Ebay.
Svenska schrieb: > Hallo, > >> sorry hab ich vergessen. 2 Personen. Ca. 0,75 - 1 Jahr. Am ende mit >> Projektarbeit. > Also vermutlich Abiturstufe. Könnte machbar sein. > Schreibt in das Pflichtenheft nur "Pong", "Tetris" und "Display" rein, > dann ist das nicht schlimm, wenn ihr nicht alles schafft. Bugs finden > und fixen dauert ewig. Das Problem kenn ich, aber durch Testen "jeder einzelnen" Zeile beim Programmieren senkt die Fehlerzahl erheblich. Pflichtenheft haben wir nicht. Eigentlich sollen wir dieses Halbjahr eine Atmega Platien nach Vorgaben machen und etwas lernen und im nächsten Jahr damit ein selbst ausgedachtes Projekt. Wir wollen als Ersatz das machen. >> Es soll einer erweiterter Gameboy werden mit etwas mehr Möglichkeiten. > Sollen Spiele von SD-Karte geladen werden können? Falls ja, > verkompliziert das Softwaredesign extrem. Das auf keinen Fall. >> Wir nutzen den STM32F407IG (176 Pins, Flash: 1Mbyte) > In 1 MB Flash solltest du sämtliche deiner Anforderungen reinkriegen. > Zusätzlicher NAND-Flash ist nicht notwendig, den kann die SD-Karte > übernehmen. Den kannst du wirklich einsparen. > Ein zusätzlicher SRAM sollte auch nicht notwendig sein, wenn du beim > Programmieren ein bisschen aufpasst. Wenn es sein muss, nimm ihn rein; > ob er am Ende auch benutzt wird, ist noch ein anderer Stern. > >> Wollen/Sollen wir einfach möglichst viel damit Demonstrieren und Zeigen >> was wir können. Nachteihaft wärs nicht, wenn wir das einfach noch dazu >> nehmen. > Viel hilft nicht immer viel. Lieber wenig und gut, als bei der > Demonstration ein peinlicher Crash, weil der Code nach den > ununterbrochenen Nachtschichten der letzten zwei Projektwochen stinkt... Das wird hoffe ich wird nicht passieren. Aber ich habe ja viel Ferien dazwischen. Zeitlich sollte das eigentlich passen. > Design es erweiterbar, dann kannst du deine verbleibende Zeit für > Erweiterungen nutzen. Wichtig ist (bei Schulprojekten) die > Dokumentation. Zumindest bei uns war die immer wichtiger als das Projekt > selbst, allein weil die Lehrer sich nicht in das Projekt einarbeiten > wollten bzw. den Nachweis wollten, dass du es selbst kannst. Die Doku kommt erst nächstes Halbjahr. Ich bin auf einem Beruflichen Gymnasium Technik und habe E-Technik als P1 (Abi) und unsere Praxislehrer haben teilweise auch viel Ahnung in die Richtung. >> Nun zum Display. Der DMA schiebt sämtliche Daten aus dem ext. SRAM in >> das Display. Und durch FPU, DSP und ihren geschickter Einsatz sollten >> wir eigentlich kaum merken, dass da noch was im Hintergrund passiert. > > Das ist Unsinn. Du hast eine begrenzte Bandbreite, wenn du die mit dem > DMA zupflasterst, wirst du es definitiv irgendwann merken. Die FPU hat > damit auch nix zu tun. > > Nimm ein Display mit Controller und implementiere ein Damage-System, > dann reicht es, wenn der DMA-Baustein nur die geänderten Teile > automatisch per SPI ins Display bläst. Um Framerate und Jitter/Ruckeln > musst du dich dann nicht mehr kümmern. Ok, wir gucken uns noch etwas um und entscheiden dann. > Wenn du willst, kannst du ein RTOS verwenden, ein controllerloses > Display verwenden und die Komplexität weit nach oben aufblähen. Dann > zieh aber zwei Monate von der Zeit für Funktionalität ab. :-) > >> Wir hatten min 24Hz angepeilt, damit wir noch etwas Luft nach oben >> haben, was z.b. das darstellen von Bildern/Videos von SD angeht. > > Am besten noch MP4-codiert. Naja, mann muss ja nicht übertreiben ;) > Wenn du dich mit AVRs auskennst, dann weißt du, was innerhalb einer > bestimmten Zeit realistisch ist. Was du beschreibst, ist mit > Vorkenntnissen in nem halben Jahr machbar (plus Vierteljahr > Dokumentation!). Aber du wirst sicher nicht 4-8h/Tag in das Projekt > investieren, wenn du noch ein Leben hast. Das ist mein Leben ;) Danke für die Infos. MfG GamerBoy
Dein Freund (AVR-Mann) sollte sich mal dies als Anregung anschauen -- http://belogic.com/uzebox/index.asp Wie Jo discovery schrieb, ist das "Open407V-D" als Testplattform geeignet; Teilweise habe ich schonmal ähnliches angefangen: Beitrag "ST-Discovery-Net-IO Anfang"
Wollt ihr einen framebuffer im RAM haben? Dann kommst um externes sram nicht rum bei der Displaygröße. So ein Display gehört an ein embedded System mit sdram und Linux drauf und nicht an so nen kleinen Controller (der ist zwar schnell aber zu wenig RAM)
Bezüglich des Displays werde ich nochmal etwas gucken. Mit Controller wäre wohl das beste. Aber wir suchen ein 4.3 inch Display. Mal kurz was zwischendurch. Ich versuche auf den BackupSram zuzugreifen, was bisher aber noch nicht geklappt hat. Im Datenblatt/Referenz Manual sowie bei google konnte ich nichts finden, was mich auf den BKD Sram zugreifen lässt. Hier der Codeausschnitt zum Testen. Compilieren und debuggen geht, aber es werden anscheint weder Daten in den BKD Sram geschrieben noch können die dann gelesen werden.
1 | PWR_DeInit(); |
2 | RCC_APB1PeriphResetCmd(RCC_APB1Periph_PWR, ENABLE); |
3 | PWR_BackupAccessCmd(ENABLE); |
4 | PWR_BackupRegulatorCmd(ENABLE); |
5 | |
6 | *(uint32_t*)(BKPSRAM_BASE+0) = ('H'<<24)|('e'<<16)|('l'<<8)|('o'); |
7 | |
8 | for(unsigned int i=0;i<40000;i++) |
9 | {
|
10 | __asm("NOP"); |
11 | }
|
12 | |
13 | uint32_t out_data = *(uint32_t*)(BKPSRAM_BASE+0); |
MfG GamerBoy
GamerBoy schrieb: > Aber wir suchen ein 4.3 inch Display. Musste dies anpassen: Beitrag "LPC1788_WQVGA"
Eumel schrieb im Beitrag #3029221: > Dummes Gelaber. Oh ja, hast recht. Man kann natürlich ohne Probleme z.B. ein 320x240 buffer in den SRAM des STM32 bekommen. Sind ja nur 150kb (bei 16 Bit). Nur doof, dass die 192 kB RAM des STM32 dann fast voll sind und nicht durchgängig addressierbar sind ("normales" RAM und CCM RAM). Aber macht ja nix, dann nimmt man halt ein Display mit Controller und verzichtet auf den Framebuffer. Das sieht bei Spielen, die mitunter auch mal Bewegungsabläufe haben, sicher lustig aus wenn man dann den Frame-Aufbau auf dem Display sehen kann (gibt schöne "Schlieren"). Man müsste die Display-Update-Routinen dann so schreiben, dass nur die geänderten Bereiche neu gezeichnet und zum Display übertragen werden (Schlierenbildung hat man damit trotzdem, nur nicht ganz so schlimm). Kann ganz schön umständlich werden. Wieso eigentlich einen STM32? Das geht doch auch alles mit einem Mega8, der bekommt das Display mit Controller auch angesteuert... Ich finde es immer wieder erstaunlich, dass man mit aller Gewalt versucht mit ungeeigneten Mitteln zum Ziel zu kommen (z.B. hochauflösende TFTs mit AVR und co ansprechen). Wobei der STM32 mit 1MB externen RAM sicher ausreichend wäre (wenn man die FSMC mit Display und RAM ans laufen bekommt).
es gibt noch eine weitere Möglichkeit: Ihr nehmt eine RaspberryPi-Platine und baut die in ein Gehäuse ein. Anschließend besorgt ihr euch einfach ein ganz normales kleines TFT-Display und schließt es an einen der Videoausgänge an. Ihr müsst euch dann überhaupt nicht mehr um die Ansteuerung kümmern. Auf Ebay gibts kleine Monitore mit 7 Zoll oder weniger. Das Praktische daran ist, dass ihr eure Spiele auf Linux aufsetzen könnt. Das macht die Sache natürlich äußerst komfortabel. Auch vom mechanischen Formfaktor dürfte es gehen. Die Platine ist wirklich nicht sehr groß. :-)
Artjomka schrieb: > Aber macht ja nix, dann nimmt man halt ein Display mit Controller und > verzichtet auf den Framebuffer. Das sieht bei Spielen, die mitunter auch > mal Bewegungsabläufe haben, sicher lustig aus wenn man dann den > Frame-Aufbau auf dem Display sehen kann (gibt schöne "Schlieren"). Hm, oder ein Display mit Controller der einen Framebuffer hat?
Ich bin dabei, ein 5"-Display mit SSD1963 an einem stm32f417 zu
betreiben.
Lt. Datenblatt :
"There are 1215K bytes built-in SRAM inside SSD1963 to use as frame
buffer."
-den ich zu nutzen gedenke;
Mit FSMC ist dies machbar.
Durchkalkulieren muss ich noch, ob ich TEAR SCANLINE einsetzen muss, zur
Übertragung ("TE signal is sent from the display module to the host
processor when the display device refresh reaches the provided
scanline, N.")
Artjomka schrieb:
> Ich finde es immer wieder erstaunlich, dass man mit aller Gewalt
> versucht mit ungeeigneten Mitteln zum Ziel zu kommen (z.B.
> hochauflösende TFTs mit AVR und co ansprechen).
Und ich bin zuversichtlich ...
Ja, das mit dem Framebuffer im Display hab ich ja auch geschrieben. Geht natürlich. Und ist super um irgendwelche Infos etc. auf dem Display dar zu stellen, dafür reicht das vollkommen aus (weil sich der Display-Inhalt von einem Frame auf den nächsten kaum ändert). Aber wenn man ein Spiel hat, dann gibt es da z.B. mehrere übereinander gelagerte Sprites die nacheinander gezeichnet werden. Zum Beispiel ein Side-Scroller wie Super Mario: Erst zeichnet man den Hintergrund (das Level), der Hintergrund bewegt sich dabei auch noch. Dann zeichnet man da drauf seine Sprites (Mario, die Gegner, etc.). Wenn man dann nur einen Framebuffer im Display hat, wird man sehen wie sich das Level aufbaut (eine Hälfte vom Display zeigt z.B. noch den alten Hintergrund an und die andere schon den neuen um 1 pixel verschobenen Hintergrund). Man sieht dann also die halb-fertigen Frames auf dem Display und das sieht nicht schön aus... Ich verwende am STM32 nur ein ganz kleines Display mit Controller und habe einen Framebuffer im RAM. Der Framebuffer wird berechnet, zum Display geschickt und danach kann ein neuer Framebuffer berechnet werden. Will man es super-schnell, dann braucht man zwei Framebuffer im RAM (damit der eine weg geschickt werden kann und zeitgleich der neue berechnet werden kann). Hat man ein Display ohne Controller braucht man sowieso zwei Framebuffer im RAM (damit der eine dargestellt werden kann und der andere neu berechnet werden kann). Weil ansonsten würde man wieder den Frameaufbau sehen (wenn der Framebuffer, welcher dargestellt wird zur gleichen Zeit auch neu berechnet wird).
@ Artjomka (Gast) -die von mir angemerkte TEAR SCANLINE ist ein Startpunkt, ab dem das Video-RAM nicht ausgelesen wird. Jetzt können neue Daten geschrieben werden.(Back/Front-Porch), wenn unbedingt notwendig, auch gleich nach dem "refreshen" einer Zeile. Dadurch wird sichergestellt, das keine Änderung während des laufenden Frames ein Flackern erzeugt oder solche Effekte wie von Dir beschrieben. Weiter oben habe ich auch schon Sprites erwähnt Beitrag "Re: STM32F4 "Gameboy"" ,wie sie zur Darstellung recht flüssiger Aninationen beim Mega 644(UZE-Box) angewandt werden(falls die Bearbeitungszeit nicht ausreicht) Wie gesagt, ich bin noch beim Kalkulieren... (durch FSMC langweilt sich der stm die meiste Zeit sowieso)
@vampire: Achso, ja okay. Aber das macht die Programmierung nicht unbedingt einfacher oder? :-) Wusste auch nicht, dass es Displays gibt die solch einen Ausgang zur Verfügung stellen.
der SSD1963 hat dies extra für solche Aufgaben. (Wenn es so einfach wäre, hätte ich's nicht erwähnt, sondern in der Zeit schon eingestellt)
Leider ist bei fast allen billigen China-LCDs mit PCB genau dieser Pin nicht zugänglich.
Weiter oben habe ich schon angedeutet. Etwas ketzerisch: wenn in der init() TSL so konfiguriert wird, das ein Schreiben nur nach dem Refresh einer, -z.B.-, Zeile möglich ist, braucht der datensendende µC nichtmal zu wissen wann er senden darf.(der fehlende Pin !) Nur die Geschwindigkeiten(Timings) müssen stimmen ...
Hi, ich habe ein paar 4.3inch Displays mit SSD1963 gefunden, die den Tearing Pins rausgeführt haben. Hat schonmal jemand probiert 2 x 4.3 inch Displays gleichzeitig anzusteuern. Das eine soll eine Updaterate von ca. 24Hz haben, wobei aber immer nur kleine Bereiche aktualisiert werden. Das andere Muss lediglich mit 1 - 2Hz geupdatet werden. MfG
Angehängte Dateien:
mit Sicherheit weis ich nur, das es "so wie hier" nicht geht; 4,3" controllerloses Display an CM3; links das Orginal, daneben die LCD Ausgabe(ext.SRAM als VRAM); - bereits beim Schreiben muss die selfrefresh-Phase einkalkuliert werden ... (und das ist nur ein "Standbild")
vampire schrieb: > - bereits beim Schreiben muss die selfrefresh-Phase einkalkuliert werden > ... Das kann man durchaus vermeiden, wenn man kein starres Timing verwendet. Zum Test habe ich eine 16 Bit Ansteuerung mit ext. SRAM und DMA für einen RX210 aufgebaut. Da kann der µC jederzeit mit höchster Geschwindigkeit auf den Displayspeicher zugreifen - ohne Flimmern! http://www.mino-elektronik.de/TFT-direct-drive/TFT-direct-drive.htm#tft-2 Natürlich ist es einfacher, ein fertiges Display mit integrietem Controller zu beschaffen. Aber max. Geschwindigkeit hat man dabei zumeist nicht.
@ m.n. (Gast) Ich kenne und schätze deine Arbeit.Ist auch ein Anhaltspunkt gewesen .. -DANKE-
Beitrag "LPC1788_WQVGA" -ist eine Anwendung; allerdings hat der LPC1788 für Timings von H-/V-Sync und Pickelclock einen speziellen Block , ist aber mit den seperaten IC's deiner Schaltung gleichzusetzen ..
Hast Du denn den Schaltplan dazu? In der 7z-Datei scheint er nicht zu sein. Zu dem Thema Displaycontroller könnte ich noch viel schreiben. Aber in einem "Umfeld", wo viele froh sind, ein 800x480 TFT per SPI anzusteuern, ist es sehr schwierig, überzeugend zu argumentieren :-) Wenn man nicht unbedingt ein fertiges TFT (Display+Controller) einsetzen möchte oder darf (wegen langfristiger Verfügbarkeit), wäre der S1D13781 vielleicht das richtige Bauteil: 384k VideoRAM intern, welches neben SPI auch indirekt und insbesondere auch direkt (memory mapped) angesprochen werden kann. Im direkten Modus sogar ohne Rücksichtnahme auf die Sync-Impulse (wenn ich nicht irre). 480x272 bei 24Bit Farbtiefe, 800x480 mit 8Bit, zusätzliche LUT und PIP-Bereich mit Alpha-Blending bei ca. 5€/Stk. netto (Future elec.). Der SSD1963 wird sicherlich noch mehr können, scheint aber als einzelnes IC schlechter verfügbar zu sein. Dies nur als Tipp.
vampire schrieb: > LPC1788 für Timings von H-/V-Sync und Pickelclock > einen speziellen Block -dieser "Block" ist der LCD-Controler(intern), macht die Clock-Verknüpfungen (WR/ --> Clock[573] --> DCLK) und die Verzögerungen intern , bzw., macht die seperaten IC's überflüssig; Ich habe aber dieses "Projekt" auf die Strafbank geschickt(mach ich meist so, wenns partout nicht will) und warte darauf, das die Muse mich küsst -- :)
Hi, nach langer Zeit mal was neues. Das Projekt durften wir dann leider doch nicht in der Schule durchführen sondern sollten das gleiche wie die anderen machen. Allerdings werden wir das jetzt privat weiterführen. Als Display haben wir uns das hier rausgesucht. Das war das einzigste erschwingliche mit Displaycontroller, welches wir finden konnten. http://www.ebay.com/itm/4-3inch-lcd-module-with-touch-panel-bulid-in-SSD1963-controller-PCB-board-/170863023832 Das gute hier ist, dass der TearingEffect Pin rausgeführt ist. Den SD Slot werden wir nicht verwenden, da wir den mit SDIO verwenden wollen und nicht SPI. Den Flash werden wir ebenfalls nicht verwenden, da wir auf der Grundplatine bereits einen 122Mbyte Flash haben. Als Basisplatine haben wir uns diese hier ausgesucht, da ich die sowieso hier zuhause rumfliegen habe. http://www.ebay.de/itm/STM32F407-417ZG-module-HY-STM32F4xxCore144-Core-Dev-Board-/180923405960?pt=LH_DefaultDomain_0&hash=item2a1fe01688#ht_2935wt_1163 Da wir auch noch XBee Pro hier rumfliegen haben, kommen die auch mit auf die Platine für Multiplayer Spiele mit Pong. MfG GamerBoy
> Den SD Slot werden wir nicht verwenden, da wir den mit SDIO verwenden > wollen und nicht SPI. Schonmal SDIO-Karten benutzt? Inzwischen sind die wohl ziemlich ausgestorben (zumindest im Consumerbereich). Bei 128 KB RAM intern und 1 MB RAM extern kommt es auf die Geschwindigkeit dann auch nicht mehr an. > Den Flash werden wir ebenfalls nicht verwenden, da wir auf der > Grundplatine bereits einen 122Mbyte Flash haben. Tipp: Betriebssystem (oder meinetwegen Hauptmenü, Bibliotheksfunktionen, ...) in den internen Flash und die Spiele in den externen Flash. :-) Gruß, Svenska
@Svenska (Gast) - der SD-Card Slot auf dem Display(Unterseite) lässt sich leider nur mit SPI ansprechen, nicht mit dem SDIO- Interface des STM32F407. Denke 1-bit SDIO bringt kaum Vorteile gegenüber SPI;
-obwohl: wenn man bedenkt, das bei SDIO die CPU außen vor bleibt..?! Müsste man mal bench-mark mässig testen --
Hi, Spiele in den exteren FLash wird nicht so ganz funktionieren, da wir hier glaube schon festgestellt hatten, dass man beim STM32F4 keinen Code von einem externen Flash ausführen kann. Die SDIO Schnittstelle beim STM32F4 kann 1-bit, 4-bit und 8-bit. Bei SPI muss jedes Bit einzeln über eine Leitung geschoben werden. Angenommen, die SD Karte kann ebenfalls mit 48Mhz arbeiten, was glaube das max. des SDIO Interface und von SPI beim Stm32f4 ist, müsste man beim 4-bit SDIO die 4fache Geschwindigkeit haben. Die Audio Dateien werden entweder auf der SD oder dem externen Flash gespeichert, das wissen wir noch nicht. Wir nutzen einen MP3 Codec am I2S Interface, da sollten wir in die 122Mbyte ne menge MP3 Files bekommen. http://www.ebay.de/itm/251035949368?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2648#ht_1702wt_1163 Eine Frage hätte ich allerdings zu dem Abspielen der MP3 Files. Den Header der Datei überträgt man dabei nicht mit, oder? Um über den Sound des Spiels (z.B. Pacman) einen z.b. Signalton zu legen, wie muss ich beiden Dateien mixen? Reicht eine einfache Addition? MfG Philipp
GamerBoy schrieb: > Spiele in den exteren FLash wird nicht so ganz funktionieren, da wir > hier glaube schon festgestellt hatten, dass man beim STM32F4 keinen Code > von einem externen Flash ausführen kann. Falls der STM32F4 Code aus dem RAM ausführen kann (hab mich nie mit dem beschäftigt und weiß es deshalb nicht), wäre es eine gute Wahl für ein Betriebssystem, das System und die Prozesse komplett im RAM laufen zu lassen. Wenn er auch noch Paging kann, könnte man jedem Prozess eine Art Virtuellen Adressraum geben, der durch den Task Scheduler für jeden Prozess immer wieder hergestellt wird, wobei die Zero-Page immer eingeblendet sein sollte und zum Beispiel eine Kernel-API enthalten könnte. Dann wäre das OS schön flexibel und könnte Programme von allen möglichen Medien laden, selbst von RS232 und Diskette. Außerdem kann sich jeder Prozess dann so viel RAM nehmen, wie er benötigt, und sogar externe Hardware könnte sich im laufenden System Speicher für DMA reservieren. Dieses Prinzip realisiere ich momentan für einen Z80-Eigenbau-Computer (mit externem Bank Switcher für 256kB RAM). GamerBoy schrieb: > Um über den Sound des Spiels (z.B. Pacman) einen z.b. Signalton zu > legen, wie muss ich beiden Dateien mixen? Reicht eine einfache Addition? Eine vorzeichenbehaftete Addition sollte funktionieren, diese muss aber auf die Rohdaten des Sounds erfolgen, mit den komprimierten MP3-Daten funktioniert das nicht. Gruß Jonathan
Jonathan Strobl schrieb: > Eine vorzeichenbehaftete Addition sollte funktionieren, diese muss aber > auf die Rohdaten des Sounds erfolgen, mit den komprimierten MP3-Daten > funktioniert das nicht. Das ist schlecht. Da das decodieren des MP3 Formats ja eigentlich erst der externe Codec übernimmt. Mal gucken, ob wir die Sounds einfach in Raw speichern, das kostet zwar mehr Platz, aber ist einfacher zu verarbeiten und genug Platz haben wir eigentlich auch. Jonathan Strobl schrieb: > Falls der STM32F4 Code aus dem RAM ausführen kann Kann er, aber ich habe dann immer Probleme mit den Clocks. Beim auslesen sind immer alle Werte 0 bis auf HCLK.
Ich habe nochmal ins Datenblatt vom UDA1380 geschaut. Das steht drin: >The UDA1380 also supports an application mode in which >the coder-decoder itself is not running, but an analog >signal, for instance coming from an FM tuner, can be >controlled in gain and applied to the output via the >headphone driver and line outputs. Wenn ich das richtig verstehe, kann ich über LineIn ein AudioSignal über die Kopfhörer abspielen. Also Raw Soundfiles über 2 PWM (R und L) Kanäle abspielen und die dann auf LineIn geben. Für MP3 Sound aktivieren wir den Decoder dann wieder. Kann ich WAV Files direkt in ein Array konvertieren, oder ist das auch Codiert? Wie sieht der Aufbau bei stereo aus? 16bit Links und dann 16bit Rechts oder andersherum? MfG GamerBoy
GamerBoy schrieb: > Kann er, aber ich habe dann immer Probleme mit den Clocks. Beim auslesen > sind immer alle Werte 0 bis auf HCLK. Hm... Eine möglicher Workaround dafür wäre doch vielleicht, die Kernel-API in den Flash auszulagern, dort Funktionen zum Schreiben/Lesen der Clocks unterzubringen und diese dann einfach vom RAM aus aufzurufen? Ach ja: Bei der API muss man darauf achten, dass man einen gemeinsamen, nicht veränderlichen Einsprungpunkt für alle Funktionen hat - wenn man eine Funktion weiter vorne im Speicher verändert, verschieben sich ja alle Funktionen dahinter und die CALL-Adressen von alten Programmen sind dadurch dann falsch und springen ins Nirvana. Um das zu umgehen, habe ich es bei meinem Kernel so gemacht, dass ich einfach nach 08h CALLe und dem Kernel die Nummer der gewünschten Funktion übergebe, welche dann ausgeführt wird (mittels Sprungtabelle). So können die Adressen der eigentlichen Funktionen wechseln, und trotzdem funktionieren alte Programme weiter. Gruß Jonathan
Ich denke wir werden erstmal einfach nur feste Programme schreiben. Also nichts was man noch nachladen könnte. Wenn die erste Version gut funktionieren sollte, gucken wir mal wieviel Zeit wir noch haben und dann könnten wir sowas eventuell noch umsetzten.
GamerBoy schrieb: > Da das decodieren des MP3 Formats ja eigentlich erst > der externe Codec übernimmt. Dein STM kann selbst locker mehrere MP3-Dateien decodieren... GamerBoy schrieb: > Kann ich WAV Files direkt in ein Array konvertieren, oder ist das auch > Codiert? Wie sieht der Aufbau bei stereo aus? 16bit Links und dann 16bit > Rechts oder andersherum? Soll das Projekt von dir oder von uns gemacht werden? Diese Frage hättest du schneller selbst beantworten können, als das Schreiben dieser Frage gedauert hat.
Fallobst schrieb: > Dein STM kann selbst locker mehrere MP3-Dateien decodieren... Wir werden erstmal alle Sounds, die in Spielen vorkommen und gemixt werden in WAV PCM abspeichern und dann über 2 PWM Ausgänge abspielen. Alles andere machen wir dann mit MP3 Files. Fallobst schrieb: > Soll das Projekt von dir oder von uns gemacht werden? Diese Frage > hättest du schneller selbst beantworten können, als das Schreiben dieser > Frage gedauert hat. Mir war zuerst nicht ganz klar was PCM heißt, aber jetzt hab ich gefunden.
Hallo, statt beim Ausschalten mit einem Schalter den Akku zum Rest zu trennen, wollen wir alle Bauteile in den Schlafmodus bringen und anschließend den Stm32 in den Standbymodus, aus dem er mit dem SystemWakeup Pin A0 wieder erweckt wird. Backupbattery ist vorhanden. Das funktioniert auch mit so gut wie allen Teilen, aber das Xbee lässt sich nur mit einem Pin, der auf logisch high geschaltet wird, in den Schlafmodus bringen. Die Frage aber ist, wie wir das hinkriegen. Wir haben uns überlegt ein Logik-IC aus der 74'er Reihe zu verwenden. Und zwar den 74HCT04. Ein Inverter. Solange der Stm32 läuft würden wir den Eingang auf logisch high halten, sodass am Xbee ein logisches low ankommt. Aber was passiert wenn der Stm32 in den Standby geht. Laut Datenblatt: "In Standby mode, all I/O pins are high impedance" aber was bedeutet das bzw was liegt am Inverter Eingang für ein logik Pegel an? MfG Gamerboy
Mach doch einfach einen externen Pull-Up an die Leitung. Der Controller kann die Leitung dann runterziehen zum Einschalten des Xbee. GamerBoy schrieb: > "In Standby mode, all I/O pins are high impedance" aber was bedeutet das > bzw was liegt am Inverter Eingang für ein logik Pegel an? "High impedance" ist effektiv das selbe wie nicht verbunden. Der Pegel auf der Leitung hängt dann von den anderen angeschlossenen Bauteilen ab (Pull-Up/-Down Widerstände, extern oder integriert in den Bauteilen). Gibt es kein Pull-Up/-Down, ist der Pegel undefiniert.
Andreas B. schrieb: > Mach doch einfach einen externen Pull-Up an die Leitung. Der Controller > kann die Leitung dann runterziehen zum Einschalten des Xbee. Stimmt, da hab ich garnicht dran gedacht. Warum einfach wenns auch kompliziert geht ;) Danke
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.