Komplexität beherrschen mit Open Source

Vor ein paar Tagen ist etwas spannendes passiert: Ich habe mein allererstes Embedded System wiedergesehen - eine nach nunmehr ca. 34 Jahren defekte Schrittmotorsteuerung für die Teleskope der Volkssternwarte Rothwesten, die ich in den Sommerferien in der 12. Klasse gebaut habe. Schaut man sich die Entwicklung von damals bis hin zu unseren aktuellen industriellen Embedded Systems an, wird schnell klar, warum sowas heute nur noch mit Open Source Software sinnvoll beherrschbar ist.

So ging's los

Aber erst mal zurück zum Anfang: Irgendwann in den frühen 90ern kam die Zeit, wo in der Schule auch mal ein paar spannende Themen an die Reihe kamen, und das waren für mich vor allem die Elektronik- und Astronomie AG. Und so kam auch schnell die Idee auf, ob man das nicht unter einen Hut bringen könnte.

Auf der Volkssternwarte Rothwesten, wo seinerzeit regelmäßig öffentliche Führungen machte, ging irgendwann der alte Plattenspielermotor zum Antrieb der Teleskopmontierung kaputt, und schnell war die Idee da, ob man da nicht was modernes, mit Microcontroller für basteln könnte.

Hardware

Ich glaube, es war 1990, als ich mich dann in den Sommerferien gemeinsam mit einem kundigen Familienmitglied hingesetzt haben und die Schrittmotorsteuerung im Bild oben entwickelt habe.

  • Der Prozessor ist ein 8035, ein Vorläufer des 8051, der nur addieren und schieben konnte. War halt ein 8-Bitter, der 4 KB externes ROM adressieren konnte.
  • Hochsprache war viel zu ressourcenaufwändig, und so entstand das Programm direkt in Assembler. So ein 8-Bitter hat halt auch nur 256 Befehle, die kann man alle auf DIN-A4 ausdrucken und über den Monitor kleben. Irgendwo fand sich dann noch ein handkopiertes Prozessor Manual, in dem die Befehle näher erklärt waren.
  • Damit man das externe EPROM anbinden konnte, musste der Adress- und Datenbus mittels eines Latches getrennt werden, das macht das 74HCT273 auf dem Bild.
  • EPROMs programmieren ging mit dem Commodore 128, da hatte ich eh schon ein EPROM-Programmiergerät aus der 64er nachgebaut. Als Schreibschutzaufkleber dienten handelsübliche Disketten-Schreibschutzaufkleber, die waren lichtdicht genug.
  • Und auch In-System-Programmieren ging schon: Dazu gab's auch aus irgend einer Computer-Zeitung (war's die c't, oder die MC, oder elrad?) einen EPROM-Simulator mit Parallelport und RAM.
  • Platine ätzen war viel zu aufwändig, wenn man einen Fehler gehabt hätte. Also, Lochrasterplatine und die Busse von Hand verdrahten.
  • Alle ICs waren natürlich gesockelt, damit man die im Fehlerfall auch schnell tauschen konnte.

Außen drumherum ist dann noch ein längsgeregeltes Netzteil mit Trafo für die Spannungsversorgung, eine FET H-Brücke zur Ansteuerung der Motorwicklungen, ein Bopla-Gehäuse vom Völkner in der Nachbarstadt und ein Kabel zur Handsteuerbox, die man mit an den Okularauszug nehmen konnte.

Software

Nachdem die Hardware die ersten Assembler-Hello-Worlds zufriedenstellend ausgeführt hat, ging es an die eigentliche Software. Schrittmotoren wollen passende Muster auf ihren Spulen sehen, da mussten Tabellen erzeugt werden, die man mit ein bisschen Pointer-Arithmetik im Kreis herum abarbeiten konnte.

Das Timing musste präzise eingehalten werden: So ein Teleskop muss sich in einem siderischen Tag (23 Stunden, 56 Minuten) ein mal um seine Achse drehen. Für mehrere Stufen "schneller" und "langsamer" Tasten mussten die Taster der Steuerbox abgefragt und die Geschwindigkeiten angepasst werden. Das ganze ist extrem feinfühlig, schließlich erlauben die großen Geräte Vergrößerungen bis zu ein paar hundertfach, so dass jede Ungenauigkeit gleich zu Ruckeln führt. Für die Sonnen- und Mondbeobachtung gab es angepasste Geschwindigkeiten, noch ein paar LEDs zur Status-Rückmeldung, und schließlich noch logarithmische Beschleunigungsrampen für smoothe Geschwindigkeitsübergänge.

