mikrocontroller.net

Forum: Projekte & Code TFT 480x272 am LPC2478


Autor: Erwin Reuss (er-tronik)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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

Autor: Star Keeper (starkeeper)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Erwin Reuss (er-tronik)
Datum:

Bewertung
0 lesenswert
nicht 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:
PINSEL11 |= 0x0000000B;
LCD_CTRL = BIT(5) | BIT(8) | (6 << 1);  // TFT, RGB, 5:6:5 Bit

Erwin

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht 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....

Autor: Star Keeper (starkeeper)
Datum:

Bewertung
0 lesenswert
nicht 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..

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Star Keeper (starkeeper)
Datum:

Bewertung
0 lesenswert
nicht 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:
/* Mem clock enable, CLKOUT runs, send command: NOP */
  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:
/*  EMC_DYN_CFG0    = (1 << 14) | (0 << 12) | (2 << 9) | (2 << 7); // 4M x 32 in 4 banks */
   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?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.