Forum: Projekte & Code TFT 480x272 am LPC2478


von Erwin R. (er-tronik)


Angehängte Dateien:

Lesenswert?

Für alle, die in den letzten Wochen das TFT-Display KWH040GM05-F02 
(480x272x3) bekommen haben, und es an den LPC2478 anschließen wollen, 
habe ich hier eine einfache Initsequenz für SDRAM und Display 
zusammengefaßt. Auf dem Foto könnt ihr meinen Versuchsaufbau erkennen. 
Um das Beispiel zu kompilieren, braucht ihr natürlich noch den 
Startup-Code für den LPC2478, Taktfrequenz ist bei mir 72 MHz, daraus 
wird der 9 MHz Display-Takt erzeugt.

Erwin

von Star K. (starkeeper)


Lesenswert?

Jo das sieht schon mal gut aus. Das gleiche habe ich auch gerade vor, 
bin aber noch nicht so weit..

Wie hast du das Display angeschlossen? Ist das direkt angeschlossen, mit 
Transceiver, 16Bit oder 24Bit?

von Erwin R. (er-tronik)


Lesenswert?

Das Display ist direkt am Controller mit 24 Bit angeschlossen. Kann aber 
auch im 16 Bit Modus betrieben werden, es müssen nur 2 Zeilen im Code 
geändert werden:
1
PINSEL11 |= 0x0000000B;
2
LCD_CTRL = BIT(5) | BIT(8) | (6 << 1);  // TFT, RGB, 5:6:5 Bit

Erwin

von Tobias P. (hubertus)


Lesenswert?

Hallo,
danke für den Code, sowas brauche ich dann auch bald, wenn meine 
Leiterplatte kommt ;)
Noch ne Frage.
Hab grade auf der NXP-Website den LCD Bus Load calculator gefunden, und 
ich komme bei 24 Bits pro Pixel und 480 x 272 auf eine Buslast von fast 
50%. ISt das nicht schon verdammt viel? Kann man das externe DRAM dann 
überhaupt noch für irgendwas sinnvolles brauchen oder wird das dann 
einfach extrem langsam?
Des weiteren wollte ich am externen Bus eigentlich noch diverse 
Peripherie anbinden, aber ich weiss nicht, ob das wirklich eine gute 
Idee ist, bei 50% Buslast allein durch das LCD....

von Star K. (starkeeper)


Lesenswert?

Also ich komme mit dem calculator für den LPC2478 auf 40% Buslast. Wobei 
dieser Wert nur eine Grobe schätzung sein kann. Denn die Buslast hängt 
stark von der Anwendung und deren Design ab.

Der LPC2478 verfügt ja über mehrere Busse, wie man im Datenblatt auf 
Seite 5 sehen kann.

Bsp 1:
Wenn die CPU code aus dem Flash verarbeitet und nur den lokalen RAM 
verwendet und die Bilder für das LCD im externen RAM liegen, kann das 
LCD so viel Last verursachen wie es will. Es wird die CPU nicht 
aufhalten, da nur von einander getrennte Busse verwendet werden.

Gleichzeitig könnte die CPU den Ethernet-Controller versorgen, ohne dass 
der Bus an dem das LCD hängt beeinflusst würde.

Bsp 2:
Der schlechteste Fall wäre wenn du die Display-Bilder im internen 
RAM/Flash hast und gleichzeitg versuchst die Daten des 
Ethernet-Controller mit der CPU in einen externen RAM zu kopieren. Dann 
würde jeder dieser Vorgänge alle Busse beanspruchen.

Alles in allem ist das Busdesign des LPC2478 auf den ersten Blick etwas 
ungünstig verteilt, da eigentlich die gesamte Peripherie an AHB1 hängt. 
Besser wäre es da gewesen den APB-Teil an AHB2 zu hängen. Das hätte 
wiederrum sicherlich Mehrkosten verursacht, da man dann einen weiteren 
DMA-Controller braucht. Man kann nähmlich nicht direkt von AHB1 auf AHB2 
zugreifen, das geht nur in die andere Richtung. Und sicherlich gibt es 
da noch mehr Gründe warum die Brüder von NXP das so gemacht haben..

von Tobias P. (hubertus)


Lesenswert?

Also, dummerweise ist es eben so, dass ich in einigen einzelnen Fällen 
eben auch gewisse Codeteile im externen RAM habe. Auch der Heap liegt 
da, und im Heap wird bei mir so einiges Gespeichert (bspw. sind die 
ganzen Buffer, welche ich für das File-Management brauche, im Heap). 
Macht das dann was aus?
Andererseits liegt ja z.B. bei Pocket PCs der gesamte Code meist in 
einem externen Flash, und der Mikrocontroller steuert gleichzeitig noch 
das Display an.

von Star K. (starkeeper)


Lesenswert?

@Erwin Reuss
Irgendwie funktioniert dein Code bei mir nicht richtig. Der Controller 
scheint sich aufzuhängen, wenn folgende Zeile der EMC initialisierung 
druchlaufen wird:
1
/* Mem clock enable, CLKOUT runs, send command: NOP */
2
  EMC_DYN_CTRL = 0x00000183;

Sobald die Zeile durchlaufen wurde, kann ich nicht mehr debuggen. Ich 
muss dann einen reset machen um mich wieder mit dem Debugger auf den 
Chip verbinden zu können. Ist dir sowas schon mal untegekommen?

Ich habe deinen Code nur wenig verändert. Ich habe noch den PLL 
initialisiert und so den Takt auf 72MHz festgelegt und außerdem das 
MAM-Modul gesetartet.

Außerdem habe ich den DRAM-Typ geändert, da ich einen ISSI IS42S32800B 
angeschlosse habe. Dazu habe ich folgende Zeile geändert:
1
/*  EMC_DYN_CFG0    = (1 << 14) | (0 << 12) | (2 << 9) | (2 << 7); // 4M x 32 in 4 banks */
2
   EMC_DYN_CFG0    = (1 << 14) | (0 << 12) | (3 << 9) | (2 << 7); // 8M x 32 in 4 banks

Die Timinigs usw. sollten eigentlich identisch sein. Deshalb habe ich 
keine Ahnung wo mein Problem liegt. Hast du ev. noch weitere 
initialisierungen vorgenommen, bevor du das EMC startest?

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.