Test: Intels Galileo-Board
Arduino-Boards sind längst eines der beliebtesten Spielzeuge für Bastler, finden aber auch bei semiprofessionellen Anwendern viel Anklang. Und je mehr Erfahrungen die Nutzer sammeln, desto mehr steigen die Ansprüche: die Einbindung in vorhandene Rechnernetze, komplexe datenbankbasierte Steuerungsaufgaben und Bilderkennung. Das alles benötigte bislang noch einen echten Rechner im Hintergrund. Eine Art preiswertes Arduino-Raspberry-Pi-Crossover ist der Traum mancher Anwender. Dass nun ausgerechnet Intel eine solche Kombination vorgestellt hat , verblüffte nicht wenige.
Auf dem Board arbeitet Intels neues SoC Quark-X1000, ein x86-Prozessor, getaktet mit 400 MHz und mit dynamischen Stromsparfähigkeiten, ihm zur Seite stehen 256 MByte RAM. Viel interessanter sind aber die Anschlussmöglichkeiten: Neben den mit dem Uno R3-kompatiblen Arduino-Pins hat das Board eine Vielzahl von Anschlüssen: einen Ethernet-Anschluss, einen seriellen RS-232-Anschluss und sowohl einen USB-Host- als auch einen Client-Anschluss, dazu einen Mini-PCIe-Port.
Der USB-Client-Anschluss kann dazu verwendet werden, USB-Geräte zu simulieren, zum Beispiel eine Tastatur. Mini-PCIe ist ein verbreiteter Standard bei Laptops, um Erweiterungsmodule anzuschließen - am bekanntesten sind Wireless-Module. Mit Hilfe von Adaptern ist daran aber im Prinzip auch das Anschließen von SSDs und PCIe-Grafikkarten möglich.
Worauf das Board allerdings verzichtet, ist eine Grafikeinheit mit zugehörigem Ausgang. Das gilt aber auch für Motherboards mit Intel-Chips im ITX-Format in ähnlicher Preisklasse.
Das Design des Boards steht unter der freien Lizenz ( CC BY-SA(öffnet im neuen Fenster) ), das Board-Design kann von Intels Webseite heruntergeladen(öffnet im neuen Fenster) werden.
Arduino-Board mit Linux
Auf dem Board läuft standardmäßig Linux, das auch die Arduino-Funktionalität transparent implementiert. Transparent heißt: Ein Arduino-Programm ( Sketch ) kann auch auf Programme und Kommandozeilenfunktionen der Linux-Installation zugreifen, umgekehrt können Linux-Programme und Skripte die Arduino-Pins über dokumentierte /sys/class/gpio -Einträge lesen und schreiben.
Zum Kaufpreis von circa 55 bis 60 Euro ist Intels Galileo damit zumindest auf dem Papier ein interessantes Bastlerboard für mitwachsende Ansprüche, vor allem, weil Entwicklerboards mit Intels Prozessoren der x86-Familie bislang nicht unter 150 Euro kosten.
Wir legen los
Nach dem Auspacken ist Galileo aber erst einmal nur das teuerste, aber schnellste derzeit verfügbare Arduino-Board. Wir verkabeln das Board und laden die Arduino-IDE von der Intel-Seite herunter. Nach dessen Installation rufen wir das Blink-Beispiel auf, und tatsächlich - es funktioniert.
Wer bereits eine Arduino-IDE installiert hat, wird damit nicht weit kommen, auch wenn die Intel-Kopie ein Fork des Originals ist. Den Grund dafür zeigt die Ausgabe der Compiler-Konsole: Intels IDE erzeugt ein echtes Linux-Programm als x86-ELF-Binary und kopiert es in das Verzeichnis /sketches des eingebauten Linux. Das Binary ist gut 48 KByte groß. Zum Vergleich: Das Atmel-Binary des Original-Arduinos für das Blink-Beispiel ist nur um die 2 KByte groß.
Hier zeigt sich ein wesentliches Designkonzept: Es handelt sich tatsächlich um einen vollwertigen Rechner. Das Linux befindet sich in einem 8-MByte-Flash-Speicher und lädt flott. Aber das System ist eben nicht mit dem Einschalten "da". Wer bislang mit echten Arduino-Boards gearbeitet hat, muss sich an die längere Wartesekunde gewöhnen.
Ein Blick ins Linux
Nachdem wir diverse Arduino-Spielereien erprobt haben, wollen wir uns größeren Aufgaben widmen. Wir stecken das Board an unser LAN und starten ein Sketch(öffnet im neuen Fenster) , um den Telnet-Daemon des Linux zu aktivieren. Ohne Probleme können wir uns dann per Konsole umschauen. Ein Großteil der bekannten und üblichen Kommandozeilenwerkzeuge ist installiert, aber auch nur diese. Insgesamt werden wir an unsere früheste Linux-Kindheit um 1993 erinnert.
Wer tatsächlich die Möglichkeiten der Plattform ausnutzen will - und vor allem die versprochenen vorinstallierten Features wie Python, Node.js und OpenCV nutzen will -, muss das "Fat"-Linux nutzen, das aber auch gerade mal 350 MByte groß ist. Das entsprechende Image muss heruntergeladen werden und wird auf eine Micro-SD-Karte überspielt.
Frohgemut stecken wir die so vorbereitete Karte ein, versorgen das Board mit Strom, starten unseren Telnet-Sketch und wundern uns. Das Board hat das Linux nicht von der SD-Karte gestartet, sondern wieder vom Flash-Speicher.
Wir testen, spielen das Image sicherheitshalber erneut ein. Wieder das gleiche Ergebnis. Deshalb entscheiden wir uns, die Firmware-Update-Funktion der Arduino-IDE zu starten. Zuerst meldet uns das IDE, dass es die Version der installierten Firmware nicht ermitteln könne, beim zweiten Versuch friert die IDE ein. Erst beim dritten Anlauf funktioniert es, und wir konnten erfolgreich updaten. Dann kann das Board auch das Linux von der SD-Karte aus starten. Wir verbinden uns nun per SSH statt per Telnet.
Laut Intel betrifft dieses Problem nur die erste Produktionscharge.
Und weitere Fehler
In unserem Überschwang wollen wir natürlich gleich mit Python und OpenCV starten. Also schreiben wir ein kleines Python-Skript auf unserem Bürorechner. Auf dem Board zu entwickeln, ist zwar prinzipiell möglich, da aber in der Installation nur vi (ohne "m"!) vorhanden ist, verzichten wir vorerst darauf. Darauf kommen wir später noch zurück.
Das Skript schieben wir per scp auf das Board und rufen es auf. Und schauen ungläubig auf die Kommandozeilenausgabe:
/usr/bin/python2.7: \ symbol 'th_comment_query_count': can't \ resolve symbol in lib \ '/usr/lib/libtheoraenc.so.1'. ?
Tatsächlich: Die OpenCV-Installation für Python ist kaputt. Und das Problem ist nicht etwa irgendein exotischer Befehl. Den Fehler verursacht bereits das "import cv2" am Skriptanfang. Zur Erinnerung: Intel bewirbt das Board explizit mit OpenCV- und Python-Support.
Wir entscheiden uns, erst einmal weiterzumachen und wollen mit Node.js einen kleinen Webserver aufsetzen. Allerdings ist Node ohne zusätzliche Module etwas unpraktisch. Zum Glück ist npm Teil der Installation. Also rufen wir es auf: npm install express .
Und erneut zerstört die Kommandozeilenausgabe all unsere Träume:
npm http GET https://registry.npmjs.org/express npm ERR! Error: SSL Error: CERT_NOT_YET_VALID
Zumindest im Fall von npm lässt sich das Problem beheben. Glücklicherweise erlaubt der Registry-Server von Node.js auch den Zugriff ohne SSL:
root@clanton:~# npm config set registry http://registry.npmjs.org/
Danach verläuft die Installation ohne Probleme. Die Ursache des SSL-Problems liegt in der fehlenden Installation vom Root-Zertifikat. Auf ein ähnliches Problem stoßen wir, als wir ein WLAN-ePci-Modul aus einem ausgeschlachteten Notebook installieren wollen. Das Linux-Kommando lspci liefert uns nur die IDs der Hardwarekomponenten, keine Klartext-Angaben der Hersteller und Produkte. Denn die zugehörige Datenbank fehlt.
Wir probieren es mit der Installation von Python-Werkzeugen. Das ez_install.py -Skript funktioniert, easy_install steht danach auf der Kommandozeile zur Verfügung. Aber je nach Modul bricht die Installation von Python-Eggs ab. Es fehlen dem Linux die Build-Werkzeuge wie make und gcc.
Unfreiwillig im Linux-Dschungel
Auf der SD-Karte ist dafür genügend Platz, und auch wenn sich ein Single-Core-Prozessor mit 400 MHz nicht gerade für eine Kernel-Kompilierung empfiehlt, für kleine Programme und Module langt es - hat es zur Jahrtausendwende schließlich auch.
Nur: Wie bekommen wir diese Werkzeuge auf die SD-Karte? Die Intel-Dokumentation verliert kein Wort zum Thema Package Manager. Das hat einen einfachen Grund: Keiner der bekannten Package Manager wie rpm oder apt-get ist installiert. Und das ist nicht etwa ein Fehler, sondern quasi ein "Feature".
Intel verwendet Yocto(öffnet im neuen Fenster) als Distribution. Dabei handelt es sich um eine spezielle Distribution für Embedded-Systeme mit dazugehörigen Build-Werkzeugen für einen Host-Rechner. Sie zeichnet sich durch einen geringen Platz- und Speicherbedarf aus. Das Yocto-Linux passt problemlos in den 8 MByte großen Flash-Speicher des Boards, lässt aber noch Platz für die Arduino-Funktionalität.
Das Yocto-Konzept funktioniert als solches gut für fertige Embedded-Boards, die auf ihren endgültigen Einsatz warten. Nur leider vermarktet Intel das Galileo-Board als Entwicklerplattform.
Und Intel sieht dieses Linux auch für "Fat"-Installation auf der SD-Speicherkarte vor, obwohl der verfügbare Platz dort ein geringeres Problem ist. Konzeptbedingt ist eine Yocto-Installation nur aufwendig an die eigenen Wünsche anzupassen und erfordert einen nicht zu unterschätzenden Lernaufwand.
Wer Yocto um zusätzliche Programmpakete, wie zum Beispiel Vim , aber eben auch Entwicklerwerkzeuge ergänzen will, kommt um die Erstellung eines eigenen Images oder ein Cross-Compiling auf Basis eines Board Support Packages (BSP) für Yocto nicht herum. Und dieser Vorgang erfordert einiges an Aufwand.
Zuerst brauchen wir eine Linux-Installation als Host, mindestens 70 GByte freier Festplattenspeicher sind Pflicht, minimal 2 GB RAM empfehlenswert und Prozessorpower sowieso. Die erforderlichen Software-Packages und eine Bauanleitung hat Intel in einer Build-Anleitung(öffnet im neuen Fenster) aufgelistet. Zusätzlich empfiehlt sich ein ausführlicher Blick in einen Blogeintrag(öffnet im neuen Fenster) von Sergey Kiselev.
Wer den Anweisungen folgt, erhält ein Build-Verzeichnis mit dem sehr langen Namen Board_Support_Package_Sources_for_Intel_Quark_v0.7.5 , dieser sollte vor allen weiteren Schritten gekürzt werden, zum Beispiel in "bsp". Denn bei uns bricht im weiteren Verlauf eine Kompilierung wegen eines zu langen Kommandozeilenaufrufes ab.
Was in beiden Anleitungen untergeht: setup.sh muss mit dem Parameter -e layer aufgerufen werden. Ansonsten läuft das generierte Image mangels spezifischer Treiber und Einstellungen nicht auf dem Galileo-Board.
Außerdem empfiehlt es sich, in der Datei conf/local.conf die Werte in den Einträgen BB_NUMBER_THREADS und PARALLEL_MAKE mindestens zu verdoppeln, wenn die Generierung auf einem halbwegs aktuellen Prozessor läuft.
Jetzt kann die eigentliche Image-Generierung beginnen. Und wir legen uns erst einmal schlafen - nein, doch lieber nicht. Denn die Generierung des "Fat"-Linux dauert zwar lang: um die 4 Stunden auch bei aktueller Hardware und guter Internetanbindung. Aber die Wahrscheinlichkeit ist relativ groß, dass der Prozess zwischendurch abbricht. Häufigster Fehler ist, dass ein Quellcode-Paket nicht heruntergeladen werden kann, weil der Downloadserver nicht schnell genug reagiert. Bei wenig RAM und zu vielen Kompilierungstasks gleichzeitig sind auch seltsame Compiler-Abbrüche möglich. In beiden Fällen ist die Lösung einfach, die Generierung neu zu starten. Zum Glück sind frühere Downloads und Kompilate gecacht.
Das generierte Image entspricht nun genau dem, das wir von Intel heruntergeladen haben. Gleichzeitig haben wir die notwendige Umgebung, um das Image um weitere Programme zu ergänzen. Dazu ist es aber notwendig, ein "Rezept" (Recipe) zu schreiben - und ja, das ist ebenfalls ein Stück Arbeit(öffnet im neuen Fenster) . In diesem Rahmen kann der Package Manager des Hostcomputers zum Einsatz kommen. Die Yocto-Werkzeuge kümmern sich um die Cross-Kompilierung.
Leider behebt der Selbstbau der Distribution keinen der obigen Fehler. Auch eine neuere Version 0.8.0 des BSP, auf die wir zufällig stoßen, hilft nicht: Die Image-Erstellung scheitert.
Am Ende doch Erfolg
Nun ist der Vorteil eines x86-basierten Boards eigentlich, dass vorgefertigte Binaries der meisten Programme existieren und ein Package Manager zumindest teilweise verzichtbar wäre. Nur sind diese praktisch nicht auf diesem Image lauffähig. Denn das Intel-Image ist nicht kompatibel zur Linux-Standard-Base(öffnet im neuen Fenster) .
Allerdings ist es möglich, ein LSB-kompatibles Image zu bauen, im obigen verlinkten Blogbeitrag wird auch dies beschrieben. Nur verlängern diese Features die Generierung des Images enorm: Bei uns dauerte es gut 13 Stunden. Danach steht tatsächlich eine sinnvoll einsetzbare, rund 1,9 GByte große Linux-Installation zur Verfügung, mit funktionierendem SSL und Python/OpenCV - und vor allem einem funktionierenden rpm -Package-Manager.
Allerdings gibt es mehrere kleine Einschränkungen: Die Bootzeit hat sich nun merklich verlängert. Mit der Arduino-IDE funktioniert das Board dann nicht mehr, mit den IDE-kompilierten Sketches auch nicht. Die Arduino-Pins können aber weiterhin angesprochen werden.
Was auch mit einem Package Manager weiterhin nicht trivial ist: das Hinzufügen von Kernel-Modulen. Der Trick ist, bei der Image-Erstellung zuerst
bitbake virtual/kernel -c menuconfig
aufzurufen, bevor das eigentliche Image gebaut werden soll. Dann können über eine grafische Oberfläche Kernel-Module aus- und abgewählt werden.
Und wie geht es weiter?
Nachdem wir zwei Wochen gebraucht haben, um das Board nutzbar zu machen, werden wir versuchen, tatsächlich ein wenig damit herumzuspielen. Dazu mehr in einem späteren Artikel.
Fazit
Nach vielen Stunden - zunehmend unfreiwilliger - Beschäftigung mit Intels Galileo lässt uns das Board etwas ratlos zurück.
Intels Galileo ist ein echtes Embedded-Board mit Arduino-Zuckerguss. Um es richtig einzuordnen: Gerade weil das Galileo-Board auf eine Grafikeinheit verzichtet, ist es ohnehin im Prinzip ein Entwicklerboard für Fortgeschrittene, die Formulierungen "einsteigerfreundlich" und "easy to use" sind da fehl am Platz, wenn nicht auch noch ein Linux-Zuckerguss dazukommt.
Wird dieser Arduino-Zuckerguss abgekratzt, sieht sich der Nutzer den klassischen Herausforderungen und Voraussetzungen der Embedded-Programmierungen gegenüber. Wer also bislang nur mit Arduino und dem Raspberry Pi gearbeitet hat, für den ist die Frustration programmiert.
Technisch ist am Board wenig auszusetzen, Yocto als Mini-Linux im Flash-Speicher auf dem Board ist in Ordnung. Aber es ist unverständlich, warum Intel dieses Linux auch für die Speicherkarte vorsieht.
Am schlimmsten stoßen aber die Mängel bei der Installation auf. Diese sind echte Showstopper und hätten bereits nach zwei oder drei Stunden Beschäftigung mit dem Board auffallen müssen.
Laut Intel wird bereits an einem Update gearbeitet, das betrifft sowohl die Linux-Distribution als auch die IDE. Zukünftig ist auch geplant, über ein Portal wie Github die Entwicklung vollständig zu öffnen. Für die Unterstützung weiterer Linux-Varianten gibt es derzeit Überlegungen, aber noch keine konkreten Pläne. Intel weist dazu explizit darauf hin, dass die notwendigen Galileo-Treiber Open Source sind und von anderen Linux-Distributionen genutzt beziehungsweise portiert werden dürfen.