zurück zum Artikel

Aufgrund langer Produktzyklen und hoher Fehlschlagrisiken erweist sich der Embedded-Bereich als vergleichsweise innovationsscheu. Doch gilt auch hier, dass die Zeit des Zählens von Bits so langsam vorbei ist. Das liegt auch an Systemen wie Arduino und Raspberry Pi, die einen einfacheren Einstieg in Embedded ermöglichen.

Aufgrund langer Produktzyklen und hoher Fehlschlagrisiken erweist sich der Embedded-Bereich als vergleichsweise innovationsscheu. Doch gilt auch hier, dass die Zeit des Zählens von Bits so langsam vorbei ist. Das liegt auch an Systemen wie Arduino und Raspberry Pi, die einen einfacheren Einstieg in Embedded ermöglichen.

Eine kleine Veranstaltung in Berlin wurde vor einigen Monaten zur Bühne für einen handfesten Generationenkonflikt in Sachen Embedded-Programmierung: Im Rahmen einer QA-Session gerieten zwei Streitparteien aneinander, die unterschiedlicher nicht sein können. Auf der einen Seite stand Massimo Banzi, der Miterfinder des Einplatinen-Computers Arduino, auf der anderen ein pensionierter Rüstungsmanager einer osteuropäischen Miliz.

Der Disput fand seinen Auslöser durch Banzis Aussage, dass sein Computersystem jedem den Zutritt in die faszinierende Welt der Mikroelektronik ermöglichen würde. Dank diverser Hochsprachen seien nun auch Künstler, Grafiker und Architekten zum Konstruieren von Gadgetry befähigt – und das ohne langwieriges Studium der internen Architektur des verwendeten AVR-Controllers. Von Seiten des Managers kam daraufhin der Einwand, dass die damit erstellten Produkte aus technischer Sicht nur mangelhaft sein könnten – wer die interne Architektur der zugrunde liegenden MCU (Microcontroller Unit) nicht verstehe, erstelle keine effizienten Applikationen. Der wortgewandte Italiener erwiderte darauf sinngemäß, dass ihm die Effizienz völlig egal sei – wichtig sei die Kreativität, die durch seine Hardware freigesetzt werde.

Wieso Processing?

Das Publikum teilte sich schnell in zwei Gruppen auf. Die Mehrheit der Teilnehmer der Konferenz schlug sich auf Seiten des Arduino-Schöpfers. Die verschwindend geringe Minderheit fokussierte ihre Kritik vor allem an der als Entwicklungsumgebung verwendeten Sprache Processing. Diese ist alles andere als hardwarenah, der aus der Hochsprache generierte Assembler-Code lässt sich nicht ohne Weiteres nachvollziehen.

ARM-Prozessoren haben eine derartig komplexe interne Architektur, dass das Erstellen einer in Assembler gehaltenen Anwendung nur für die diensterfahrenen Entwickler realisierbar ist. Durchschnittliche Programmierer sind mit dem Erlernen des Hardwareaufbaus zumeist überfordert, der Einsatz einer Hochsprache ist deswegen in den häufigsten Fällen gerechtfertigt.

Arduinos basieren auf ATMega-Prozessoren aus dem Hause Atmel. Sie sind mit Sicherheit etwas komplexer als der althergebrachte PIC16F84A-Microchip -- die interne Architektur lässt sich trotzdem ohne allzu große Probleme an einem Nachmittag begreifen. Aufgrund der eher geringen Rechenleistung und des einfachen Aufbaus ist der Einsatz von Hochsprachen aus technischer Sicht alles andere als sinnvoll. Zudem "übt" das Programmieren in Assembler das Gehirn der Entwickler. Ein kleiner Teil der Kritiker ging aus diesem Grund sogar so weit, Banzi vorzuwerfen, dass er dafür verantwortlich wäre, dass die nachkommenden Programmierer zunehmend weniger "praktische Erfahrung" mitbrächten. Die Mehrheit der Anwesenden ging jedoch davon aus, dass die Kreativität der Nutzer wichtiger sei als die technische Effizienz des resultierenden Systems.

Werte schaffen

Das beste Gegenbeispiel fand sich einige Wochen später im nahen Umfeld des Autors. Eine technisch nicht sonderlich begabte Lebensgefährtin eines Elektronikers nutzte einen Arduino, um ihre Kaffeemaschine vom Bett aus fernsteuern zu können – wenn die Dame den oberen Stock ihrer Wohnung in Richtung Küche verlassen hatte, stand eine Tasse Betriebsstoff bereit.

Mit Sicherheit hätte sich dieser Aufbau auch mit einem PIC16F84A und Assembler realisieren lassen; das resultierende Gerät wäre um einige Cent billiger und würde sicherlich mit etwas weniger Rechenleistung auskommen. Der springende Punkt liegt an anderer Stelle. Die Dame konnte ihre Fernsteuerung selbst – das bedeutet ohne Hilfe von Technikern oder ihres Mannes – konstruieren. Dadurch schuf sie eigenständig einen Wert, den sie ohne Arduino niemals hätte realisieren können. Ihr Leben wurde somit um ein technisches Gerät reicher, das sie sonst nicht (oder nur mit viel Aufwand) hätte erhalten können.

Auf gesamtgesellschaftliche Sicht gesehen entstand dadurch eine nicht unwichtige Veränderung. Die Nutzerin lernte, dass sie durch Wille, Fleiß und Einarbeitung ein komplexes technisches Gerät realisieren kann.

Zeit kostet Geld

