Seite wählen

NETWAYS Blog

Raspberry Pi Touch Display

Der Raspberry Pi ist ein  tolles Gerät für alle möglichen Anwendungsszenarien. In der 2er-Variante hat er mit einem 4-Kern-Prozessor und 900MHz auch endlich genug „Wumms“, um für anspruchsvollere Aufgaben nutzbar zu sein.
Seit der ersten Revision aus dem Jahre 2012 thronen auf der Platine ein CSI- und ein DSI- Anschluss. Der Anschluss für das Camera Serial Interface erhielt auch recht bald ein offizielles Gegenstück in Form einer Kamera, die per Flachbandkabel verbunden wurde. Dieser wurde wenig später noch eine NoIR-Variante (ohne Infrarotfilter) zur Seite gestellt, mit der Aufnahmen im nahen Infrarotbereich möglich sind. Das Display Serial Interface war jedoch bis September 2015 nahezu unbenutzbar, da der Markt für Endverbraucher keine passenden und unterstützten Geräte anzubieten hatte. So lange dauerte es eben, bis die Macher des Pi die richtigen Teile mit der entsprechenden Verfügbarkeit und die nötigen Fertigungskapazitäten beisammen hatten. Als das Display dann auf den Markt kam, war es natürlich erst mal monatelang ausverkauft.
Das Warten auf ein Wiedereintreten der Verfügbarkeit konnte man sich mit dem Anschauen einiger Auspackvideos versüßen. Denn so mancher Youtuber hatte bereits eines der Displays ergattern können und so konnte man sich schon vorab ein Bild von Nutzen und Begrenzungen der Erweiterung machen.
Anfang Januar 2016 war es dann soweit, dass wieder eine Charge der Displays verfügbar wurde und da schlug ich dann auch zu. Nach angenehm kurzer Lieferzeit konnte ich das Display dann auch von seiner Verpackung befreien und in Betrieb nehmen. Das größte Manko ist, dass der Schachtel zwar die üblichen Sicherheitshinweise beiliegen, jedoch keinerlei Anleitung, wie der Pi letztlich an das Display anzuschließen ist.
Als Regel kann man sich merken, dass die blauen Laschen am Flexkabel immer auf der Seite der ausziehbaren Klemmschieber liegen müssen. Die Stromversorgung kann wahlweise über USB oder über die beigelegten Verbindungskabel erfolgen. Ich habe mich für letztere Variante entschieden. Dabei geht „5V“ vom Controllerboard auf den zweiten und „GND“ auf den dritten GPIO-Pin der äußeren Reihe des Pi.
Die folgenden Bilder dürften da mehr Klarheit schaffen:

IMG_20160127_110402

Flexkabel: man achte auf die blauen Laschen


 
IMG_20160127_110423~2

Stromversorgung: platzsparend verlegt


Danach habe ich die SD-Karte mit einem aktuellen Raspbian bespielt und dabei noch mal zwecks Beschleunigung des Schreibvorgangs in einem früheren Artikel gespickt. Mit dem aktuellen Image läuft die Sache wie am Schnürchen. Das Display ist ohne weitere Konfiguration sofort voll einsatzbereit und die Touchfunktionalität ist ebenfalls direkt gegeben.
Unschön ist, dass bei der standardmäßigen Ausrichtung des Displays die USB-Stromanschlüsse nach unten zeigen. Solange man das Display ohne Gehäuse oder passenden Aufsteller betreiben will und das Ganze einfach so auf dem Tisch balanciert, wird das USB-Kabel recht hart abgeknickt und die Buchse ebenfalls mechanisch belastet.
Beheben lässt sich das durch Einfügen der folgenden Zeile in der /boot/config.txt:

display_rotate=2

Der Wert 2 bewirkt eine Drehung um 180°.
Eine 1 würde das Display um 90° rotieren und eine 3 um 270°.
Damit ist nach dem nächsten Neustart aber erst mal nur die Darstellung rotiert. Die Touchfunktionalität steht danach auf dem Kopf und muss extra angepasst werden. Dafür ist die Installation zweier Pakete notwendig, was mit

