Original-URL des Artikels: https://www.golem.de/news/intel-edison-ausprobiert-ich-seh-dich-das-mona-lisa-projekt-1411-110577.html    Veröffentlicht: 20.11.2014 09:04    Kurz-URL: https://glm.io/110577

Intel Edison ausprobiert

Ich seh dich - das Mona-Lisa-Projekt

Beim Kleinrechner Edison macht Intel vieles richtig. Das erspart uns in einem neuen Bastelprojekt graue Haare. Ein großer Kritikpunkt bleibt allerdings.

Von Da Vincis Mona Lisa heißt es, ihre Augen würden den Betrachter verfolgen. Davon inspiriert haben wir mit dem Intel Edison Arduino Kit ein Projekt umgesetzt, das ein Paar künstlicher Augen per Gesichtserkennung ebenfalls einer Person folgen lässt. Ganz nebenbei loten wir dabei die Leistung des auf 500 MHz getakteten Dual-Core-Atom im Edison aus. Wir prüfen auch, ob Intel bei der Entwickler- und Software-Unterstützung auf die Kritik aus der Community reagiert hat. Die grundlegenden technischen Daten haben wir bereits in einem früheren Artikel über das Edison-Modul beschrieben.

Der Edison - ein Modul, verschiedene Boards

Nach den beiden Kleinrechnern Galileo 1 und Galileo 2 ist der Edison das dritte Produkt von Intel, das - auch - auf die Maker-Szene zielt. Während die Galileo-Boards klassische Tüftler-Boards sind, ist der Edison erst einmal nur ein Modul: eine kleine Platine mit Prozessoren (ein Dual-Core-Atom und ein Quark), RAM, Flash-Speicher sowie Bluetooth- und Wifi-Technik. Die Verbindung zur Außenwelt übernimmt ein kleiner Stecker mit 70 Pins.

Intel bietet zwei Boards an, auf die das Modul aufgesteckt werden kann, um sinnvoll mit ihm arbeiten zu können. Das Arduino-ähnliche Board bringt nicht nur Pin-Leisten im Arduino-Layout, sondern auch USB-Anschlüsse für verschiedene Aufgaben, einen MicroSD-Karten-Slot, einen Stromanschluss und diverse Taster zum Ein- und Ausschalten. Daneben gibt es noch ein reines Breakout-Board, das im Wesentlichen die 70 Pins des Modulsteckers im 2,54-mm-Raster ausführt und ansonsten nur einen USB-Anschluss ergänzt. Seeed Studio hat ebenfalls eine Reihe von kleinen Platinen angekündigt, die spezielle Funktionen des Moduls nutzbar machen.

Intel reagiert auf Trend

Kleinrechner und Entwicklerkits werden immer häufiger direkt in fertigen Produkten verbaut, anstatt dass auf Basis dieser Designs eigene Platinen konzipiert und angefertigt werden. Das ist zwar einfacher und bei Kleinserien durchaus preiswerter - aber Entwicklerkits brauchen mehr Platz, schleppen vom Produkt ungenutzte Elektronik mit sich herum, und wenn die Stückzahlen größer werden, wird es doch teuer.

Durch die Trennung von Rechner und Peripherie können Entwickler einen Mittelweg einschlagen: Die Entwicklung erfolgt über das Edison-Modul mit Hilfe des Arduino-Boards oder handgelötet per Breakout-Board. Für das fertige Produkt hingegen ist nur noch eine, einfacher zu konzipierende, Platine für die Peripherie notwendig. Das komplexere Edison-Modul hingegen kann einfach weiterverwendet werden. Auch die Raspberry Pi Foundation verfolgt mit dem Compute-Modul den gleichen Ansatz für den Raspberry Pi.



Betriebssytem-Update per Dateikopieren

