Microcontroller Ansteuerung von TFTs leichtgemacht

Baustein zur Ansteuerung von TFT-Panels
Baustein zur Ansteuerung von TFT-Panels

Der wichtigste Zielmarkt für RZ/A-Bausteine von Renesas sind Mensch-Maschine-Schnittstellen (HMI), bei denen der Baustein zur Ansteuerung von TFT-Panels eingesetzt wird. Die RZ/A-Produktfamilie ist eine Embedded-MPU-Lösung auf der Basis eines ARM Cortex-A9 mit einer Reihe von Vorteilen für HMI-Anwendungen. Der Artikel erläutert die Anforderungen für diesen Einsatzbereich und zeigt, wie die RZ/A- Familie diese Anforderungen erfüllt und welche systemrelevanten Vorteile diese Bausteine für Systementwickler bieten.

Im Juli 2013 hat Renesas seine neueste Mikroprozessor-Plattform vorgestellt – die RZ/A-Familie. Diese enthalten bis zu 10 MB integrierten SRAM und bieten damit mehr Embedded-SRAM als irgendein anderer Baustein auf dem Markt. Renesas konzipierte diese Produktfamilie für den HMI-Markt zur Ansteuerung von mittleren bis großen TFT-Panels.

Dieser Markt wächst mit enormer Geschwindigkeit. Bevor Apple die Welt im Sturm eroberte, gab es unter Technikern häufig eine geringschätzige Diskussion darüber, wer eigentlich „ein Farbdisplay an seinem Telefon benötigt“. Nicht wenige lagen dabei falsch. Offenbar wünschen sich viele Kunden Farbdisplays auf Telefonen – und das gilt nicht nur für Mobiltelefone. Die Zahl der Kaffeemaschinen, Kühlschränke, Verkaufsautomaten und ähnlicher Geräte mit TFT-Panels wird in den kommenden Jahren noch erheblich zunehmen. Beispielsweise ersetzen Geschäfte die Plastikunterlage, auf der man normalerweise Belege unterschreibt, jetzt durch 7-Zoll-TFT-Displays, die Werbung für die im Geschäft angebotenen Produkte zeigen. Die Zunahme dieses sog. „bathroom advertising“ in Europa sowie auch weltweit zeigt, dass TFT-Panels bald allgegenwärtig sein werden.

Anwendungsanforderungen

Der Kern des Problems betrifft die Ansteuerung von TFTs – was benötigt man dafür? Die meisten heutigen TFT-Panels nutzen eine digitale RGB-Schnittstelle – RGB888 oder RGB565. Der RGB-Wert ist normiert; dabei stehen die aufgeführten Zahlen für die Auflösung in Bit für die verschiedenen Farben eines jeden Pixels in Rot, Grün und Blau. Bei 888 stehen für jeden Kanal 8 bit an Daten (also insgesamt 24 bit pro Pixel) zur Verfügung, während bei 565 Rot und Blau mit 5 bit und Grün mit 6 bit (also insgesamt 16 bit pro Pixel) dargestellt werden. Als Alternative könnte ein Bildschirm auch anstelle einer standardisierten digitalen Schnittstelle eine LVDS-Schnittstelle nutzen, wie dies zunehmend bei größeren Bildschirmen üblich ist. Die eigentlichen RGB-Signale werden in Form eines differenziellen Signals übertragen, das Datenformat aber bleibt unverändert. Für den Anfang benötigt man daher einen Baustein, der die Erzeugung eines RGB-Signals unterstützt und/oder eine LVDS-Schnittstelle enthält.

Darüber hinaus müssen die RGB-Daten aus einem Frame-Puffer kommen, der typischerweise im RAM abgelegt ist. Dieser Frame-Puffer ist ein Bitmap-Bild, das im gewünschten Format gespeichert wurde. So benötigt etwa ein WVGA-Display (Auflösung 480 × 800) zur Speicherung eines RGB888-Bildes etwas mehr als 1 MB RAM (480 × 800 × 24 bit = 1,1 MB).

Neben dem erwähnten Frame-Puffer, in dem das aktuell auf dem Display gezeigte Bild gespeichert ist, verfügt eine typische Anwendung auch über einen nicht sichtbaren Bildspeicher-Bereich (“Back Buffer”), der das nächste Bild enthält, das an den Bildschirm weitergeleitet wird. So kann die CPU das nächste Bild bearbeiten, ohne dass der Benutzer ein halb bearbeitetes Bild auf dem Display aufflimmern sieht, bevor die CPU damit fertig ist. Ein solches Doppelpuffer-System ist weit verbreitet und verbessert die Qualität der HMI, erfordert jedoch andererseits bei einem WVGA-Display zusätzlich 1,1 MB RAM für den Puffer.

