Verzeihen Sie mir, liebe Cortex-M[x]-Fans, aber meine aktive Beschäftigung mit dieser Thematik geht zurück auf die Zeiten, als die Mikrocontroller-Programmierung noch interessant und quasi als Selbstzweck betrieben wurde. Begeisterte Männer fuhren weit über 100 km, um sich über die Komplexität und Schönheit eines 8-bit-Systems auszutauschen, das nur dann vernünftig zum Laufen zu bringen war, wenn man wirklich alle Register zog.
So etwa ging es damals in unserer CDP1802 User Group zu, als wir glücklich waren, eine Art Software zu besitzen, mit der sich um das gekümmert wurde, das wir am meisten fürchteten: die Software! Regeln bezüglich eines Human Interface Designs gab es nicht. Stattdessen vielleicht einen Taster, einen Summer und eine ordinäre 5-mm-LED. Trotz der eher primitiven Anfänge im Jahre 1985 war uns doch allen klar, dass wir hier Zukunftstechnik in den Händen hielten. Wenn man nämlich dazu in der Lage ist, eine LED per Software einzuschalten, dann kann man doch genauso gut eine Rakete damit starten. Und Sie können mir glauben: Einer von uns hat „so etwas Ähnliches“ damals im CERN gemacht – wenn auch vermutlich mit einem anderen Prozessor.

Zu der Zeit gab es viel Aufmerksamkeit für zwei begabte Club-Mitglieder, die eine Cold-Boot-Sequenz in den 256 Byte statischem RAM unterbrachten und die Sache mit einem Batterie-Backup aus zwei AA-Batterien versahen. Man konnte das Ding starten und darauf warten, dass die LED auf dem Board aufleuchtete und dann Code von Kassette in den Audio-Eingang des Systems einspielen. Das Programm konnte sogar schon „automatisch“ seine eigene Integrität und das der Daten vom Band überprüfen. Anschließend wurde ein 4-KB-System-Monitor installiert und konfiguriert, was dann zu zweimaligem Aufleuchten der LED führte, und endlich wurde das größere OS von – tatsächlich: Floppy-Disk – in den enormen Arbeitsspeicher von 48 Kilobyte dynamischem RAM auf einer Karte geladen. Und dann TINY BASIC und dann endlich: ein Bier! Und Spiele wie Cosmac Space Invaders.

Das war ein cleverer und ökonomischer Schachzug, denn statische RAM-Chips waren zu der Zeit sehr teuer. Ich betrachtete den Code auf Maschinenebene und staunte über seine Kompaktheit. Jedes Byte und jeder Taktzyklus wurden maximal ausgenutzt. Erst damit waren all die Wunder möglich. Sie werden es schon erwartet haben: Software wurde direkt in Op-Codes und nicht einmal in Assembler geschrieben. Kein Compiler hätte dies für die 256 zur Verfügung stehenden Bytes packen können.

Wir hatten kaum praktische Software für unser System und es gab auch keine Verlockungen von Killer-Applikationen, die es irgendwo zu kaufen gegeben hätte. Das Beste, was wir zustande brachten, das war eine Ampelsteuerung, alles in 1 KB Speicher, alles in CMOS-Technik mit erstaunlich geringem Strombedarf und großer Stabilität.

Heute ist die Mikrocontroller-Programmierung einfacher und komfortabler. Der enorme Umfang moderner Developer-Tools, von Compilern, Source-Code-Dateien, Debuggern und Daten, die man heutzutage über das Netz auf den PC zieht, übertreffen locker den Faktor 10.000 gegenüber dem resultierenden Code, den man dann letztlich für den Flash-Speicher seines AVR-, PIC- oder ARM-Controllers produziert. Aber das spielt keine Rolle, da es heute genug RAM gibt und auch die Tools kostenlos sind. Auch die restliche Hardware kostet lediglich Peanuts, und selbst der Internet-Provider verlangt nicht viel. Im Datenverbrauch der restlichen Familienmitglieder geht der Bedarf für Elektroniker fast unter. Eine ideale Basis für eine Killer-Applikation (nicht „App“) für ihren Lieblings-Mikrocontroller.

Und welches reale Mikrocontroller-System entwickeln Sie so, mit dem man Geld verdienen oder zumindest Geld oder Zeit sparen kann? Falls Ihnen tatsächlich etwas Brauchbares gelungen ist: Klicken sie auf die Schaltfläche „Kommentar schreiben“ und informieren Sie uns und alle Mitleser über Ihren Erfolg!