Nach dem Auspacken des Arduino-Kits muss das Intel Edison-Modul erst einmal auf das Board gesteckt und mit zwei kleinen Schrauben gesichert werden. Danach wird das Board über die beiden Micro-USB-Anschlüsse mit einem Rechner verbunden. Die äußere USB-Schnittstelle wird vom Rechner als serielle Schnittstelle erkannt, über die innere Schnittstelle wird ein Teil des Flash-Speichers auf dem Rechner als externes Speichermedium dargestellt. Eine zusätzliche Stromversorgung ist an diesem Punkt nicht notwendig.

Das Betriebssystem wird beim Edison auf dessen Flash-Speicher installiert. Das Arduino-Board hat zwar einen SD-Karten-Slot, allerdings ist es noch nicht gelungen, damit von einer SD-Karte auch zu booten.

Um den Intel Edison auf den neuesten Stand des Yocto-Linux zu bringen, müssen wir das Betriebssystem-Image auf den Flash-Speicher packen. Dazu laden wir die aktuelle Version des Archivs mit den Systemdateien herunter. Das Archiv wird entpackt, und die enthaltenen Dateien werden einfach per Dateimanager auf den Edison kopiert. Danach müssen wir uns mit dem Screen-Kommando auf dem Edison über die serielle Schnittstelle einloggen. Dort rufen wir reboot ota auf. Den Rest erledigt der Edison beim Neustart selbst.

Alternativ ist es auch möglich, ein neues System komplett mit einem Kommandozeile-Aufruf einzuspielen. Intel liefert ein entsprechendes Skript mit. Das empfiehlt sich zum Beispiel, wenn das Betriebssystem-Image selbst konfiguriert und erstellt wurde.

Gleich, welcher Weg gewählt wird, der ursprüngliche Inhalt des Flash-Speichers geht beim Update verloren.

Erste Konfiguration per USB

Nach dem Neustart loggen wir uns wieder per serieller Schnittstelle auf dem Edison ein und konfigurieren und aktivieren über ein Edison-eigenes Konfigurationswerkzeug den WLAN-Zugang. Nach der erfolgreichen Verbindung merken wir uns die vergebene IP. Wir schalten den Edison wieder aus und ziehen die beiden USB-Kabel ab. Stattdessen stecken wir ein Netzteil an, wodurch der Edison sofort startet. Nach 20 Sekunden können wir uns per SSH über das WLAN verbinden.

Über das Konfigurationswerkzeug können weitere, kleinere Einstellungen vorgenommen werden. Zum Beispiel kann der Hostname des Edison festgelegt werden.



Yocto-Linux und IDEs



Beim Test des Intel Galileo waren wir von Yocto-Linux alles andere als begeistert. Yocto ist weniger eine klassische Distribution als ein Baukasten, mit dem eine eigene Distribution für Embedded System konfiguriert und erstellt werden kann. Das wäre als solches noch kein Problem, nur war das Standard-Image des Galileo eher sparsam mit Software ausgestattet, und es erforderte Zeit sowie Know-how, zusätzliche Software zu installieren, sowie einen Desktop-Rechner für die notwendigen Tätigkeiten.

Auch das Linux-Image des Edison basiert wieder auf Yocto. Intel hat während einer Fragerunde auf der Maker Faire 2014 in Rom auch noch einmal bestätigt, dass das Unternehmen für den Galileo und den Edison an Yocto festhalten wird, trotz anhaltender Kritik durch die Community.

Zwei Dinge machen den Umgang mit Yocto auf dem Edison aber mittlerweile angenehmer. Zum einen ist die Basisinstallation auf dem Edison deutlich umfangreicher und enthält nun unter anderem auch eine GCC-Installation. Zum anderen gibt es inzwischen ein - wenn auch inoffizielles - Package Repository für den Galileo wie auch den Edison.

Dass Yocto ein auf OPKG basierendes Package-Managementsystem enthält, dokumentiert Intel nun auch zum ersten Mal - denn eine eigene Entwicklerbibliothek wird merkwürdigerweise über ein eigenes Repository angeboten. Doch zu dieser später mehr.

Alternativ kann auch Ubilinux auf dem Edison eingesetzt werden. Diese Linux-Distribution auf Debian-Basis wurde ursprünglich für den Galileo konzipiert und ist inzwischen auch auf dem Edison lauffähig. Sie wird dort im Flash-Speicher anstelle des Yocto-Linux installiert.