sudo apt-get -y install xinput evtest

schnell erledigt ist. Nun ist noch die folgende Zeile in der /etc/X11/Xsession einzufügen:

DISPLAY=:0 xinput --set-prop ‘FT5406 memory based driver’ 'Evdev Axis Inversion' 1 1

Nach einem weiteren Neustart funktioniert die Touchbedienung dann erwartungsgemäß.
Nun sind 800×480 Bildpunkte nicht übermäßig viel und einige Dialogfenster von LXDE passen damit nicht ganz auf den Bildschirm. Für einen vollwertigen Desktop ist das Display also keine gute Wahl. Zudem ist die Auswahl an „fingerfreundlichen“ Fenstermanagern auch 2016 noch sehr übersichtlich. Gnome Shell und Unity bieten bereits recht brauchbare Konzepte, aber da ist noch viel Spielraum. Außerdem sind beide zu ressourcenhungrig für den im Pi2 vorhandenen Arbeitsspeicher.
Eine weitere Möglichkeit besteht in der Verwendung des Frameworks Kivy, mit dem sich plattformunabhängig schon recht komplexe Oberflächen bauen lassen. Die Installation auf dem Raspberry Pi ist auch ziemlich gut dokumentiert.
Für den von mir angestrebten Zweck (Medienplayer mit Zusatzfunktionen) bestand die einfachste Lösung allerdings in der Verwendung von Kodi, welches die Touchfunktionalität ebenfalls ohne weitere Konfiguration unterstützt. Nach ein paar Experimenten bin ich schließlich bei OpenElec als Distribution gelandet, das sich durch einfachste Bedienung und kurze Bootzeit auszeichnet.

Das Erwachen der Vorweihnacht

Du weißt, dass es etwas ganz Besonderes wird, wenn Du Dich am frühen Nachmittag von Deinem Sitzmöbel erhebst, um kurz darauf mit all Deinen Kolleginnen und Kollegen einen Fußmarsch zum örtlichen Kinokomplex anzutreten.
Dort angekommen gab es allerlei Getränke, Popcorn und Nachos, sowie die äußerst komfortablen elektrisch verstellbaren Ledersessel in einem der Deluxe Kinos. Ein wahrlich angemessenes Setting, um dem bevorstehenden Kinoereignis „Krieg der Sterne – Das Erwachen der Macht“ beizuwohnen.

You know you work for @netways when this is how you're going to watch Star Wars VII. Big thanks to @gethash pic.twitter.com/SfElA6GhLa

— blerims (@bobapple) December 21, 2015


Kaum dass die ersten Klänge der Titelmelodie ertönten und der Introtext in die Unendlichkeit zu wandern begann, wurde das Spektakel auch schon von enthusiastischem Gejohle der hartgesottenen „Krieg der Sterne“-Fans quer durch den Saal begrüßt.
Über die sich in den folgenden zweieinviertel Stunden entfaltende Handlung will ich hier kein Wort verlieren. Das tun andere bereits zur Genüge und manch einer, der diesen Artikel liest, will vielleicht noch unvoreingenommen ins Kino gehen können. Die Qualität der Produktion soll dennoch erwähnt werden. Dieser Teil wirkt wesentlich düsterer und erwachsener als die zuvor erschienen drei Teile. Es war sehr schön, die altbekannten Darsteller wieder einmal in ihren Rollen zu sehen und die 3D-Umsetzung war tatsächlich sehr gut gemacht. So hatte ich nie den Eindruck, dass es „zuviel 3D“ wäre, und war gleichzeitig angenehm überrascht, wenn mich ein scheinbar aus der Leinwand ragender Sternenzerstörer förmlich an der Nasenspitze kitzelte.
Mit dem anschließenden Besuch beim Nürnberger Weihnachtsmarkt nahm das Ereignis dann auch ein würdiges Ende.
Vielen Dank an Netways, dass es auch immer wieder solche Glanzlichter gibt!

