Forum: Mikrocontroller und Digitale Elektronik Grafikdisplay mit SSD1289 mit XMEGA, DMA und 16bit Interface sehr schnell


von Felix H. (masterq)


Angehängte Dateien:

Lesenswert?

Ich hatte hier: Beitrag "XMEGA 16-bit DMA Burst Transfer für Display Parallel Bus" vor kurzen 
eine Anfrage gestellt.
Ich konnte das Problem inzwischen lösen.

Es war ein unheimliches gefrickel. Deshalb stelle ich den Code hier noch 
eben rein.

Fakten:
Das Ergebnis kann sich sehen lassen. Mit Übertakteten XMEGA erreiche ich 
33,3 Vollbilder aus dem Externen SRAM. Bei einer Auflösung von 240px * 
320px und 16bit per Pixel.
Das entspricht einer Transferrate von fast 5MByte/s. Wobei der 
Speicherbus zwar viel belegt ist aber die CPU fast dauerhaft frei.
Aus dem internen RAM geht es noch wesentlich schneller. Allerdings passt 
da kein Vollbild rein. Deshalb hatte ich keine Lust es genau zu testen.

Ich habe die Routine getestet mit dem TFT320_QVT mit SSD1289 Controller, 
welches für rund 10€ bei EBay zu haben ist. Es sollte allerdings auch 
Problemlos mit anderen Displays mit 16-Bit Interface funktionieren.


Anbindung:
Das ist meine Anschlusskonfiguration. Der Pin WR an PORTC PIN3 ist 
wichtig sonst muss ein anderer timer2 genutzt werden. Ansonsten kann man 
das wohl nach belieben machen:
1
#define SSD_LPORT    PORTA
2
#define SSD_HPORT    PORTB
3
4
#define SSD_CONTROL_PORT  PORTC
5
6
7
// control line pins
8
#define  LCD_CD_bm    PIN2_bm //RS
9
#define  LCD_WR_bm    PIN3_bm //LCMPD of TCC2
10
#define  LCD_RD_bm    PIN4_bm
11
#define  LCD_CS_bm    PIN5_bm
12
#define  LCD_RES_bm  PIN6_bm //Reset

Weitere Funkionen:
Für die Initialisierung des Displays und dessen commands habe ich mir 
eine kleine Bibliothek geschrieben. Die unterscheidet sich allerdings 
nur minimal von den vielen die im Netz verfügbar sind. Wenn sich dennoch 
jemand dafür interessiert bin ich gerne bereit zu teilen.


Verfahren:
Das verfahren ist Grundlegend so das 2 DMA Channel benutz werden um die 
Daten auf die Ports zu kopieren. Dann startet ein dritter DMA Kanal der 
ein Byte in das CNT registers des Timers 2 Kopiert welcher dann ein 
kurzen Puls generiert, damit die Daten vom Display übernommen werden. 
Auf den IRQ des Timers werden die DMA Kanäle dann erneut getriggert usw.

Die Routinen sind noch relativ stark im RAW Format, damit meine ich es 
sind alle noch nicht viele #define's gesetzt oder Makros definiert. So 
kann man sie wahrscheinlich am besten lesen.
Die Initialisierung für den EBI-Bus habe ich mal mit rein kopiert.


Format:
Die Bilder werden in Arrays erwartet welche diese Form haben:
uint8_t bild[2][height][width];
Wobei highbyte und lowbyte getrennt von einander gespeichert werden
bild[0] enthällt alle highbytes
und
bild[1] alle lowbytes.
Das ist leider nicht anderes möglich wenn man es schnell möchte. Stellt 
in der Praxis jedoch auch kaum ein Nachteil da.


Entwicklung:
Ich werde das ganze wahrscheinlich noch weiter entwickeln und in eine 
echte Bibliothek umwandeln. Wenn daran auch jemand Interesse hat gebe 
ich die Fortschritte gerne weiter.


Anmerkung:
Für Bugs, Vorschläge und Code Request habe ich ein offenes Ohr. Ich 
werde jedoch nur minimalen support zur Einrichtung geben und falls mir 
danach ist werde ich Anfragen ignorieren.

Viel Spaß und liebe Grüße
Felix

Nachtrag: Ein paar der Code-Kommentare in der main.c sind leider noch 
aus einer alten Version aber das merkt man schon. :)

: Bearbeitet durch User
von Felix H. (masterq)


Angehängte Dateien:

Lesenswert?

Habe nochmal die Kommentare angepasst.

von Arduinoquäler (Gast)


Lesenswert?

Felix H. schrieb:
> Es war ein unheimliches gefrickel.

Ja, tolles Gefrickel.

Und die Zeit die du zum Vereinzeln der beiden Bildhälften
brauchst, die zählt nicht zur Gesamt-Datenrate dazu?

Was macht es für einen Sinn ein Bild einmal zu erstellen und
dann immer wieder aufs Display zu schicken? Anders scheint
deine Vorgehensweise keinen Sinn zu machen

Wenn ich am Bild manipuliere kann ich das auch gleich direkt
ins Display schreiben ohne DMA zu machen. Das erspart die
Arbeit am Image im Speicher und das Umkopieren mittels DMA.

... oder ich habe die (weiterhin existierende?) Sinnhaftigkeit
noch nicht wirklich gesehen?

Felix H. schrieb:
> Fakten:
> Das Ergebnis kann sich sehen lassen.

Nur was machst du mit diesem Ergebnis? Die praktische Nutzung
geht gegen Null, ausser dass es auch "von hinten durch die
Brust ins Auge" funktioniert.