Die IDEs im Überblick

Intels Fork der Arduino IDE unterstützt auch den Edison. Ein kompilierter Sketch wird über die serielle USB-Schnittstelle auf dem Edison permanent im Flash-Speicher abgelegt und sofort gestartet. Auch nach einem Neustart und dem Booten wird der Sketch automatisch wieder ausgeführt.

Die Arduino IDE sollte aber nicht darüber hinwegtäuschen, dass auch auf dem Edison-Arduino-Board nicht jedes Shield funktioniert, noch jeder Sketch oder jede Arduino-Bibliothek.

Das dürfte einer der Gründe dafür sein, dass Intel neue, eigene Entwicklungsumgebungen favorisiert: eine IDE mit dem etwas sperrigen Namen Intel XDK IoT Edition für die Programmierung mit Node.js und die genauso kryptisch benannte IoT DK-IDE, bei der es sich um ein vorkonfiguriertes Eclipse Kepler handelt - inklusive Cross-Compiler-Werkzeuge.

Beiden ist gemeinsam, dass sie über das Netzwerk mit dem Edison kommunizieren statt über USB. Auch Remote-Debugging ist darüber möglich. Dafür laufen auf dem Edison spezielle Dienste. Diese Art von Schnittstelle ist durchaus ein Sicherheitsrisiko. Deshalb kann der Zugriff auf den Edison mit dem Werkzeug iotkit-agent auf festgelegte IPs beschränkt werden.

Die Eclipse-basierte IDE enthält keine Überraschungen; wer Eclipse ansatzweise kennt, sollte keine Probleme haben. Einzig anders ist die Notwendigkeit, Eclipse mitzuteilen, unter welcher IP der Edison erreichbar ist. Ansonsten funktionieren die Entwicklung und das Debuggen wie bei Eclipse gewohnt.

Node.js statt Arduino

Die XDK-IoT-IDE ist einerseits eine optisch schlanke, anfängerfreundliche IDE im Vergleich zu Eclipse, andererseits deutlich mehr IDE als die sehr rudimentäre Arduino-IDE. So enthält die XDK-IDE ein Projektmanagement und einen Debugger.

Gedacht ist die XDK-IDE für die Entwicklung von serverseitigen Node.js-Anwendungen wie clientseitige HTML-5-/Javascript-Apps für Smartphones und Tablets.

Die IDE kümmert sich nicht nur um die Übertragung von Node.js-Anwendungen auf den Edison. Die Anwendung wird als NPM-Package generiert und korrekt installiert. Erfordert die Anwendung zusätzliche Node.js-Module, werden diese auf dem Edison automatisch installiert beziehungsweise auch kompiliert, wenn dies notwendig ist.

Der Debugger kommt uns bekannt vor, es handelt sich dabei offensichtlich um den Chrome-Debugger, der auch das Remote-Debugging von Javascript-Anwendungen beherrscht.

Im Verhalten identisch mit der Arduino-IDE ist die dauerhafte Speicherung der Javascript-Anwendung auf dem Flash-Speicher des Edison und dem automatischen Start der Anwendung, auch nach einem Neustart.



GPIO-Pins einfacher ansprechen



Im Galileo-Artikel haben wir ausführlich erklärt, wie die GPIO-Pins des Boards unter Linux angesprochen werden können. Das ist längst nicht so einfach wie mit den Funktionen digitalWrite&Co in Arduino-Sketches. Intel hat nun mit seinen neuen IDEs auch eine eigene Bibliothek vorgestellt, welche die Steuerung der Pins genauso einfach macht: MRAA. Laut Intel wurde die Buchstabenfolge des Namens willkürlich ausgewählt.

