Vollgrafikanzeige mit Grafikbibliothek und Touchscreen

Huh, da muss man auch noch eine fette Java-Programm­installation über sich ergehen lassen. Für jedes Betriebs­system extra, na klar. Robuste Software sieht anders aus! Mit Arduino hatte ich bis jetzt nichts zu tun. Wie ich sogleich sah, das war auch gut so:

• Die Software ist riesengroß aber ohne Debugger auch bloß ein Texteditor.
• Außer Syntaxhervorhebung bietet die Software nichts. Kein IntelliSense, nicht mal ansatzweise. Gerade Programmier-Anfänger sind auf Schreibunterstützung und Kontexthilfe angewiesen.
• Kontextsensitive Hilfe ist nicht. Deutsch auch nicht. Die paar deutschen Menüeinträge helfen da nicht drüberweg.
  Eine deutsche Übersetzung des ATmega328-Datenblatts liegt seit Mai 2016 vor: 5,5 MByte CHM statt 32 MByte PDF, trotzdem ist alles drin!
• Funktionstasten sind lieblos verteilt, dafür gibts Vorbilder.
• Obwohl gcc-basiert ist alles völlig anders als beim WinAVR: 100 % umlernen für das gleiche System. Die Pinzuordnung ist ganz Arduino-typisch gelöst: Mit langsamem Zugriff und hohem Speicherverbrauch. Nämlich indirekt über Speicheradressen der Ports.
• Der Editor hat den lästigen Bug, dass man einzelne Tabs nicht schließen kann. Will man Ordnung machen, muss man ein neues Projekt erstellen. Igitt! (Wo auch immer er sich die Tabs merkt.)
• Wie man Compiler-Einstellungen vornimmt erschließt sich überhaupt nicht. Etwa die Einstellungen des Optimierers oder die Generierung von Listing-Dateien.
• Das schlimmste: Alle gefundenen Demo-Programme passen nicht in den ATmega328p! Lassen sich also gar nicht verwenden.

Die Demo-Programme basieren auf UTFT, einer mickrigen Grafikbibliothek mit riesigem Speicherverbrauch.

Also erst mal alles nicht benötigte herausgeworfen und laufen gelassen: Von dem was übrig bleibt sieht's schon mal ganz gut aus!
So wie's aussieht gibt's nichts besseres. Daher habe ich als erstes ein WinAVR-Projekt draus gemacht und den Arduino-Ramsch 'rausgeschmissen.
An einem Demo konnte ich die folgenden Features erkennen:

• Display-Drehung bei Initialisierung, nur 2 Richtungen
• Ausgabe von Text mit diktengleicher Schrift (ziemlich hässlich)
• Ausgabe von Bitmaps (nur Hi-Color) mit ganzzahliger Vergrößerung
• Linien, Rechtecke, Kreise, Rund-Rechtecke sowohl hohl als auch ausgefüllt
• Angenehm schnelle Funktion
• Die Siebensegment-Schrift (nur 10 Ziffern) sieht hübsch aus, aber hier wäre wohl eine Polygonausgabe angemessener in Anbetracht der Speicherverschwendung

Implementiert aber ungesehen weil Demo gekürzt werden musste:

• Frei rotierbarer Text
• Frei rotierbare Bitmaps
• Transparente Ausgabe von Text und Bitmaps

Anmerkung: Die Rund-Rechtecke sind mit festem Eckenradius. Ellipsen gibt's nicht, die Display-Pixel müssen gefälligst vom Seitenverhältnis 1:1 sein.

Richtungsweisend für mich war die Von-Neumannisierung von String-Zeigern mit dem Makro F. Das funktioniert am besten für AVR-Mikrocontroller mit ≤ 32 KByte Flash. Dafür ist das hervorragend für ATtinys geeignet, insbesondere rund um das Thema USB und seine Deskriptoren. Im Nachhinein betrachtet ist es schade, dass avr-gcc bzw. WinAVR nicht diesen Weg gegangen ist. Es hätte die unsäglichen Routinen aus avr/pgmspace.h wie memcpy_P und printf_P erspart.

