Embedded Systems am Scheideweg
Im März trafen sich in Bochum Embedded-Entwickler auf der emBO++. Die Konferenz offenbarte den schwierigen Spagat zwischen gewohnten Methoden und aktuellen Trends.
- Tam Hanna
Embedded-Entwickler gelten traditionell als Dinosaurier, die neue Techniken nur ungern annehmen. Auf der emBO++ in Bochum zeigte sich das Spannungsfeld zwischen neuen Herangehensweisen und liebgewonnenen Gewohnheiten.
Der alte Wettstreit zwischen C und C++ steht nach wie vor im Mittelpunkt: Diverse Unternehmen programmieren ihre Systeme in reinem C und verwenden OOP-Emulationsstrukturen, die zu kaum mehr wartbarem Code führen – insbesondere im Zusammenspiel mit Codegeneratoren und anderen Automatisierungstools.
Weiterentwicklungen in den Bereichen Compiler und Mikrocontroller sorgen dafür, dass das Verwenden von Teilen des C++-Sprachstandards mit minimalen oder nur schwer messbaren Performanceverlusten einhergeht. Wer C++ mitdenkend verwendet, den belohnt der Compiler dank Fehlererkennung mit wesentlich zuverlässigerem Code.
Die von Mozilla vorangetriebene Programmiersprache Rust wirkt dank diverser Entscheidungen der Sprachentwickler nahezu ideal für den Embedded-Bereich. Die mit C++ vergleichbare Performance und die strengere Syntax sorgen für Sauberkeit. Mit der 2018 verabschiedeten Stabilisierung des Userspace beginnt die Nutzung im Umfeld, und erste Konferenzen zu Rust auf Embedded Devices sind noch für dieses Jahr geplant. Auf der diesjährigen emBO++ gab es jedoch nur einen Workshop und einen Lightning Talk zu Rust.
An der Grenze der Überprüfbarkeit
Wer mit 8-Bit-Systemen arbeitet, lebt paradiesisch: Die Performance einer Assembler-Routine lässt sich von Hand berechnen. Komplexe Mikrocontroller erschweren die Situation immens – Abbildung 2 zeigt zur Veranschaulichung die Performance eines STM32-Controllers in unterschiedlichen Betriebsmodi. Steigerungen der Taktrate führen in manchen Situationen zu einer relativen Verlangsamung, weil Komponenten wie Flash-Speicher nicht linear schneller werden und bestimmte Algorithmen ausbremsen. Wer auf spezialisierte Dienste wie BareBench verzichtet, hat das Nachsehen.
Permanente Weiterentwicklung hat zu einer hohen Komplexität bei den C++- und USB-Standards geführt. Das im Automotive- und Embedded-Bereich weit verbreitete Framework Qt vollzieht die Entwicklung nur teilweise mit, weshalb sich mit CopperSpice ein Fork auf Basis von Qt 5.6 etabliert – er erfreute sich unter den Teilnehmern der Konferenz enormer Beliebtheit. Dass sich mehrere Vorträge mit Seltsamkeiten der C++-Spezifikation auseinandersetzten, sei allerdings ebenfalls angemerkt.
Hardware wird wichtiger
Soft- und Hardwareentwicklung waren einst zwei weitgehend voneinander isolierte Bereiche. Im Laufe der letzten Jahre zeigte sich – wohl auch durch Systeme wie Arduino –, dass die beiden Bereiche zunehmend zusammenarbeiten müssen.
Neben einem Workshop zum Leiterplattendesign mit der quelloffenen (und recht eigenwilligen) Designsoftware KiCad befassten sich einige Vorträge mit den Problemen und Lösungen im Bereich der niederschwelligen Fertigung von Hardware. Schließlich leistet sich nicht jedes Unternehmen ein zehnköpfiges Entwicklerteam, um ein kleines IoT-System zu realisieren.
Dabei zeigte sich die steigende Leistungsfähigkeit der Hardware: Immer mehr Aufgaben, die früher dedizierte Logik erledigte, entstehen nun in Software. Ein gutes Beispiel hierfür ist der Bluetooth-Stack Bluetoe, der in einem Vortrag Würdigung fand.
Umfangreiches Zusatzprogramm
Die diesjährige Ausgabe der emBO++ konnte auch im Rahmenprogramm das in den letzten Jahren gebotene Niveau halten – Teilnehmer bekamen umfangreich Gelegenheit zum privaten und professionellen Erfahrungsaustausch.
Neben diversen Gesprächen zu dem neuen heterogenen Prozessor STM32MP1 von ST, der ein Linux- und ein Echtzeitsystem auf einem Core vereint, war unter anderem die Weiterentwicklung von Testverfahren ein beliebtes Thema. Eine besonders interessante Implementierung nutzt den GPIB (General Purpose Interface Bus) und einen Saleae Logic, um im Rahmen eines Unit-Tests Hardwareinformationen zu sammeln – dank der Integration der beiden Systeme musste das Hardwareteam nur jene Logs ansehen, bei denen es zu seltsamem Verhalten kam.
