STM32F4 "Gameboy"

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.

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.

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).

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)

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)

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

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-

@vampire (Gast)
:-)

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

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

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

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