Beim Blick auf das Disassemblerlisting (die man mit der Arduino-Software auf Tod und Teufel nicht zu Gesicht bekommt) fand ich riesige Passagen identischen Kodes. Was ist da los? Also: Unfähiger Programmierer. (Fleißig aber unfähig.) Sowas erwächst aus dem Arduino-System. War kaum anders zu erwarten. (Das gleiche Dilemma ist von VisualBasic bekannt.)

Ah, da findet sich eine memorysaver.h. Mal alle Displays ausknipsen, die nicht gebraucht werden. Wieso sind die per Default alle (~ 30) an? Hm, komischer Verdacht: Alles steckt in switch/case statt in #ifdef/#endif-Konstrukten! Wer kommt schon auf die Idee, an einen Mikrocontroller zwei Displays dranzuhängen??

Wie man's richtig macht sieht man bei V-USB: Fähiger Programmierer. Der nimmt auch keinen Arduino. Gut so. Schade nur, auch hier kein Deutsch.

Also alle nicht benötigten Controller auch noch restlos rausgeworfem, und die Code-Größe dampft auf erträgliche 20 Kilobyte ein. Unter Verzicht auf Gleitkomma und damit der freien Rotation. Würde sicherlich sowieso unleserlich aussehen, so ein schräger Font. Im Prinzip habe ich's neu geschrieben, aber (klar!) unfertig und mit folgenden Features:

• Auswahl dier Display-Eigenschaften per #define für minimale Code-Größe, aber auch nur 1 Display pro Controller (sollte wirklich reichen)
• Display-Rotation in 4 Richtungen sowie gespiegelt wählbar (wichtig für handgehaltene Geräte), dabei werden die Spiegelungen bereits vom Controllerchip übernommen

  

• bitblt (Bitmap-Transfer) in „8 Richtungen“ (X/Y-Tausch, X-Spiegelung, Y-Spiegelung) für 1-Bit-Quelle (Flash-Speicher) und 16-Bit-Quelle (FILE*, also universell) mit Masken-Transparenz auch als Kernfunktion für die Schriftausgabe

  

• Rechteck-Clipping, auch für bitblts (Das Display clippt zwar Pixelausgaben automatisch, aber betrachtet nur 8 vertikale und 9 horizontale Bits.)

  

• Objekt-Variablen wie aktuelle Position und Nullpunkt vereinfachen die Positionierung im Anwenderprogramm und verringern die Code-Größe, da eine lange Übergabeparameterliste vom avr-gcc nicht gut compiliert wird (liegt auch am Mikrocontroller).
• Proportionalschrift, speichersparend (bitweise hintereinander) abgelegt und die Funktion getTextExtent()

  

• Textausgabe in „8 Richtungen“ (siehe bitblt per orient[5:3]) und 4 Laufrichtungen (Escapements), was man so wahlfrei nur für die Ausgabe von Chinesisch oder Arabisch braucht

  

• Punkte, Linien, Kreise, Rechtecke, hohl oder ausgefüllt wie bisher nur eben mit Clipping
• Rund-Rechtecke mit Radiusvorgabe als Basis für Kreise und Rechtecke (TODO)
• Linienausgabe wahlweise ohne (wie Windows) oder mit (wie früher) Zielpunkt; Rechteck-Ausgabe wahlweise inklusive (wie früher) oder exklusive (wie Windows) der letzten Zeile und Spalte. Die Windows-Variante hat rechentechnische Vorteile, sonst hätte es Microsoft nicht so implementiert.

Was fehlt und in eine abgeleitete Klasse gehört:

• Scrolling im Rechteckfenster (erfordert rücklesbares Display)
• 2D-Weltkoordinatensystem (Drehung, Scherung, Skalierung)
• Muster- und Gradientenfüllung
• Polygone und Polygonfüllung
• Linienbreite > 1 Pixel (das ist richtig schwierig!)
• Alpha-Transparenz (sofern das Display rücklesbar ist)
• Freie Rotation von Bitmaps und Ellipsen
• Kreisbögen und Splines
• Pfade und Pfad-Clipping
• Outline-Schriften
• In eine weitere Klasse: OpenGL für den 3D-Renderwahnsinn
• Speicher-Bitmap (wird u.a. für OpenGL benötigt)

Das alles erscheint nur sinnvoll für Mikro­controller mit mindestens 16 Bit Verarbeitungs­breite und mindestens 64 KByte Flash-Speicher. Der RAM-Verbrauch hält sich hingegen in Grenzen. Daher sind alle diese Displays Kandidaten für STM32F103 und STM32F401.

