Embedded-Programmierung im Umbruch

Inhaltsverzeichnis

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.