Beim Deployment von Arduino und Co. darf ein "weicher" Vorteil nicht unterschätzt werden. Für Quereinsteiger vorgesehene Entwicklungsumgebungen bringen im Allgemeinen weitaus mehr Debugger-Unterstützung mit – wer einmal einen Fehler in einem Programm für einen PIC16F84A gesucht hat, kann ein Lied über diese mühevolle und wenig ergiebige Sisyphusarbeit singen. Die dazu notwendige Zeit kann bei kleinen Produktionsmengen den Preis für teurere Prozessoren mehr als aufwiegen.

Doch damit nicht genug: Die meisten Arduino-Konfigurationen bestehen aus Kombinationen von tausendfach erprobten Komponenten. Diese sind oft von mehreren Anbietern verfügbar – bei elektrischen Problemen ist es leicht, technische Unterstützung zu finden. Ein selbst konstruiertes Mainboard kann hier in mehrerlei Hinsicht nicht mithalten. Erstens ist es heute alles andere als einfach, Kleinserien zu beordern: Wenn man die Platinen nicht selbst zusammenbauen möchte, kostet schon allein das Ätzen des Mainboards ein kleines Vermögen. Zweitens ist man bei einer Eigenentwicklung nie vor simplen Fehlern gefeit. Softwarefehler lassen sich vergleichsweise einfach reparieren – das Entwerfen einer neuen Platine kostet Länge mal Breite. Zu guter Letzt besteht noch das Risiko von Konflikten mit den Regulierungsbehörden.

Fazit

Logische Abwehrreaktionen

Etablierte Entwickler von Embedded-Systemen stehen diesen Gedanken mit Sicherheit alles andere als erfreut gegenüber. Dabei handelt es sich – zumindest bis zu einem gewissen Grad – um eine logische Abwehrreaktion, die die Verteidigung der eigenen Pfründe avisiert. Solange das Entwerfen von Embedded-Steuerungen eine komplizierte Aufgabe darstellt, lässt sich mit Beratungsdienstleistungen viel Geld verdienen. Wenn erst einmal jeder durchschnittliche Programmierer zum Realisieren eingebetteter Steuerungen befähigt ist, sieht die Situation völlig anders und für die Berater alles andere als befriedigend aus.

Viele Unternehmen gehen beim Verteidigen ihrer Pfründe sogar soweit, dass sie ihre Kunden mit Absicht schädigen. Der Einsatz programmierbarer Suchköpfe könnte im Rüstungsbereich zu einem Quantensprung führen – die etablierten Unternehmen setzen nur deshalb nicht auf diese Technologie, da sich ihre Margen dadurch wesentlich verschmälern würden.

Pragmatismus ist immer falsch

Eine alte Weisheit im Bereich des Software Engineering besagt, dass es keine silbernen Kugeln gibt. Das gilt auch für die Entwickler von Embedded-Systemen: Bei einem für die Massenfertigung vorgesehenen Produkt ergibt das Einsparen einiger Cents an Hardwarekosten Sinn. In diesem Fall wäre die Verwendung von Assembler und einem "kleinen" Controller mit Sicherheit gerechtfertigt – für ein in Kleinserie produziertes System sieht die Kalkulation naturgemäß völlig anders aus.

Daraus folgt, dass das Erlernen einer Assembler-Sprache meist keine vergebene Liebesmühe ist. Ein in Elektronik versierter Programmierer findet in den häufigsten Fällen jede Menge an Aufträgen. Für einen in Hochsprachen entwickelnden Programmierer ist die Lage weitaus weniger eindeutig: Heutige Compiler sind so weit von der Hardware entfernt, dass der Assembler-Code kaum mehr nachvollziehbar ist. Zudem unterscheidet sich die Hardware eines ARM- oder x86-Prozessors so stark von einem primitiven Mikrocontroller, dass Abstraktionen nicht mehr ohne weiteres möglich sind.

Das Ende einer Ära

Die von Banzi vertretene Sicht der Dinge ist genauso falsch wie die des pensionierten Managers. Der beste Weg liegt, wie so oft, in der Mitte. Auch wenn es für den einen oder anderen mit Assembler aufgewachsenen Veteranen schwer zu akzeptieren ist: Die Branche lebt heute in einer Zeit, in der Speicher und Rechenleistung nur mehr eine untergeordnete Rolle spielen. Wer seine Programmiererkarriere unter Palm OS begann, zeichnete in der Anfangszeit Speicherlayouts auf kariertes Papier. Beim Palm IIIc war das nicht mehr notwendig – heutige Smartphones haben ein oder zwei Gigabyte Arbeitsspeicher.

Der Embedded-Bereich erweist sich aufgrund langer Produktzyklen und hoher Fehlschlagrisiken als vergleichsweise innovationsresistent. Trotzdem gilt auch hier, dass die Zeit des "Bitzählens" vorbeigeht. Schnelle Arduinos rechnen Kreise um klassische Mikrocontroller. Einplatinen-Computer wie Arduino, Raspberry Pi und BeagleBone bieten Rechenleistungen, die vor zehn Jahren im Workstation-Bereich üblich waren.

Avioniker erlebten vor einigen Jahrzehnten eine ähnliche Umstellung: Analogrechner galten als erprobt, konnten aber mit den Leistungen ihrer digitalen "Kollegen" nicht mithalten. Im Laufe der Zeit stellten alle Unternehmen um – wer als Erster "sprang", konnte sich im Rennen um die Technologieführerschaft bessere Plätze sichern.

Tam Hanna
befasst sich seit der Zeit des Palm IIIc mit Programmierung und Anwendung von Handheldcomputern. Er entwickelt Programme für diverse Plattformen, betreibt Onlinenews-Dienste zum Thema und steht für Fragen, Trainings und Vorträge gern zur Verfügung. (ane [1])

URL dieses Artikels:
https://www.heise.de/-2082301

Links in diesem Artikel:
[1] mailto:ane@heise.de

Copyright © 2014 Heise Medien