Leider ist damit das Thema RAM noch nicht abgeschlossen. Bei einer typischen HMI-Anwendung ist es nicht immer notwendig, den Inhalt des gesamten Bildschirms zu bearbeiten. Drückt man zum Beispiel auf ein Icon oder einen Button, dann könnte dazu eine Animation ablaufen: Das Icon leuchtet entweder auf, es dreht sich oder reagiert auf irgendeine andere Weise, bevor die Aktion ausgeführt wird. Für einen solchen Fall würde der HMI-Entwickler eine weitere Bildebene definieren. Dann gäbe es eine Hintergrund-Ebene, die unverändert bliebe, und das Icon oder der Button wäre auf der Vordergrundebene, auf der die Animation ablaufen würde. Natürlich benötigt dies zusätzliches RAM, allerdings nicht für das gesamte Display, sondern lediglich etwas mehr. Wie viel, hängt von der Größe des Bildes ab, aber bei einem Button mit 200 × 200 Pixeln wären das zusätzlich 100 kB RAM. Ebenfalls erforderlich ist es, die verschiedenen Ebenen untereinander überblenden zu können, und gegebenenfalls ein gewisses Maß an Transparenz für einige dieser Bilder geltend zu machen. Dies lässt sich per Software erledigen, wenn die CPU schnell genug ist, oder per Hardware, falls solche zur Verfügung steht.

Um also die Liste der RAM-Anforderungen zu vervollständigen, kann eine realistische HMI-Anwendung für einen Bildschirm im WVGA-Format RAM in der Größenordnung von 3 MB belegen. Wenn der Code ebenfalls im RAM abläuft, wie dies bei den meisten Prozessoren der Fall ist, dann benötigt man weitere 0,5 MB für den Code. Daher sollte man für ein WVGA-Display nach einem System suchen, das mindestens 3,5 MB RAM bieten kann.

Selbstverständlich ist auch die RAM-Zugriffsgeschwindigkeit sehr wichtig, da mehrere unterschiedliche Quellen gleichzeitig auf das RAM lesend und schreibend zugreifen. So wird zum Beispiel der Front-Puffer (für die ursprünglichen Bilddaten) von dem IP-Block gelesen, der das Display zur Anzeige der Daten ansteuert. Gleichzeitig wird der Back-Puffer von der CPU aktualisiert oder per DMA-Transfer mit einem anderen Bild gefüllt (Bild 1). Ebenfalls zur selben Zeit könnte die CPU das zuvor erwähnte Icon manipulieren und ihren eigenen Code aus dem RAM lesen. Damit wird die Bus-Bandbreite zum RAM stark in Anspruch genommen. In vielen Anwendungen ist dieser Bus der Flaschenhals, weshalb man daher eine leistungsfähige Bus-Systemarchitektur benötigt, um die Risiken einer Bus-Überlastung zu vermindern. Ein solches System hilft auch, die Anzeige von unvollständig bearbeiteten Bildern zu vermeiden oder schlimmstenfalls eine nicht funktionierende GUI.

Besondere Aufmerksamkeit verdient auch die Rechenleistung der CPU. Ein System, das 24 Frames pro Sekunde an das Display liefern soll, muss Daten (in unserem Fall für ein WVGA-Display) mit einer Datenrate von mehr als 24 MB/s manipulieren und erzeugen. Dies lässt sich komplett per Software oder in manchen Fällen auch in Hardware erledigen; jedoch was immer auch geschieht, die CPU muss zur Erfüllung dieser Anforderungen schnell genug arbeiten.

Daraus folgt als nächste Anforderung eine Verbindung zu externem Flash-Speicher. Meist verwendet man heute dafür einen externen, parallelen NOR-Flash-Speicher. Dieser enthält den Code und überträgt diesen beim Hochfahren ins RAM, um eine schnelle Ausführung zu ermöglichen. Allerdings unterstützen neuere Bausteine auch andere Speichertechnologien, mit denen Systementwickler die Systemkosten ohne den zusätzlichen Aufwand eines „teuren“ NOR-Flash-Speichers auf der Leiterplatte senken können. Die meisten dieser Anwendungen erledigen in der Regel mehr, als nur einen Bildschirm anzusteuern. Dazu müssen sie auch mit dem Rest des Systems verbunden sein. Automotive-Anwendungen sind typischerweise an einen CAN- oder MOST-Bus angeschlossen. Industrielle und Konsumelektronik-Bausteine benötigen heute meist Ethernet- und USB-Verbindungen. Aufgrund dieser Verbindungen muss das am besten geeignete Produkt nicht nur das Hardware-IP enthalten – es muss auch genügend Leistung für die Ausführung sowie ausreichend Code-Speicherplatz zur Unterstützung der entsprechenden Stacks bieten.