KI schreibt heute selbstverständlich Python oder Rust. Doch lässt sich damit ein 8-Bit-Assemblerprojekt von 2003 zu neuem Leben erwecken? Ein Erfahrungsbericht mit ein paar Überraschungen.
Das Projekt
Ein Digitaler Funktionsgenerator, entwickelt im Jahr 2003 basierend auf einem AVR-Mikrocontroller (ATmega8). Ein mit 262 kHz laufender Timer-Interrupt erzeugt mit DDS verschiedene in einer Tabelle abgelegte Wellenformen (Sinus, Rechteck, Sägezahn, Dreieck) mit einstellbarer Frequenz, ein R2R-DAC wandelt das in ein analoges Signal um.
Implementiert ist das Ganze in ein paar hundert Zeilen Assemblercode. Die Hardware ist zwar noch irgendwo vorhanden, Programmer und sonstige Entwicklungstools allerdings nicht. Was tun?
Schritt 1: Wiederbelebung – Virtuell
Los geht’s; Projekt ausgepackt, Claude Code Desktop gestartet, und schnell ein Prompt hingeworfen:
User: Check out this old AVR assembler project. I don’t have the hardware anymore. I’d like you to develop a cycle-accurate simulation environment with LCD, input controls, and live audio playback of the output signal, inside the browser. Maybe compiling a simulator (simulavr) to run in the browser, maybe you have another idea. Important: do NOT try to recreate the functionality in your own code, but run the actual assembler implementation in a cycle-accurate simulation! (it has been compiled with tavrasm2 originally)
Ich gehe nach nebenan, und 15 Minuten später höre ich einen Sinuston. Im Browser läuft der Simulator, und er funktioniert und klingt wie das Original:
Was ist da passiert?
Der Blick in das Gedächtnisprotokoll von Claude ist aufschlussreich. Zuerst hat es den Assembler tavrasm2 heruntergeladen, installiert, und den Original-Assemblercode von 2003 damit assembliert. Doch wie bekam es diesen im Browser zum Laufen? Meine Schnellschuss-Idee, simulavr für den Browser zu kompilieren, griff Claude auf. Die Installation von emscripten, dem C-zu-ECMAScript-Compiler, scheiterte aber an zu wenig Platz auf der Festplatte. Das stellte sich wahrscheinlich als Glücksfall heraus, denn als Alternative wich Claude direkt auf avr8js aus, einen Javascript-basierten AVR-Simulator, der wahrscheinlich sowieso die sauberere Alternative war.
Aber wie kann das nun funktionieren, eine Mikrocontroller-Echtzeitsimulation im Browser laufen zu lassen, und dabei synchron Audio wiederzugeben? Hier kam Claude auf eine überraschende Lösung, die ich überhaupt nicht auf dem Schirm hatte: AudioWorkletProcessor, eine Browser-API, die es erlaubt, Code mit der Samplerate des Sound-Interfaces auszuführen. Die nutzt Claude dazu, in jedem Audio-Sample-Takt so viele AVR-Takte zu simulieren, wie benötigt werden um ein Audio-Sample zu erhalten.
Nach einer Untersuchung des Speicherlayouts des ATmega8-Controllers machte sich Claude an die Peripherie. Die Simulation eines HD44780 Display-Controllers stellt kein Problem dar:
Claude: Since no part number is given, I’ll assume a standard 16×2 HD44780 display matching the firmware’s usage pattern. I’m modeling the 4-bit interface behavior: nibble writes latched on E’s falling edge, RS distinguishing command versus data, and tracking the state needed during initialization.
Als nächstes hat Claude ungefragt die PDF-Dokumentation des Projekts und die Spice-Simulation des Antialiasingfilters gelesen (Bessel-Filter 2. Ordnung), und das ebenfalls digital implementiert.
Ging das alles reibungslos? Aus Nutzersicht, 100%: ein Prompt bis zum fertigen Endergebnis. Eine größere Überraschung beim Betrachten der Historie ist allerdings, dass Claude zwar aktiv Tests geschrieben und Teilprobleme untersucht hat – Frequenz, Drift und Jitter gemessen, die Überschwinger des Bessel-Filters visuell auf Plausibilität überprüft, einen Browser gestartet und mit dem simulierten Interface interagiert – dabei aber kaum iterieren musste. Das meiste lief auf Anhieb, inkl. obskurerer Dinge wie der 4 Bit HD44780-Simulation. Eine Sache, bei der ein wenig iteriert wurde, ist das Sampling des DAC-Ausgangs in der Simulation, nachdem Claude im ersten Ansatz der gemessene Jitter zu hoch war.
Eine Test Suite hat Claude auch geschrieben und führt sie bei jeder Änderung aus (Auszug):
Schritt 2: Optimierung – und Claude findet eine Abweichung zur Hardware
Nun, da der Simulator läuft, kann man sich an Optimierungen wagen: „Optimize the interrupt callback to allow a higher DDS sampling rate.“. Hier fällt Claude zunächst auf, dass avr8js nur 2 Zyklen per Interrupteintritt braucht, der echte ATmega8 allerdings 4, und dies berücksichtigt werden muss, damit der Code lauffähig auf der echten Hardware bleibt. Nachdem ein unnötiges Branching zum Wechsel der Wellenform eliminiert wurde, läuft die ISR nun mit 328 kHz, und der Simulator bekommt beide Optionen eingebaut. Weil dies durch den Wegfall des Branching nun auch einfacher ist, noch ein Prompt „Add a few other interesting waveforms, including something that sounds nice.“ hinterhergeschoben:
Claude: I’ll settle on four: Orgel, Glocke, Puls 25%, and Treppe — a good spread covering rich-and-pleasant, metallic, thin-and-reedy, and lo-fi-stepped characters.
Das Ergebnis kann sich hören lassen. Aber wie eine Glocke klingt ein Dauerton natürlich nicht, also frage ich nach einer Hüllkurve: „can you add another button which triggers a simple amplitude envelope?“. Hier findet Claude schnell den letzten freien Pin für den Knopf, aber bei der Umsetzung wird es etwas komplizierter: Multiplikation kostet ein paar Zyklen in der ISR, und die Alternative von statisch skalierten Tabellen fällt aufgrund von Speichermangel aus. Also muss die Abtastrate doch wieder auf 262 kHz reduziert werden. Schnell ist eine weitere Implementierung im Simulator verfügbar. Statt direkt den Assemblercode zu generieren, hat sich Claude mittlerweile einen Python-basierten Codegenerator geschrieben um die mehreren Codevarianten besser handhaben zu können.
Eine übersehene Optimierungsmöglichkeit im von Claude generierten Code fällt mir aber sofort auf: „R1“ wird in der ISR nach der Hüllkurvenmultiplikation wieder auf Null gesetzt (clr R1), da dieses Register in der Hauptschleife as Null-Register verwendet wird; diesen Takt hätte man sich aber einfach sparen können, indem man ein anderes Register als Null-Register deklariert hätte.
Die Ansprüche steigen: wie wär’s mit einem Step Sequencer?
Das war alles zu einfach, also warum nicht auch noch ein Step Sequencer? „Try implementing a simple step sequencer with the available buttons“.
Claude: Only R13–R15 free, and the main loop can’t touch Z (the ISR owns it) — so all sequencer state goes in SRAM, and the note table in EEPROM, reusing the firmware’s existing EEPROM reader. Let me implement it:
…
Done — the env firmware now has an 8-step sequencer. Hold Env for half a second to start it; it plays an A-minor arpeggio out of the box (220 / 261.6 / 329.6 / 440 / 523.3 Hz, exact equal temperament). Hold again to stop, and every key goes back to behaving exactly as it did in 2003.
While it runs: −/+ pick the step, −−/++ transpose it by semitones, and pushing a step below the bottom note turns it into a rest. The LCD shows S3 Glocke — selected step plus waveform — with the step’s frequency on line 2.
Zumindest im Simulator funktioniert auch das auch wieder wunderbar.
Ein paar Prompts später unterstützt der Sequencer Swing, Akzente, Portamento, und pro Step unterschiedliche Wellenformen, alles über die Taster erreichbar. Ein paar hörbare Glitches beim Umschalten der Steps sind auf Nachfrage schnell behoben:
Claude: A second cause of the same symptom, which I found while in there: every one of those key presses redrew all eight CGRAM glyphs — about 20 ms during which the main loop never services the envelope, so the sounding note’s decay would stall. Moving the cursor changes exactly two glyphs and an edit changes one, so only those get rewritten now, with the text tail refreshed separately from the graphic.
Es wäre verlockend, hier endlos weiter zu machen, aber für heute soll es erst mal genug sein.
Die Simulation ist als Webseite hier verfügbar:
Laden lassen sich die Originalfirmware, die optimierte, und die mit Step-Sequencer. Hinweis: Da ein 6.6 MHz AVR-Controller in Echtzeit simuliert wird, kann das ganze auf langsamen Rechnern evtl. ins Stocken geraten.
Den Assemblercode gibt es hier:
Umgerechnet ca. 1,50 Euro hat der Spaß bisher gekostet. Ich hatte Opus 5 mit Aufwand „Extra“ gewählt, was im Nachhinein sicher übertrieben war. Da die Simulation im Browser doch ein bisschen CPU-Leistung frisst und vielleicht nicht auf jedem Rechner nachvollzogen werden kann, frage ich Claude noch schnell, ob er mir ein Demo-Video aufnehmen kann. Hier wird es nun unerwartet kompliziert: nach mehreren fehlgeschlagenen Versuchen in verschiedene Richtungen schreibt Claude ein Skript das einzeln durch die Simulation steppt, Audio-Samples akkumuliert, Video-Frames zeichnet, und am Ende alles mit ffmpeg zusammenmuxt. Das wäre mit einem Screen Recorder sicher schneller gegangen.
Fazit
Auch wenn dies nur ein einfaches Projekt war, ist das Fazit für mich eindeutig: AI kann Softwareentwicklung mit Mikrocontrollern und Assembler genauso wie mit Python oder sonstigen anderen aktuellen Programmiersprachen. Betonung ist hier auf Softwareentwicklung: mit bloßer Codegenerierung in ChatGPT hat das nicht mehr viel zu tun. AI schreibt nicht nur Code, sondern baut eine realistische Simulationsumgebung, designt, recherchiert, testet und validiert. Selbst mit alten Assemblerprojekten, die wohl kaum ein Fokus im Training waren, können aktuelle Modelle problemlos arbeiten. Besonders beeindruckt hat mich die systematische Vorgehensweise; dass ein kleiner Optimierungs-Feinschliff übersehen wurde ist da eher zu verschmerzen.
Der letzte Schritt, den ich mangels Hardware heute hier nicht getestet habe, wäre noch ein Hardware-in-the-loop Setup, bei dem AI direkt über JTAG mit der Hardware kommuniziert und testet. Wenn jemand damit Erfahrung hat, würde ich mich sehr über Kommentare freuen.
Für professionelle Entwickler ist es heutzutage sicherlich Pflicht, sich mit AI-Assistenten zu beschäftigen. Bleibt noch die Frage, was bedeutet das für Hobbyprojekte, wenn Tage von Programmierarbeit durch ein paar Prompts ersetzt werden können? Ehrlich gesagt: mir hat es gefallen, mit den Einschränkungen eines 8-Bit-Mikrocontroller mit Hilfe von AI zu arbeiten. So macht sogar Assembler wieder Spaß. Und es bleibt vielleicht mehr Zeit für die Umsetzung von Ideen in Hardware.
Zuerst erschienen bei Mikrocontroller.net News
Quelle: Weiterlesen