von Felix H. (masterq)


Lesenswert?

Hallo danke für deine Kritik,
ich habe die beiden Bildhälften separiert, so kann man das Bild ganz 
normal bearbeiten ohne größere Rechenlast, bzw mit den üblichen 
Einschränkungen.
Abgesehen von der Möglichkeit nur ein horizontale reduzierten Ausschnitt 
zu zeigen, was wirklich nur mit der CPU geht.
Aber es horizontal und Vertikal zu scrollen ist kein Problem, auch Teile 
zu ändern ist kein Problem.

Weiter muss kein Bild umformatiert werden weil ich einfach direkt in 
diesem Format arbeite. Meine Methoden mussten natürlich angepasst 
werden, aber das war kein großer Umstand.

Der Code den hochgeladen habe soll nur zur Anschauung dienen, was daraus 
gemacht wird ist demjenigen überlassen der damit arbeiten möchte. Oder 
wie ich es bei dir vermute nicht damit arbeiten möchte :)

Ich habe es für meinen Mario Clon geschrieben. In meiner ersten Version 
hatte ich nur weniger als 10 Frames das war zu wenig. Jetzt habe ich 
mehr als das 4fache und muss mir keine sorgen über Timings mehr machen.

Insgesammt funktioniert diese Methode ganz gut zum ausgeben von Sprites.

Was wirklich von hinten durch die Brust ist, ist das Arbeiten mit mehr 
als 64KB Ram auf einer AVR Platform ohne DMA. Jedenfalls mit AVR-GCC.

Aber ich kann mir leider nicht verkneifen eine kleine Kritik 
zurückzugeben. Wenn man Datenstrukturen nicht durchschaut und nicht viel 
Erfahrung hat sollte man etwas freundlicher fragen um sich weiter zu 
bilden oder auch einfach beim Arduino bleiben.

Beste Grüße
Felix

: Bearbeitet durch User
von H-G S. (haenschen)


Lesenswert?

Kannst du die Schaltung oder ein Blockdiagramm von der Speicheranbindung 
zeigen ?
Ist es ein System mit zwei kompletten Bildpuffern ?

Wieviel SRAM ist insgesamt im Spiel und was kann dieser AVR (kenn den 
gar nicht) ?

Edit: hat ein Bild 320x480= 150k mal 16bit Speicherbedarf ? Das ist ganz 
schön heftig.

: Bearbeitet durch User
von Felix H. (masterq)


Lesenswert?

Klar mache ich gerne habe auch ein schönes Board dazu. Ich habe 512 
KByte SRAM und eine SDCard. Die SDCard hängt allerdings nur an den 
Pin-Headern arbeite noch am Experimentierte Board. Bin gerade unterwegs. 
Lade die Dateien morgen hoch. Ich habe 512*240*2 Bytes im Speicher damit 
ich vorladen kann.

Liebe Grüße
Felix

von Felix H. (masterq)


Angehängte Dateien:

Lesenswert?

Hier das gewünschte Board.

Das Board:
Das Photo ist schon älter und zeigt das Board ohne das Display. Aber die 
Anschluss Konfiguration für das Display habe ich ja oben Gepostet.
Man beachte das die Reihenfolge des Data-Busses sowie die Reihenfolge 
des Adress-Busses egal ist.
Ich benutze übrigens den A1U nicht den A1.
Das Netzteil ist extern. Ich hatte keine Lust für alle meine 
Experimentierboards ein eigenes Netzteil mit auf die Platine zu bringen. 
Ein standardisiertes Netzteil spart Zeit und Geld.

SD-Card:
Zusätzlich habe ich mal den SD-Card Adapter mit gepostet. Weil ich den 
so liebe :) Der ist einfach so praktisch, aufstecken mit Strom versorgen 
Lib laden und schon hat man "uneingeschränkten" Speicher zu Verfügung.

Supply:
Nur für den Fall das es jemand nachbauen möchte, habe ich hier auch noch 
ein kleines Beispiel Netzteil mit hochgeladen. Es reicht allerdings auch 
das Board einfach mit einer stabilen 3V3 Spannung üben den Pinheader zu 
versorgen. Wer jedoch die USB-Schnittstelle benutzen möchte muss 
improvisieren oder Tastsächlich das Supplyboard mit fertigen.

Entschuldigt die Rechtschreibfehler, den letzten Beitrag habe ich auf 
dem Handy geschrieben.

Alle Schaltpläne und Boards sind meine Eigenentwicklungen. Ich freue 
mich wenn Sie jemand gebrauchen kann und von daher, kann und darf jeder 
der möchte meine Schaltpläne und Boards gerne nach belieben verändern 
und benutzen. Jedoch mit Folgenden Einschränkungen: Zum kommerziellen 
Gebrauch und zu weiteren Veröffentlichung ausserhalb dieses Threads 
möchte ich gefragt werden.

H-G S. schrieb:
> Edit: hat ein Bild 320x480= 150k mal 16bit Speicherbedarf ? Das ist ganz
> schön heftig.

Neben den Bild+Scroll Area liegen auch noch meine Sprites im Speicher 
die sind aber verhältnismässig winzig und können gelegentlich über die 
SDCard nachgeladen werden.

Hoffe ich konnte dir helfen
Felix

: Bearbeitet durch User
von Rahmon (Gast)


Lesenswert?

Guten Tag. Veröffentlichen Sie bitte den Code für 8-Bit. Ich habe ein 
Display von Nokia 6280 - ein Datenbus von 8 Bit xmega Controller 128a4u

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.