Die Bibliothek kümmert sich darum, den Pins nach Arduino-Zählung auf den Boards den intern verwendeten Hardware-Pins zu zu ordnen und auch korrekt zu initialisieren. Dabei muss der Entwickler sich nicht darum kümmern, auf welchem der Intel-Boards das Programm läuft. Ein auf dem Edison kompiliertes Programm, welches an Pin 1 eine LED an- und ausschaltet, spricht auch auf dem Galileo-Board Pin 1 an, obwohl sich die Hardware-Umsetzung der Pins unterscheidet.

Es gibt nicht nur die einfachen Funktionen, wie digitale und PWM-basierte Schaltvorgänge auszulösen sowie analoge Eingabe einzulesen. Auch Daten können über die Bussysteme SPI und I2C versendet und empfangen werden.

Mit Github ein Blick in die Zukunft

MRAA steht auf Github im Quellcode zur Verfügung, sollte aber einfach aus Intels Package-Repository heraus installiert werden - es ist das einzige Package darin. Ein Blick in das Git-Repository lohnt aber trotzdem. Intel scheint den Einsatzzwecke der Bibliothek nicht auf seine Bastelrechner beschränken zu wollen. Es gibt bereits eine rudimentäre Unterstützung für Intels DE3815-Plattform. Dabei handelt es sich um ein lüfterloses NUC-System, um einen Single-Core-Atom mit 1,64 Ghz. Der entsprechenden Header-Datei zufolge soll dieses beziehungsweise ein zukünftiges System immerhin 18 ansteuerbare GPIO-Pins aufweisen.

Für den Einsatz in eigenen C/C++-Projekten stehen die notwendigen Header-Dateien zur Verfügung. Für Node.js und Python gibt es entsprechende Module.

Neben MRAA wird von Intel eine zweite Bibliothek bereitgestellt: UPM. Diese ist modular aufgebaut und bietet High-Level-Funktionen für Sensoren und Aktuatoren, allerdings sind diese typenspezifisch. Und die Dokumentation ist noch recht rudimentär.



Augen gerade aus! Oder nach links oder rechts



Augen, die dem Betrachter folgen - die Magie besteht darin, dass über eine Webcam ein Bereich überwacht wird. Mit Hilfe der Bibliothek OpenCV prüfen wir, ob im Bild ein Gesicht erkannt wird. Ist das der Fall, wird ein Servo angesteuert, der die Augen in die Richtung dreht, in der das Gesicht gefunden wurde.

Im Kern handelt es sich dabei um eine Neuauflage unseres Laika-Projektes beim Galileo, allerdings in neuer Verpackung. Wir waren hier bewusst unkreativ, um einen Leistungsvergleich zum Galileo ziehen zu können. Aber auch, um zu testen, ob wir mit der MRAA-Bibliothek tatsächlich einfacher programmieren können, ohne uns neue Probleme aufzuhalsen.

Wegen des Versprechens der Einfachheit von MRAA haben wir aber auch eine einschneidende Änderung bei der Umsetzung beschlossen: Statt wie bei Laika in Python zu programmieren, haben wir diesmal C++ genommen. Wir verzichten dabei auch auf die Unterstützung durch die Eclipse-IDE, sondern arbeiten mehr oder weniger allein auf der Kommandozeile des Edison über SSH. So wollen wir herausfinden, ob die Linux-Installation tatsächlich so brauchbar ist, wie unser erster Eindruck nahelegte.

Ein kleiner, aber folgenschwerer Konfigurationsfehler

Bevor wir uns an das eigentliche Programm setzen, testen wir ein wenig die angeschlossene Webcam mit Hilfe von Kommandozeilenprogrammen, experimentieren mit der GCC-Installation und probieren MRAA mit Node.js sowie OpenCV mit Python aus. Wir wollen sichergehen, dass sowohl die Servo-Ansteuerung als auch OpenCV mit der Kamera funktionieren, bevor wir sie in einem C++-Programm zusammenpacken. Das zieht sich über mehrere Tage hin.

Als wir dann ein neues Package installieren wollen, erhalten wir eine unerwartete Fehlermeldung: kein Speicherplatz mehr. Wir rufen df -h auf und staunen nicht schlecht. Die Root-Partition ist tatsächlich komplett voll. Der größte Teil des Flash-Speichers ist für Benutzerverzeichnisse (2 GByte) reserviert, nur 500 MByte für System- und Programmdateien. Das ist zwar nicht sonderlich viel, aber weder haben wir ein großes Office-Paket installiert noch große Grafikprogramme oder IDEs.

