Effiziente Anzeige einfacher Texte/Grafiken auf einem Farb-LCD von ARM

Wie sollte man beim Entwerfen eines ARM-basierten Geräts, das einfache Grafiken auf einem Farb-LCD anzeigen soll, am besten vorgehen, um schnelle Updates zu ermöglichen, vorzugsweise ohne an einen bestimmten ARM- oder LCD-Anbieter gebunden zu sein? Mein aktuelles Projekt verwendet ein Schwarz-Weiß-Display, das blitzschnell von einem SPI-Port auf einem PIC angesteuert werden kann (Neuzeichnen eines komplexen Displays in 1/60 Sekunde). Es scheint, dass übliche Farb-LCD-Displays einen SPI-Anschluss haben, aber selbst das Fü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-Verschiebungstakt).

Wenn man die Controller-Pins sparen könnte, könnte der Parallelmodus besser sein, aber ich kenne keine familienunabhängige Möglichkeit, die parallele Schnittstelle anzuschließen, ohne drei separate Speicheranweisungen für jedes Pixel zu benötigen (eine zum Einstellen der Daten, eine, um den Taktausgang hoch zu setzen, und eine, um ihn niedrig zu takten). Einige ARM-Chips haben Speicherbus-Schnittstellen, aber diese möchten oft Dinge wie das Multiplexen von Adressen und Daten tun oder viele Pins für die Ausgabe irrelevanter Adressbits festlegen (das LCD würde nur ein Adressbit benötigen).

Betrachtet man den ILI9320 von ILITEK oder den HD66789 von Renesas, wäre ein Ansatz, der interessant erscheinen würde, die Verwendung eines CPLD zur Konvertierung von SPI in parallele Daten und die Einbeziehung eines Modus, der ein Pixel pro Bit ausgeben würde. Wenn man sich das Renesas-Datenblatt ansieht, ist es möglicherweise möglich, Pixel-pro-Bit-Schreibvorgänge mit minimaler Hardware (kein CPLD erforderlich) zu erhalten, indem alle Datenbits des parallelen Anschlusses den seriellen Daten-Pin verfolgen und den seriellen Modus für alles außer Pixel verwenden schreibt, und Verwenden der Vergleichs-/Maskierungsfunktionen, so dass entweder Pixel, die nur aus Nullen bestehen, transparent sind und Pixel, die nur aus Einsen bestehen, ausgewählte Bits im GRAM setzen würden, oder Pixel, die nur aus Einsen bestehen, transparent sind und Pixel aus ausschließlich Nullen ausgewählte Bits löschen würden. Der Abschnitt "Features" des IKITEK-Datenblatts schlägt vor, dass es eine ähnliche Funktionalität hat, aber die Registerkarten nicht

Unter der Annahme, dass der Code hauptsächlich einfarbigen Text und Grafiken anzeigt, scheint der ideale Ansatz darin zu bestehen, ein CPLD zu verwenden, um den SPI-Port des ARM mit dem parallelen Port des Displays zu verbinden und zu ermöglichen, dass das CPLD mit Vorder- / Hintergrundfarben geladen wird. Dies wäre besonders schön, wenn man eine Möglichkeit hätte, "transparente" Pixel zu schreiben. Bei einer Schriftart als zweifarbige Bitmap könnte man die Schriftartdaten einfach direkt in den SPI-Port laden; dies würde ermöglichen, dass Schriftdaten alle zwei ARM-Takte mit einer Rate von einem Pixel angezeigt werden. Andererseits würde ein CPLD, das ausreicht, um eine solche Anzeigesteuerungsaufgabe zu bewältigen, etwa 2 US-Dollar kosten.

Was ist der beste Weg, um einen ARM mit einem Farb-LCD zu verbinden, wenn das Ziel darin besteht, hauptsächlich einfarbigen Text oder einfache (z. B. 16-farbige oder 64-farbige) Grafiken anzuzeigen?

Bearbeiten