Loganalyse mit gltail

Logdateianalyse ist mit manuellen Mitteln ein beschwerliches Geschäft. Außerdem sind wir Menschen um Größenordnungen besser darin, graphische Muster schnell und intuitiv zu bewerten, als Abermillionen von Textzeilen. Daher wurden mittlerweile einige Softwarelösungen entwickelt, die Logs nach verschiedenen Kriterien visualisieren können. Neben Lösungen wie beispielsweise Kibana oder AWStats, die geloggte Ereignisse vornehmlich als „Fieberkurven“ darstellen, gibt es auch andere Werkzeuge, die einen eher spielerischen Ansatz verfolgen, wie etwa logstalgia oder das hier besprochene gltail.
gltail wurde von Erlend Simonsen als Programmierübung entwickelt und auf github veröffentlicht. Der Autor macht keinen Hehl daraus, dass es sich hierbei um kein sonderlich ernsthaftes Projekt handelt. Für manche Anwendungsfälle wie Trafficanalysen bietet es dennoch eine interessante Alternative.
Die Installation ist durch Clonen des Repositorys schnell erledigt.

git clone https://github.com/Fudge/gltail.git

Danach müssen noch – wie in der Installationsanleitung auf github beschrieben – ein paar Ruby-Pakete installiert und die mitgelieferte config.yaml angepasst werden.
Ein Blick in das Verzeichnis mit den Parsern (oder auch direkt auf verrät, welche Logformate gltail darstellen kann.
Wenn dann noch passwortloser Login mit SSH-Schlüsselpaaren zur Zielmaschine eingerichtet ist, steht auch dem entfernten Analysieren von Logdateien nichts mehr im Wege.

Ein kurzer Druck auf die Leertaste bewirkt, dass die Kugeln voneinander abprallen und wie im Video durch einen Trichter nach unten ablaufen. Da gewinnt der Begriff „Bottleneck“ bei hohem Aufkommen deutlich an Plastizität.

Mac OS X: dd schneller und mit Fortschrittsanzeige

Wenn ich weiß, dass die Hardware eigentlich deutlich mehr hergeben sollte, gehört Geduld nicht unbedingt zu meinen großen Stärken.
Konkret bestand die Aufgabe darin, eine Raspbian-Installation von einer SD-Karte auf zwei andere zu transferieren. Da mein Mac nur (oder immerhin noch) einen SD-Kartenslot hat und kein externer Kartenleser zur Verfügung stand, musste der Umweg über das Ziehen eines Images von der Originalkarte und anschließendes Schreiben desselbigen auf die neuen Karten her. Das altbekannte dd ist hierfür das perfekte Werkzeug.
Vorher wird die Karte aber erst mal ausgehängt. In meinem Fall ist das /dev/disk2:

diskutil umountDisk /dev/disk2

Dann geht es mit dd weiter:

dd if=/dev/disk2 of=Image.dd

Da dd von Haus aus keine Fortschrittsanzeige mitbringt, kann man sich unter anderem durch Drücken von „CTRL+t“ einen Zwischenstand ausgeben lassen. Die Ausgabe umfasst die aktuelle Systemlast, den Namen und die PID des aktuell im Vordergrund laufenden Prozesses, sowie seine Kernel- und User-Zeiten und im Falle von dd eben auch den aktuellen Fortschritt.
Das sieht dann zum Beispiel so aus:

load: 1.69 cmd: dd 69334 uninterruptible 0.00u 1.97s
13+0 records in
13+0 records out
109051904 bytes transferred in 17.182351 secs (6346739 bytes/sec)

Circa 6 MB/s von einer Class10-SD-Karte? Das muss doch schneller gehen.
Aus der Linuxwelt kommend versuchte ich also als Erstes, per Angabe der Blockgröße (bs=8M) mehr Durchsatz zu erzwingen. Der Lerneffekt hierbei war, dass die BSD-Version von dd unter Mac OS X die Angabe der Einheit nur kleingeschrieben schluckt. Also:

dd if=/dev/disk2 of=raspiImage.dd bs=8m

Damit änderte sich am Tempo aber so gut wie nichts. Bei einer zum Vergleich hergenommenen Class6-Karte macht der Parameter aber doch einen wesentlichen Unterschied. Also wird er beibehalten und fix noch mal das globale Wissen angezapft,  wo sich der Tip findet, anstelle von /dev/diskX doch besser /dev/rdiskX zu verwenden.

dd if=/dev/rdisk2 of=test.dd bs=8m

Kontrolle mit CTRL+t:

load: 1.77  cmd: dd 70036 uninterruptible 0.00u 7.38s
886+0 records in
886+0 records out
7432306688 bytes transferred in 166.815176 secs (44554140 bytes/sec)

Etwas mehr als 42 MB/s. Das ist schon eher die Antwort, die ich suchte 😉
Da das häufige Drücken von CTRL+t und anschließende Umrechnen der Byteangaben in eine menschenverständliche grobe Abschätzung der zu erwartenden Dauer eine Sache ist, die der Computer viel besser und schneller machen kann, bietet sich hierfür das Kommando „pv“ an.
Zum Lesen von einer Karte (-s 16g an die Größe der Karte anpassen):

dd if=/dev/rdisk2 bs=8m | pv -petra -s 16g > Image.dd

Um das Image auf eine Karte zurückzuschreiben:

pv -tpreb Image.dd | dd of=/dev/rdisk2 bs=8m

Natürlich gelten die hier gemachten Vorschläge nicht nur für SD-Karten und gegebenenfalls mit Abwandlungen auch für Linuxer 🙂
Quellen:

Solution: dd too slow on Mac OS X


Progress while copying an img file to/from an SD card with OSX/Linux

Icinga2 und icinga-web für Debian/Ubuntu auf ARM-Prozessoren

Warum?

Das icinga PPA stellt fertige Pakete für i386 und amd64 bereit. Für den Betrieb auf ARM-Prozessoren (wie zum Beispiel beim Raspberry Pi oder dem hier verwendeten ODROID U3) muss man seine Installationspakete aber selber schnüren.
Aufgrund der exzellenten Build Tools von Debian sowie des fertig vorliegenden Debian Source Packages vom Icinga Package Maintainer  ist das allerdings eine sehr einfache Angelegenheit. Dieses HowTo verwendet pbuilder, welches den Bauprozess sauber in einer chroot-Umgebung ausführt und so das System nicht mit Fragmenten des Kompiliervorgangs kontaminiert.

pbuilder setup

Ersetze trusty durch die angepeilte Zieldistribution

sudo apt-get install pbuilder debootstrap devscripts
sudo pbuilder create --distribution trusty --debootstrapopts --variant=buildd

configure sources.list

sudo echo "deb-src http://ppa.launchpad.net/formorer/icinga/ubuntu trusty main" >> /etc/apt/sources.list
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 36862847
sudo apt-get update

icinga2

Herunterladen der Quellen in das aktuelle Verzeichnis

sudo apt-get source icinga2

Das Bauen der Pakete dauert auf einem ODROID U3 etwa eine Stunde (-j4 an die Anzahl der CPU-Kerne anpassen)

sudo pbuilder build --debbuildopts "-j4" icinga2_2.2.4-1~ppa1~trusty1.dsc

icinga-web

Das Ganze funktioniert entsprechend für icinga-web

sudo apt-get source icinga-web
sudo pbuilder build icinga-web_1.11.2+dfsg1-1~ppa1.dsc

Die Resultate liegen dann in /var/cache/pbuilder/result/

Vielen Dank an andrenarchy für die exzellente Zusammenarbeit bei der Erstellung dieses Artikels!