Nach einer kurzen Recherche in Intels Maker-Forum finden wir heraus, dass wir nicht die einzigen mit diesem Problem sind. Das System ist derart konfiguriert, dass bestimmte Log-Dateien nicht gelöscht oder rotiert werden. Nachdem wir diesen Punkt umkonfiguriert und die alten Log-Dateien gelöscht haben, haben wir wieder 140 MByte frei.



Programmieren in C++ und mit MRAA



Um es vorwegzunehmen: Die Programmierung für den Edison ist tatsächlich einfacher als beim Galileo. Das zeigt sich schon am Code-Umfang. Der neu geschriebene Quellcode ist deutlich kürzer als der des Laika-Projektes auf dem Galileo und auch weniger erklärungsbedürftig. Würden wir das Laika-Projekt mit MRAA auf dem Edison umsetzen, würde sich der Quellcode vermutlich von rund 300 Zeilen auf gut 120 Zeilen reduzieren.

Der Quellcode unseres Mona-Lisa-Programms kann heruntergeladen werden.

Die main()-Funktion des Programms ist recht übersichtlich und besteht aus vier Teilen: der Initialisierung des GPIO-Pins, mit dem der Servo angesteuert wird, und dem Laden der Gesichtserkennungsdaten. Am Ende starten wir einen zusätzlichen Thread, in dem die eigentliche Gesichtserkennung durchgeführt wird und schließlich lassen wir OpenCV die Kamerabilder holen.

String cascadefile = "haarcascade_frontalface_alt2.xml"; VideoCapture capture; CascadeClassifier face_cascade; mraa::Gpio* gpio; int main(int argc, const char** argv) { pthread_t thread; gpio = new mraa::Gpio(4); gpio->dir(mraa::DIR_OUT); gpio->mode(mraa::MODE_STRONG); if(!(face_cascade.load(filename))) { return 1; } capture.open(0); if(!capture.isOpened()) { return 1; } int rc = pthread_create(&thread, NULL, faceThread, NULL); while(1) { capture.grab(); } return 0; }



OpenCV übernimmt die Gesichtserkennung



Dass die Gesichtserkennung in einem eigenen Thread läuft, hat einen einfachen Grund: Sie ist rechenzeitintensiv, die angelieferten Bilder der Kamera werden gepuffert. Liefe das Holen des Bildes und dessen Auswertung im gleichen Thread, würden wir beim nächsten Schleifendurchgang ein Bild unbekannten Alters aus dem Puffer erhalten. Mit capture.grab() leeren wir stets den Puffer und sorgen dafür, dass im Thread mit capture.retrieve() immer nur das aktuelle Bild ausgewertet wird:

void *faceThread(void *arg) { Mat img; while(1) { if(capture.retrieve(img)) { checkFace(img); } } }

Die eigentliche Erkennung läuft in der Funktion checkFace(). Diese Funktion sah ursprünglich so aus:

void checkFace(Mat img) { ... cvtColor(img, gray, CV_BGR2GRAY); equalizeHist( gray, gray); face_cascade.detectMultiScale(small, faces, 1.1, 2, CV_HAAR_SCALE_IMAGE); if(faces.size() > 0) { int p = faces[0].x + (faces[0].width/2); int pd = map_pixel_to_deg(p); servo(180 - pd); } }

Das Kamerabild wird in ein Graustufenbild umgewandelt, die Farbverteilung im Bild normalisiert und schließlich auf Gesichter geprüft. Die detectMultiScale()-Methode liefert für jedes gefundene Gesicht ein Rect-Objekt zurück. Es enthält die xy-Koordination eines Rechtecks sowie dessen Höhe und Breite. Jedes Rechteck beschreibt also, wo im Bild ein Gesicht gefunden wurde. Wir ermitteln auf Basis dieser Daten dann die x-Koordinate der Mitte des Rechtecks. Sie wird in eine Grad-Angabe (0 - 180 Grad) umgerechnet und der Funktion servo() zur Ansteuerung des Servos übergeben.