Software
Diese enthält eine make-basierte VisualStudio-2008-Projektdatei, um den Quelltext mit IntelliSense bearbeiten zu können und gleich in der Entwicklungsumgebung (IDE) übersetzen zu können. Abgesehen dass diese IDE noch einiges fetter ist, nicht unter Linux läuft und kein Deutsch kann, ist's auf Dauer trotzdem komfortabler. Für die Filterung des gcc-Outputs wird gccfilter benötigt.

Die Datenblätter nochmal:

• Schaltplan des TFT-Anzeigemoduls mit Touchscreen und SD-Kartenschacht
• Datenblatt des Grafikchips
• Datenblatt des Touchscreen-Chips

Für diesen Ebay-Artikel (Suchworte TFT Arduino Uno R3) ist weder Dokumentation noch ein Beispielprogramm aufzutreiben! Alle UTFT-Displaytypen ausprobiert führte auch zu keiner Funktion. Die Pinbeschriftung deutet weder auf den benutzten Controller hin, noch ist klar wo und wie das Touchpanel angeschlossen ist. Nur dass es 240 × 320 Pixel hat ist dokumentiert. Bananen-Hardware also, oder gar ein Briefbeschwerer?

Also das Display gewaltsam von der Platine getrennt. Auf der flexiblen Leiterplatte steht eine Bezeichnung: FRD2803703. Google fördert ein PDF mit der Anschlussbelegung der Flexleiterplatte (siehe rechts) zu Tage, sowie den verwendeten TFT-Controllerchip: ILI9341. Keinen Schaltplan. Nicht mal einen unleserlichen.

Auf der Platine befindet sich ein Null-Ohm-Widerstand mit der Beschriftung R8 und R16. Man hätte drauf kommen können, dass es sich dabei um die Auswahl der Busbreite 8 bit oder 16 bit handelt. Bestückt ist er als R8 auf 8 bit. Da aber nirgends in der Doku zu entnehmen ist, wie die IMx-Eingänge des ILI9341 beschaltet sind, kam mir zunächst der Verdacht, dass man den Low-Teil ansteuern muss und das Arduino-Shield, so wie's ist, gar nicht gehen kann.

Einige Experimente später kam schließlich raus, dass alles richtig angeschlossen und verdrahtet ist. Nur die UTFT-Bibliothek ist krankhaft konstruiert. Die IM-Anschlüsse und Datenleitungen müssen wie folgt beschaltet sein:

Anschlussbelegung des Displays — nicht des Arduino-Shields

IM3	IM2	IM1	IM0	Modus	DB15:8	DB7:0
1	0	0	0	16-bit-Interface II	D17:10	D8:1
			1	8-bit-Interface II

Immerhin unterstützt es das Rücklesen und damit Alpha-Blending und Scrollen. Der Pullup R1 auf der Unterseite wird nicht benötigt.

Die Touchpanel-Anschlüsse X+,X-,Y+,Y- teilen sich die übrigen Datenleitungen wie folgt:

Direkte Analogwertabfrage beim „TFT-Shield 2.8″ R3“

Elektrode	Signal	Arduino-Pin	ATmega328-Pin		ATmega328-Funktion	Ruhezustand	X messen	Y messen
X- (links)	LCD_D7	A1	24	PC1	ADC1	Z	L	Z + messen
Y- (oben)	LCD_RS	~6	10	PD6	-	L	Z	L
X+ (rechts)	LCD_WR	7	11	PD7	PCINT23	Hi-Z + Interrupt	H	Z
Y+ (unten)	LCD_D6	A2	25	PC2	ADC2	L	Z + messen	H

So, hier ist eine halbfertige aber funktionierende Firmware. Dreh- und Angelpunkt ist eine "utft-config.h", die ich mit der Arduino-Software leider ums Verderben willen nicht in das Verzeichnis neben die .ino-Datei bekomme. Touchscreen-Unterstützung fehlt auch noch.

