Vollgrafikanzeige mit Grafikbibliothek und Touchscreen

Immerhin ist da noch ein Touchscreen und ein SD-Kartenleseschacht dran. Der arme kleine Mikrocontroller! (Verwalte mal 32 Gigabyte mit 32 Kilobyte!) Dafür gibt es jedoch vom Hersteller keinen Verweis auf Demo-Programme. Es gibt auch keine. Bananen-Hardware? (Soll beim Anwender reifen.) Das Display ist leider write-only angeschlossen, damit ist Alpha-Transparenz nicht realisierbar.

Arduino-Kritik

• 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.

UTFT - ziemlich unbrauchbar

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

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

UTFT - noch einmal

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
  

  Mögliche (ungespiegelte) Bildschirm-Ausrichtungen

• 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
  

  Bitmaps können in alle Hauptrichtungen ausgegeben werden. Es entscheidet orient[3] sowie das Vorzeichen von w und h

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

  Rechteck-Clipping in Aktion. Völlig außerhalb liegende Bitmaps und Zeichen werden gar nicht erst ausgegeben

• 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()
  

  Das liefert 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
  

  Die vier Laufrichtungen der Schriftausgabe

• 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)

Hier ist Software (Download). 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

Rätselhaftes TFT

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-Ω-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:

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

2016: Andere TFT-Zuordnung

• Display-Controller, Auflösung (für Kalender muss es 240×320 sein), Orientierung (hochkant und ungespiegelt)
• Portpin-Zuordnung zum Display-Controller, Bidirektionalität
• Portpin-Zuordnung zum Touchscreen
• falls vorhanden, Touchscreen-Controller (selten)

Firmwarestand von 2016 auf ILI9341. Der Proportionalfont sieht fetzig aus

Seit August 2016 gibt es auch einen Monatskalender mit Editierfunktion.

Was man nicht sieht: Vom Hauptbild geht es per Touch in drei Bereiche zu drei Unterprogrammen:

Touchscreen kalibrieren
Monatskalender	Uhr stellen

Die Klickbereiche sind hierbei unkalibriert getrennt, damit man überhaupt sinnvoll zum Kalibrier-Dialog kommt. Zielgenauigkeit ist erst bei „Monatskalender“ und „Uhr stellen“ vonnöten.

Abfallkalender

Die derzeitige 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 Proportionalschriften mit 19 und 24 Pixeln Zellenhöhe und je 224 Zeichen eingebaut, was trotzdem nur ca. 13 kByte Speicher verbraucht. Das Konvertierungsprogramm für die UB-PixelFontGenerator-Dateien ist in awk geschrieben.

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.
• 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

• 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

Rätselhaftes Display

Gelöst!

Der Touchscreen verhält sich anscheinend wie bei älteren Displays mit ILI9325 und funktioniert nun auch:

Noch eins mit ILI9481

Siehe Quelltext.

Unbekanntes 2,4-Zoll-Display (August 2017)