Ich habe viele LCD-Display-Projekte mit vielen Arten von LCDs durchgeführt, einschließlich Zeichenmodus-LCDs, benutzerdefinierter 3: 1-Multiplex-Segment-basierter Verwendung meiner eigenen Antriebsmethode, Schwarzweiß-Grafik-LCDs mit integrierten Controllern und Schwarz-und -weiße LCDs, für die ich meinen eigenen CPLD-basierten Controller entwickelt habe, um eine Schnittstelle mit dem Allzweck-DMA eines Mikrocontrollers herzustellen (der sogar vierstufige Graustufen bereitstellt). Ich bin stolz darauf, Displays flink zu machen. Einer der Grafikcontroller war ein bisschen wie ein Hund, der etwa 1/10 Sekunde für eine vollständige Bildschirmaktualisierung 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 der Projekte, die ich mache, sind batteriebetrieben, daher ist die Stromaufnahme ein Problem. Der DMA-basierte Display-Controller, den ich gemacht habe, hat gut funktioniert, aber er war für ein netzbetriebenes Projekt. Ich glaube, die einzige Möglichkeit, eine vernünftige Stromaufnahme aus einem Grafik-LCD zu erzielen, besteht darin, einen Controller zu verwenden, der den Anzeigepuffer und die Spaltentreiber kombiniert. Das Senden einer großen Anzeige zwischen den Chips in jedem Frame würde selbst bei einer Anzeige mit einem einzigen Bit pro Pixel viel Energie verschwenden. Auf einem Farbdisplay mit sechzehn Bit pro Pixel wäre es weitaus schlimmer.

Ich habe nur angefangen, mir Farb-LCD-Datenblätter anzusehen; Viele Displays scheinen einen ähnlichen Controller wie den ILITEK ILI9320 zu verwenden, obwohl alle Datenblätter, die ich für Controller gefunden habe, die auf diesem allgemeinen Design basieren, als "vorläufig" gekennzeichnet wurden. Einige wie die von ILITEK behaupten, Maskierungs- und Transparenzfunktionen zu haben, listen aber keine Register dafür auf; Ich weiß nicht, ob die echten Chips solche Funktionen haben, aber die "vorläufigen" Datenblätter haben sie nicht aufgenommen, oder ob sie die Funktionen weggelassen, aber vergessen haben, sie zu erwähnen. Wenn in der Praxis alle diese Chips Transparenzmerkmale haben, 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 willkürlich platziertem Text in einer moderaten Anzahl von einfarbigen Schriftarten beliebiger Größe besteht. Schriftarten würden höchstwahrscheinlich als Bit-pro-Pixel-Daten gespeichert werden. 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 so enden:

  Rolle 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] ; Stellen Sie die Uhr hoch
  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] ; Stellen Sie die Uhr hoch
  strb r4,[r3,#CLOCK_CLR_OFS] ; Uhr niedrig stellen

Nicht gerade das schnellste Ding der Welt. Das Eliminieren der Schreibvorgänge in die Anweisungen zum Setzen/Löschen der Uhr würde helfen. Meine Vermutung wäre, dass es keine nette architekturunabhängige Möglichkeit gibt, beide Taktschreibvorgänge zu eliminieren, aber es kann eine ziemlich übliche Methode geben, die es ermöglicht, einen zu eliminieren (z kurz als Reaktion auf eine einzelne Speicheroperation).

Die Verwendung des SPI-Ports und das Hinzufügen von Hardware zum Takten von einem Pixel pro Bit würde den Anzeigezugriff erheblich beschleunigen. Wenn ein Display ohne Maskierung und Transparenz verwendet wird, müsste das CPLD einen Adresszähler enthalten und für jedes Pixel entweder ein Wort mit Pixeldaten oder einen Set-Adress-Befehl für die Position des folgenden Pixels takten (für das es einen Zähler benötigen würde). ). Wenn dagegen ein Display Maskierung und Transparenz hätte, müsste das CPLD nur einen Modus unterstützen, in dem nach dem Eintakten von 16 Bit jedes zusätzliche Bit ein Datenwort mit dem an das Display ausgibt LSB-Tracking des SDI-Pins (es ist möglicherweise nicht einmal erforderlich, ein CPLD zu verwenden - nur ein paar normale Logikchips). Ich würde die Transparenzfarbe auf die be-Farbe setzen, die ich schreiben möchte, aber mit umgedrehtem LSB.

Ich möchte kein schönes Design entwickeln, das auf Maskierung und Transparenz beruht, und dann feststellen, dass die einzigen Displays mit solchen Funktionen eine Vorlaufzeit von 30 Wochen haben. Auf der anderen Seite, wenn solche Displays bei vielen Anbietern weit verbreitet sein und bleiben, möchte ich mich nicht von Paranoia über die Verfügbarkeit dazu bringen lassen, ein minderwertiges Design zu verwenden.