Der Edison beeindruckt



Als wir zum ersten Mal das Programm in dieser Form aufrufen, staunen wir nicht schlecht. Die Gesichtserkennung läuft auf dem Edison mit dem 500-MHz-Atom langsamer als auf dem Galileo mit seinem 400-MHz-Quark-Prozessor.

Wir überlegten, wo unser Fehler sein müsste, und experimentieren mit den Optionen für detectMultiScale() herum. Durch Einschränkung der maximalen Erkennungsgröße gelingt es uns, die Erkennung von einigen Sekunden auf gut eine Sekunde herunterzudrücken - womit der Edison nun gleich auf mit dem Erfahrungswert beim Galileo liegt.

Erst ein eher beiläufiger Blick auf das originale Laika-Skript bringt die Lösung. Dort haben wir das angelieferte Bild der Kamera auf 176 x 144 Pixel verkleinert, damit die Gesichtserkennung nicht ewig braucht. Bei unserem Edison-Programm haben wir hingegen das unverkleinerte Kamerabild geprüft. Wir probieren die Verkleinerung auf diese Größe auch im Edison-Programm und schon wird die Gesichtserkennung deutlich öfter aufgerufen.

Final entscheiden wir uns, die Bildgröße auf 256 x 192 Pixel zu reduzieren: ... resize(gray, small, Size(256, 192)); ...

Damit ist die Bilderkennung noch schnell genug, um annähernd einen Echtzeiteffekt bei der Augenbewegung zu erzielen. Andererseits werden dann auch noch Personen erkannt, die nicht direkt vor der Kamera stehen.

Um noch einmal den Leistungsunterschied zwischen dem Quark-Prozessor auf dem Galileo und dem Atom-Prozessor auf dem Edison zu verdeutlichen: Der matrixbasierte Mustererkennungsalgorithmus von OpenCV verarbeitet in der gleichen Zeit auf dem Edison problemlos die doppelte bis dreifache Datenmenge, die der Galileo schafft.

Mit OpenCV-Gesichtserkennung hatten wir damals auch den Raspberry Pi und den Galileo miteinander verglichen. Damals gewann noch der Raspberry Pi mit leichtem Vorsprung.



Servo ansteuern leicht gemacht



Die Ansteuerung des Servos ist deutlich einfacher als beim Galileo, trotzdem wenden wir etwas mehr Code auf, um den Ablauf verständlicher zu gestalten.

Zur Erinnerung: Ein Servo wird gesteuert, indem ein elektrischer Impuls mit einer definierten Dauer an den Servo geschickt wird. Die Länge steht für die anzusteuernde Position, dabei entspricht der kürzeste erkannte Impuls 0 Grad, der längste 180 Grad.

Beim Galileo war es nicht möglich, derart kurze Schaltzeiten direkt zu realisieren, weshalb wir per PWM tricksen mussten. Beim Edison hingegen sind diese Schaltzeiten möglich. Deswegen ist die Funktion für die Servoansteuerung auch recht einfach:

void servo(int deg) { unsigned long t = map_deg_to_time(deg); unsigned long b, a; unsigned long period = 20000; a = time(); b = time(); gpio->write(1); while(t > (b - a)) { b = time(); } gpio->write(0); while(period > (b - a)) { b = time(); } }

Die aufgerufene Funktion map_deg_to_time() rechnet die übergebene Gradzahl in die benötigte Zeitdauer um. Dann wird der Pin, über den der Servo angesteuert wird, auf High (=1) geschaltet. Als nächstes wird die ermittelte Zeitdauer abgewartet. Ist sie verstrichen, wird der Pin wieder auf Low (=0) geschaltet, das Signal beendet. Zum Schluss wird erneut eine kurze Zeitspanne abgewartet. Das verhindert, dass ein zweiter Aufruf der Funktion zu früh erfolgt, und das Signal vom Servo womöglich falsch oder gar nicht interpretiert wird.

