Die Lieferung des Bildschirms (Abbildung 2) erfolgte prompt. Im Gegensatz zum Pi3g-Modell kommt das Watterott-Display ohne Kabel aus: Sie stecken es direkt auf die Stiftleiste des Raspberry Pi auf. Der Vorteil: RasPi und Bildschirm bilden eine kompakte Einheit, für das Paar gibt es auch ein passendes Gehäuse. Der Nachteil: Es stehen weniger Freiheiten bei der Montage zur Verfügung. Da das Display auch den Kameraanschluss verdeckt, müssen Sie eine Pi-Cam zuerst montieren und dann das Kabel mit einem scharfen Knick herausführen.
Abbildung 2: Der LCD-Bildschirm von Watterott bietet auf der Rückseite eine Anschlussleiste, die Sie direkt auf den RasPi stecken.
Der Lieferumfang fällt spartanischer aus als beim Pi3g-Modell, es fehlen sowohl die vorinstallierte SD-Karte als auch der nützliche Eingabestift. Dafür belastet das Gesamtpaket das Budget deutlich weniger. Ein angepasstes Raspbian-System sowie eine ausführliche Dokumentation finden Sie auf Github [4]. Das System von Watterott kämpft mit den gleichen Problemen bei Updates der Distribution wie das von Pi3g, auch die Lösung gestaltet sich analog (siehe Kasten “Treib(er)jagd”).
Technisch unterscheiden sich die beiden Displays nur minimal: Das Pi3g-Modell nutzt einen ILI9325-Chipsatz mit einem ADS7843-Touch-Controller, beim Watterott-Modell kommt ein ILI9341-Chipsatz mit identischem Controller zum Einsatz. Bei der nächsten Produktionscharge könnte das allerdings schon wieder im Detail ganz anders aussehen.
Inbetriebnahme
Ein wichtiger Schritt bei der Inbetriebnahme eines Touchscreens stellt die Kalibrierung dar, wie sie schon bei früheren Geräten mit resistiven Bildschirmen so üblich war. Bei Pi3g [5] steht eine grobe Hardware-Kalibrierung an erster Stelle – ein etwas fummeliger, aber gut dokumentierter Prozess. Letztlich geht es dabei um optimale Parameter für den Touch-Treiber, die dann in der /etc/modules landen und die der RasPi beim Booten automatisch aktiviert. Anschließend erfolgt die Feinkalibrierung per Software mit dem Programm ts_calibrate. Dazu gibt das Tool Punkte auf dem Bildschirm vor, die es anzutippen gilt (Abbildung 3).
Abbildung 3: Pi3g startet beim ersten Booten ein Kalibrierungsprogramm, mit dem Sie das Display feinjustieren.
Das Pi3g-Image bootet normal, es startet also das textbasierte Konfigurationsprogramm von Raspbian. Da das System den Touchscreen nur unter X unterstützt, geht ohne angeschlossene Tastatur nichts. Der ganze Prozess gestaltet sich zudem nicht eben augenfreundlich, leichter geht es per Secure Shell von einem anderen Rechner aus. Das Watterott-System dagegen kommt schon grundkonfiguriert, hier startet X direkt. Möchten Sie Einstellungen wie die Tastaturbelegung ändern, müssen Sie trotzdem das Konfigurationsprogramm aufrufen.
Pfiffig löst Watterott die Kalibrierung, die beim ersten Start von X automatisch lädt. Sie erzeugt die Datei /etc/pointercal.xinput mit den ermittelten Parametern. Existiert dieses File bereits, überspringen die Startskripte von X den Kalibrierungsprozess. Die grobe Hardware-Kalibrierung erwähnt Watterott in seinen Dokumenten nicht. Je nach Serienstreuung sollten Sie dazu aber die entsprechenden Werte für das Modul ads7846_device in der Datei /etc/modules anpassen.
Letztlich unterscheiden sich die beiden Systeme hinsichtlich der ersten Inbetriebnahme nur minimal voneinander. Nach dem Start steht dann der normale Raspbian-Desktop bereit (Abbildung 4). Hier zeigt sich schnell, dass sich der Bildschirm für diesen Zweck nicht eignet, weil er dazu schlicht zu klein ausfällt. Darüber hinaus lässt sich kaum ein grafisches Programm nur mit der linken Maustaste bedienen – eine andere Form der Benutzerinteraktion muss also her.
Abbildung 4: Für einen normalen Raspbian-Desktop erweist sich das Mini-Display als viel zu klein und nahezu unbedienbar.
Speziallösungen
Im der letzten Ausgabe von RPG stellte ein Artikel das C-Berry-Display vor [6]. Wegen fehlender X-Treiber lief die Ansteuerung aber über Low-Level-APIs mittels C. Das erwies sich zwar als effizient und ressourcenschonend, aber nicht als jedermanns Sache.
Da die beiden besprochenen Displays einen X-fähigen Framebuffer-Treiber mitbringen, wäre dieser Ansatz zwar möglich, ist aber gar nicht nötig: Jedes Toolkit – ob Qt, GTK+ oder ein anderes, das auf X aufsetzt – versorgt Anwendungen mit einer Oberfläche. Die Bestandteile passen aber nicht wirklich auf die Mini-Screens, insbesondere Standardkomponenten wie Scrollbalken, Menüs und ganz speziell Dateiauswahldialoge eignen sich definitiv nicht für kleine Bildschirme.
Adafruit bietet einen den beiden getesteten Exemplaren ähnlichen Bildschirm auf Basis des ILI9341 für Bastler mit Löterfahrung an [7]. Dafür stellt der US-Anbieter eine Kamera-Anwendung auf PyGTK-Basis bereit [8], die das Benutzerinterface konsequent selbst implementiert. Solche Speziallösungen wären zwar optimal, erweisen sich aber für viele Zwecke als zu aufwendig.
Apps für Raspbian?
Apple zeigte der Welt letztlich, wie eine einfache und sinnvolle Benutzerinteraktion auf kleinen Bildschirmen funktioniert: mit ausreichend großen, auf Berührung ausgelegten Schaltflächen im Einfenstermodus. Entwicklern stehen für iOS und Android leistungsstarke Toolkits zur Verfügung, die das Erstellen von Anwendungen stark vereinfachen. Auch die Nutzer profitieren von den einheitlichen Designvorgaben.
Für Raspbian in Kombination mit den 2,8-Zoll-Bildschirmen gibt es derzeit nichts dergleichen. Die Bastelei geht also nach dem Zusammenbau trotz X-Treiber erst richtig los: Ohne Programmierkenntnisse erweisen sich die Bildschirme also eher als nutzlos. Fraglich bleibt auch, ob sich die Displays weit genug verbreiten, damit sich eine Community entwickelt, die eine generische Unterstützung für die Anwendungsentwicklung bietet.
Technisch gibt es verschiedene Ansätze für solch ein 2,8-Zoll-Toolkit. HTML5 wäre ein heißer Kandidat, als Laufzeitumgebung bräuchte es dann noch einen für Kleindisplays optimierten Browser. Das wäre in etwa der Ansatz, den Firefox mit seinem Firefox-OS verfolgt.