Komplexität damals und heute

Am faszinierendsten finde ich aus heutiger Sicht eigentlich, dass das Gerät überhaupt 34 Jahre durchgehalten hat, bei Sonne, Winter, Sturm und Regen, überhaupt bei all diesen extremen Temperatur- und Feuchtigkeitsverhältnissen, die auf so einem exponierten Turm auf dem Rand eines Vulkankraters herrschen. Und das im IP54 Gehäuse, quasi ohne jeden Schutz.

Spannend ist natürlich, dass die Technik damals so wenig komplex war, dass man die als Zwölftklässler irgendwie innerhalb der Sommerferien in den Griff bekommen konnte - ohne Internet. Ein bisschen Löten, Drähtchen, eine Seite Befehlssatz, viel mehr brauchte man nicht und konnte sich sofort auf das fachliche Problem konzentrieren.

Und dann schaue ich mir heute die aktuellen Prozessoren an, die wir bei Pengutronix in unseren Industrieprojekten so tagtäglich in der Hand haben und die oftmals 15 bis 30 Tausend Seiten Dokumentation haben, mit Secure Boot, mit Ethernet, mit Power Management und jede Menge komplexer Software-Technologien. Die bis in die letzte Ecke ausgefeilt und so speziell sind, dass es auch bei uns keine Einzelpersonen mehr gibt, die das alles hinreichen bis in jede Ecke beherrschen, sondern eine Vielzahl an Experten für jedes noch so kleine Teilgebiet.

Da fragt man sich schon, wie wir damals eigentlich fachliche Probleme lösen konnten - wir hatten ja nüscht! :-) Aber natürlich hat sich das Umfeld auch massiv geändert, so dass es ohne Vernetzung, Funktechniken, IT-Security usw. heute bei vielen Systemen gar nicht mehr geht. Und dann steigt natürlich sofort massiv die Komplexität.

Damals wie heute war aber das wichtigste: Zugang zu offener Dokumentation. Man kann und konnte lernen, wie das alles funktioniert, und man kann und konnte Leute fragen, die sich damit auskennen. Heute haben wir Linux und jede Menge Open Source Komponenten, die erst mal einfach so funktionieren und die Hardware so weit zum Leben erwecken, dass man als Anwender auch auf diesen komplexen Boliden sich auf seine Anwendung konzentrieren kann.

Und Damals wie heute musste man die richtigen Leute kennen, die sich mit sowas auskennen und denen man ein Loch in den Bauch fragen konnte. Danke an Ingeborg Reuter, Peter Kirchhoff und Martin Dietz, die das damals für mich möglich gemacht haben. Und Danke an mein großartiges Team bei Pengutronix, dass all diese Sachen heute möglich macht - für mich und für alle, die unsere Ergebnisse im Linux-Kernel und all den anderen spannenden Open Source Projekten einfach so nutzen können!

Übrigens: Das schnell herbeigeschaffte Ersatzsystem für die kaputte Schrittmotorsteuerung hat der Kollege in Rothwesten über's Wochenende an den Start gebracht, mit ESP32 und damit auch wieder mit einem Open Source Ökosystem mit ganz viel offenem Wissen. Aber das ist eine andere Geschichte...


Weiterführende Links

Pengutronix at FrOSCon 2024

Am 17. und 18. 08. 2024 ist es wieder soweit: Die FrOSCon findet an der Hochschule Bonn-Rhein-Sieg in Sankt Augustin statt - und Pengutronix ist wieder als Partner dabei.


umpf - Git on a New Level

Moderne Softwareentwicklung ohne begleitende Versionsverwaltung wie Git ist heutzutage unvorstellbar - Änderungen am Quellcode sollen schließlich nachvollziehbar dokumentiert und beliebige Verssionsstände jederzeit einfach reproduziert werden können. Für Arbeiten an komplexeren Projekten wie etwa dem BSP ("Board Support Package") eines eingebetteten Systems mit mehreren Entwicklungssträngen skaliert ein bloßes Aufeinanderstapeln der einzelnen Änderungen jedoch nicht.


Yes we CAN... add new features

Have you ever experienced an otherwise fine product that is missing just the one feature you need for your application?