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
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?
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
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....
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..
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.
@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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.