Der eine oder andere wird sich fragen, warum wir die Zeitdauer so umständlich herunterzählen, statt zum Beispiel usleep() zu nutzen. Auf diese Weise verringern wir die Möglichkeit, dass uns das Betriebssystem während der Wartedauer in die Quere kommt - allerdings auf Kosten der Performance des gesamten Systems.

Eine kleine Optimierungsmöglichkeit für die Servo-Ansteuerung wäre es, statt von Pixel in Grad in Zeitdauer direkt von Pixel in Zeitdauer umzurechnen, außerdem vermeiden wir so sich aufaddierende Rundungsfehler. Der Zwischenschritt macht unser Vorgehen aber transparenter und verständlicher.



Stromverbrauch und Fazit

Während unserer Experimente behielten wir den Stromverbrauch im Blick. Im Betrieb mit dem WLAN, aber ohne Bluetooth, lag der Leistungsbedarf zumeist bei 1,5 bis 1,6 Watt, selbst mit aktivem Servo stieg der Wert nicht über 2 Watt.

Fazit

Der Edison macht keine schlechte Figur, und auch beim Thema Software-Unterstützung und Community lernt Intel dazu. Das sollte aber nicht darüber hinwegtäuschen, dass die Verwendung von Yocto erst dank der Hilfe der Community halbwegs anwenderfreundlich wird und die Einstiegshürde nicht unterschätzt werden sollte.

Betrachten wir nur die Hardware, so hält sich der Edison wacker. Der 500-MHz-Dual-Core-Atom liegt bei OpenCV-basierten Aufgaben mindestens auf Augenhöhe mit dem Raspberry Pi mit seinem 700-MHz-ARM-Prozessor. Gegen aktuelle 1-GHz-ARM-Prozessoren hingegen dürfte der Edison verlieren.

Doch diese Leistungsvergleiche dürfen über eines nicht hinwegtäuschen: Für Bastler gibt es aktuell kein Board aus dem ARM-Lager, das einen recht leistungsfähigen Prozessor, Bluetooth und WLAN auf einem sehr kleinen Modul vereint.

Der Preis von 90 Euro für die Kombination aus Arduino-"kompatiblem" Board inklusive Edison-Modul scheint zwar erst einmal viel. Da das Modul zum konkurrenzfähigen Einzelpreis von 50 Euro aber abnehmbar ist und das Board weiterverwendet werden kann, relativiert sich der Preis für ambitionierte und semiprofessionelle Bastler. Und genau auf diese scheint Intel abzuzielen: Bastler, die potenziell eine (Klein-)Serien-Produktion ihres Projektes im Auge haben.

Die Lage könnte sich noch einmal ändern, wenn die Ankündigung wahr wird, dass Intel den Zugriff auf den Quark-Prozessor im Edison-Modul auch für Programmierer erlaubt. Dieser kümmert sich derzeit um die IO des Edison und verwendet ein eigenes RTOS. Dann wäre zum Beispiel ein Linux-System mit zuschaltbaren Echtzeitfähigkeiten denkbar, oder die Abhandlung von GPIO-Aktivitäten ganz ohne Linux-Overhead.  (am)


Verwandte Artikel:
Lenovo Ideapad 720S im Test: AMDs Ryzen Mobile gegen Intels Kaby Lake R   
(08.03.2018, https://glm.io/132924 )
Intel: Edison-Module und Arduino-Board werden eingestellt   
(28.04.2017, https://glm.io/127567 )
Aaeon UP Core Plus: Entwickler-Platine koppelt Intel Atom mit AI-Hardware   
(28.02.2018, https://glm.io/133045 )
Intel Edison: Kleinrechner mit Arduino-ähnlichem Board als Breakout   
(09.09.2014, https://glm.io/109137 )
ARM-SoC-Hersteller: Qualcomm darf NXP übernehmen   
(19.01.2018, https://glm.io/132261 )

© 1997–2019 Golem.de, https://www.golem.de/