Wie sollte man beim Entwerfen eines ARM-basierten Geräts, das einfache Grafiken auf einem Farb-LCD anzeigen soll, vorgehen, um schnelle Aktualisierungen zu ermöglichen, vorzugsweise ohne an einen bestimmten ARM- oder LCD-Hersteller gebunden zu sein? In meinem aktuellen Projekt wird eine Schwarzweißanzeige verwendet, die über den SPI-Anschluss eines PIC blitzschnell gesteuert werden kann (Neuzeichnen einer komplexen Anzeige in 1/60 Sekunde). Es scheint, dass herkömmliche Farb-LCD-Displays einen SPI-Anschluss haben, aber selbst das Befüllen eines 160 x 120-LCD mit einer Volltonfarbe würde 30 ms dauern, und ein 320 x 240 würde im besten Fall 120 ms dauern (10-MHz-Takt).
Wenn man die Controller-Pins schonen könnte, könnte der Parallelmodus besser sein, aber ich kenne keine familienunabhängige Methode zum Anschließen der parallelen Schnittstelle, ohne dass drei separate Speicheranweisungen für jedes Pixel erforderlich sind (eine zum Einstellen der Daten, eine, um den Taktausgang hoch und eine, um ihn niedrig zu takten). Einige ARM-Chips haben Speicher-Bus-Schnittstellen, aber diese möchten oft Dinge wie Multiplexen von Adressen und Daten oder viele Pins für die Ausgabe irrelevanter Adressbits (das LCD würde nur ein Adressbit benötigen).
Ein interessanter Ansatz für die ILI9320 von ILITEK oder die HD66789 von Renesas wäre die Verwendung einer CPLD zur Konvertierung von SPI in parallele Daten und die Verwendung eines Modus, der ein Pixel pro Bit ausgibt. Wenn Sie sich das Datenblatt von Renesas ansehen, können Sie möglicherweise mit minimaler Hardware Pixel-pro-Bit-Schreibvorgänge durchführen (keine CPLD erforderlich), indem Sie alle parallelen Datenbits auf den seriellen Datenpin legen und den seriellen Modus für alles außer Pixel verwenden Schreiben und Verwenden der Vergleichs- / Maskenfunktionen, so dass entweder nur Nullen Pixel transparent sind und nur Einsen Pixel ausgewählte Bits in GRAM setzen, oder nur Einsen Pixel transparent sind und nur Nullen Pixel ausgewählte Bits löschen. Der Abschnitt "Eigenschaften" des IKITEK-Datenblattes weist auf eine ähnliche Funktionalität hin, die Registerkarten enthalten jedoch keine
Angenommen, der Code zeigt hauptsächlich einfarbigen Text und Grafiken. Der ideale Ansatz wäre die Verwendung einer CPLD, um den SPI-Port des ARM mit dem parallelen Port des Displays zu verbinden und das Laden der CPLD mit Vordergrund- / Hintergrundfarben zu ermöglichen. Dies wäre besonders schön, wenn man "transparente" Pixel schreiben könnte. Bei einer Schriftart als zweifarbige Bitmap können die Schriftartdaten einfach direkt in den SPI-Port geladen werden. Auf diese Weise könnten Schriftdaten alle zwei ARM-Takte mit einer Rate von einem Pixel angezeigt werden. Andererseits würde eine CPLD, die ausreicht, um eine solche Anzeigesteuerungsaufgabe auszuführen, etwa 2 USD kosten.
Wie lässt sich ein ARM am besten mit einem Farb-LCD verbinden, wenn hauptsächlich einfarbiger Text oder einfache (z. B. 16-Farben- oder 64-Farben-) Grafiken angezeigt werden sollen?
Bearbeiten
Ich habe viele LCD-Anzeigeprojekte mit vielen Arten von LCDs durchgeführt, einschließlich Zeichenmodus-LCDs, benutzerdefinierten 3: 1-Multiplex-LCDs mit eigener Ansteuermethode, grafischen Schwarzweiß-LCDs mit integrierten Controllern und Schwarzweiß-LCDs -weiße LCDs, für die ich meinen eigenen CPLD-basierten Controller entwickelt habe, der mit dem Allzweck-DMA eines Mikrocontrollers (der sogar vier Graustufen bietet) kompatibel ist. Ich bin stolz darauf, Displays flott zu machen. Einer der Grafik-Controller war ein bisschen wie ein Hund, der ungefähr 1/10 Sekunde für eine Vollbildaktualisierung benötigte, selbst wenn konstante Daten geschrieben wurden, aber die meisten meiner Displays können sogar ein ziemlich komplexes Bild in weniger als 1/50 Sekunde rendern.
Viele meiner Projekte sind batteriebetrieben, daher ist die Stromaufnahme ein Problem. Den DMA-basierten Display-Controller habe ich gut gemacht, aber es war für ein zeilenbetriebenes Projekt. Ich glaube, die einzige Möglichkeit, eine vernünftige Stromaufnahme von einem Grafik-LCD zu erhalten, ist die Verwendung eines Controllers, der den Anzeigepuffer und die Spaltentreiber kombiniert. Das Senden einer großen Anzahl von Anzeigen zwischen Chips pro Frame würde selbst bei einer einzelnen Bit-pro-Pixel-Anzeige viel Energie verschwenden. Auf einem Farbdisplay mit 16 Bit pro Pixel wäre es weitaus schlimmer.
Ich habe erst angefangen, Farb-LCD-Datenblätter zu betrachten. Viele Displays scheinen einen Controller zu verwenden, der dem ILITEK ILI9320 ähnelt, obwohl alle Datenblätter, die ich für Controller gefunden habe, die auf diesem allgemeinen Design basieren, mit "vorläufig" gekennzeichnet sind. Einige wie die ILITEK one behaupten, Maskierungs- und Transparenzfunktionen zu haben, listen jedoch keine Register für diese auf. Ich weiß nicht, ob die echten Chips solche Merkmale haben, aber die "vorläufigen" Datenblätter sie nicht enthalten, oder ob sie die Merkmale weggelassen haben, aber vergessen haben, sie zu erwähnen. Wenn in der Praxis alle derartigen Chips Transparenzmerkmale aufweisen, erscheint es vernünftig, für sie zu entwerfen; wenn nicht, nicht
Ich würde erwarten, dass für die meisten Projekte ein typischer Bildschirm aus beliebig platziertem Text in einer moderaten Anzahl von einfarbigen Schriften beliebiger Größe besteht. Schriftarten würden höchstwahrscheinlich als Bit-pro-Pixel-Daten gespeichert. Wenn ich mit einem Cortex-M3 die Anzeige mit parallelen Daten schreiben wollte, würde die "innere Schleife" des Codes zum Schreiben von zwei Pixeln wahrscheinlich ungefähr so aussehen:
rol r0, r0, # 2; Holen Sie sich ein Bit in C, das andere in N itcs strhcs r1, [r3, # DATA_OFS]; Daten schreiben strhcc r2, [r3, # DATA_OFS]; Daten schreiben strb r4, [r3, # CLOCK_SET_OFS]; Uhr hoch stellen strb r4, [r3, # CLOCK_CLR_OFS]; Uhr niedrig stellen itmi strhmi r1, [r3, # DATA_OFS]; Daten schreiben strhpl r2, [r3, # DATA_OFS]; Daten schreiben strb r4, [r3, # CLOCK_SET_OFS]; Uhr hoch stellen strb r4, [r3, # CLOCK_CLR_OFS]; Uhr niedrig stellen
Nicht gerade das schnellste Ding der Welt. Das Beseitigen der Schreibvorgänge für die Anweisungen zum Setzen / Löschen der Uhr würde helfen. Meine Vermutung wäre, dass es keinen netten architekturunabhängigen Weg gibt, um beide Taktschreibvorgänge zu eliminieren, aber es könnte einen ziemlich verbreiteten Weg geben, um einen zu eliminieren (z. B. können viele Chips einen Zähler / PWM haben, der dazu gebracht werden könnte, einen Ausgang zu pulsieren kurz als Antwort auf einen einzelnen Speichervorgang).
Die Verwendung des SPI-Ports und das Hinzufügen von Hardware zum Takten eines Pixels pro Bit würde den Zugriff auf die Anzeige erheblich beschleunigen. Bei Verwendung einer Anzeige ohne Maskierung und Transparenz müsste die CPLD einen Adressenzähler enthalten und für jedes Pixel entweder ein Wort mit Pixeldaten takten oder einen Befehl zum Festlegen der Adresse für die Position des folgenden Pixels (für den ein Zähler erforderlich wäre) ). Wenn eine Anzeige hingegen Maskierung und Transparenz hätte, wäre alles, was ich tun müsste, eine CPLD-Unterstützung für einen Modus zu haben, in dem nach dem Takten mit 16 Bits jedes zusätzliche Bit ein Datenwort mit dem auf die Anzeige überträgt LSB-Tracking des SDI-Pins (möglicherweise ist nicht einmal die Verwendung einer CPLD erforderlich - nur ein paar normale Logikchips). Ich würde die Transparenzfarbe auf die Farbe setzen, die ich schreiben möchte, aber mit gespiegeltem LSB.
Ich möchte kein schönes Design entwickeln, das auf Maskierung und Transparenz beruht, und dann feststellen, dass die einzigen Displays mit solchen Merkmalen eine Vorlaufzeit von 30 Wochen haben. Auf der anderen Seite möchte ich nicht zulassen, dass Paranoia über die Verfügbarkeit mich dazu veranlasst, ein minderwertiges Design zu verwenden, wenn solche Displays bei vielen Anbietern verfügbar sind und bleiben.