Nach einigen Diskussionen mit den Besitzern solcher Arduinos + TFT-Shields stellte sich doch noch eine sinnvolle Anwendung heraus. Natürlich nicht für Bewohner von Plattenbauten wie ich, sondern für Häuslebesitzer — ein Abfallkalender oder kurz Müllkalender. Dieser hängt in der Küche oder an der Hauseingangstür und erinnert mit einer auffälligen Hintergrund­farbe daran, die entsprechende Tonne an den Straßenrand zu stellen. Von Vorteil ist der geringe Stromverbrauch von ca. 100 mA, der sicherlich aus 80 % Hintergrund­beleuchtung besteht. Die gleiche Lösung mit einem Raspberry Pi wäre deutlich gefräßiger — und teurer.

Die Firmware zeigt die Aktion für den heutigen, morgigen und übermorgigen Tag an. Auch mehrere Aktionen pro Tag können angezeigt werden. Ein Groß­teil des Kodes kümmert sich um das Stellen der Uhr mit dem Touchscreen. Die UTFT-Bibliothek kommt nunmehr mit UTF-8 zurecht und kann die Zeichenposition 0x80..0x9F im Windows-Zeichensatz CP1252 benutzen. Für mehr als 256 Zeichen ist's aber erst mal nicht vorgesehen. Zur perfekten Ablesbarkeit wurden zwei Proportional­schriften mit 19 und 24 Pixeln Zellenhöhe und je 224 Zeichen eingebaut, was trotzdem nur ca. 13 kByte Speicher verbraucht. Das Konvertierungs­programm für die UB-PixelFontGenerator-Dateien ist in awk geschrieben.
Als Austauschformat zum Programmer wurde das unhandliche HEX-Dateiformat über Bord geworfen und alles auf Binärdateien umgestellt. Diese tragen bei mir die Endungen .flash bzw. .eeprom. Prinzipiell könnte man .flash sogar weglassen, da avrdude neuerdings auch .elf-Dateien akzeptiert.

Firmwarestand von 2016 auf ILI9341
Im 3D-gedruckten Gehäuse 2025 auf S6D04H0
3D-Visualisierung Gehäuse mit Stylusführung

Die jetzige Implementierung ist mit einigen Unvollständigkeiten verbunden:

• Da der Arduino keine batteriegepufferte Echtzeituhr hat, wird zur Überbrückung von kurzen Stromausfällen die Zeit jede Minute im EEPROM gerettet. Aber nicht einfach so plump, sondern so ausgetüftelt, dass jedes Bit von insgesamt 12 Bytes nur 1× pro Stunde programmiert wird. Atmel garantiert somit eine Lebensdauer von über 10 Jahren.
  • Da bietet sich durchaus der Anschluss eines DCF77-Funkuhrmoduls an.
  • Oder, wenn man eine Ferrit­stab­antenne hat und mit Konden­sator auf 77500 Hz abgleichen kann, zwei Transistoren und etwas geniale Software.
• Es ist kein Arduino-Projekt, sondern ein WinAVR-Projekt (also avr-gcc). Wie bereits oben erwähnt kann man sonst nicht die UTFT-Bibliothek zentral führen und lokal (per Include-Datei) konfigurieren.
• Das Hintergrundbild ist vom UTFT-Demoprogramm „übrig geblieben“ und garniert die ansonsten etwas lieblos gestaltete Oberfläche. Es ist statisch. Es wird auch der Wochentag angezeigt, hier (Chemnitz) mit Sonnabend statt Samstag.
• Kalibrier-Tool für Touchpanel, aufzurufen durch Touch in obere Bildhälfte
• Feiertags-Anzeige (für Sachsen), Oster-Berechnung bis 2099
• Kalender-Editor per Touchscreen
• Alle Unter-Fenster haben ein Timeout (von 30 Sekunden) eingebaut, damit nach dem Herumspielen durch Gäste letztlich immer der Hauptbildschirm angezeigt wird

Aber so ein Arduino ist ja zum Dranherumspielen gemacht. Der Flash-Speicher ist nun ziemlich voll. Was man so noch einbauen könnte bzw. was vorsehbar ist:

• Batteriepufferung und 32-kHz-Uhrenquarz an Timer2 (erfordert Schaltungsänderung am Arduino)
• Stromausfall-Früherkennung (zum Speichern der Uhrzeit erst wenn nötig) (erfordert Schaltungsänderung am Arduino)
• DCF77-Empfänger, am besten mit Wettervorhersage
• Fetziger Bildschirmschoner oder sonstige Untermalung mit dem Ziel, die Pixel gleichmäßig abzunutzen (etwa Scrollen des Kalenders zu verschiedenen Positionen)
• Dimmen der Hintergrundbeleuchtung je nach errechnetem Sonnenstand (Software) oder Umgebungshelligkeit (Fototransistor)
• Verschiedene Kalender-Ansichten (bspw. mit morgen, übermorgen, Wochenkalender, Monatskalender)
• Mondphasen-Anzeige, Sonnen-, Mond-, Sternbild- und Planeten-Anzeige, mehrere Kalender (chinesisch, iranisch, Hidschra u.ä.)
• Geburtstags-Erinnerung
• Akustischer Wecker (zum Schlafen), Kurzzeitwecker (zum Kochen), erfordert Piepser; Komme-gleich-wieder-Anzeige; Anzeige entgangener Anrufe (erfordert Verbindung zum Telefon sowie Hardware)

• ILI9325 auf Shield-TFT-2.8, ein 2,8-Zoll-Display
• ILI9341 auf FRD2803703, ein 2,4-Zoll-Display
• S6D04H0 auf „2.4" TFT LCD Shield“, Display-Label „S241GF31 DD5H29010 USP5280371“

Da ich die beiden erstgenannten Displays nicht gleichzeitig zum Test da hatte, leider mit getrennter UTFT-Bibliothek.

Das Gehäuse kommt ohne Schrauben aus: Die Platine mit dem Display wird an der Unterkante eingesetzt und oben eingeschwenkt, bis das LCD bündig im Ausschnit sitzt. Dabei helfen Pappschnipsel der Dicke 1 mm unter dem LCD. Danach wird der Arduino Uno wird mit seinen beiden Buchsen in die (dafür extra angefasten) Löcher (oben) gesteckt und unten eingeschwenkt. Dabei findet die Kontaktierung statt. Die Arretierung erfolgt mit Hilfe des Fingernagels: Damit wird die untere Gehäusekante etwas nach außen gebogen, um den „Arsch“ des Arduinos in die Rille einzuclipsen.
Die Rückseite wird von einem Pappdeckel Dicke 0,5 mm aus einer Schokoladenverpackung gebildet, der auf Zehntelmillimeter exakt zugeschnitten werden muss, mit vier abgefasten Ecken. Dieser clipst in der umlaufenden Rille an der Rückseite ein. Die dauerhafte Speisung kommt entweder von einem USB-Netzteil über die USB-Buchse oder von einer Spannungsquelle 6…12 V= über die Hohlbuchse. Für Batteriebetrieb ist die Hintergrundbeleuchtung des LCD viel zu gefräßig. Angedacht ist entweder Tischbetrieb mit einem hochflexiblen Stromversorgungskabel oder an der Wand aufgehängt.

Nachtrag: Nicht jeder Arduino Uno ist (für den ATmega328P) mit einem Quarz ausgestattet! Insbesondere die Revision R3 spendiert nur einen Keramikresonator! Damit ist die Uhr mit bis zu ±5 ‰ Gangfehler (±7 Minuten pro Tag, über ±3 h pro Monat) nur so genau wie Uromas mechanischer Wecker. In so einem Fall empfehle ich (1) den Austausch des Resonators durch einen Quarz oder (2) den Betrieb des ATmega328P mit dem Quarztakt des USB-Seriell-Konverterchips, also notfalls mit nur 12 MHz.

Ein September 2016 geliefertes 2,4″-Touch-Display mit der Aufschrift „S24GF31“ (auf dem Metallgehäuse), der Prägung „LMS241GF31“ sowie „CK241_REV0.1“ und „IS9F01YOP1P“ auf dem Flexboard erweist sich zwar ganz sicher als eines mit 240 × 320 Pixeln (400 Pixel sind Quatsch, ich hab's nachgezählt), aber mit dem Sketch „st7883.zip/examples/Mygraphicstest/Mygraphicstest.ino“ kommt auch nur ein zuckender (= kurzzeitig auf Schwarz umschaltender) weißer Bildschirm mit einigen farbigen Pixeln heraus. Immerhin, alle anderen Sketche zucken gar nicht. Es könnte sich also tatsächlich um einen ST7883 handeln. Aber ein Datenblatt dazu ist nicht zu finden. Ob es ein S6D04H0 ist, muss sich noch erweisen.