One ROM – Praxis: Entwickler-Workflow mit Makefile und automatischem Flash per CLI

Im letzten Beitrag ging es darum, One ROM als EPROM-Ersatz für schnelle Firmware-Tests zu verwenden.
Diesmal gehen wir noch einen Schritt weiter:

👉 Wie sieht ein wirklich praxisnaher Entwickler-Workflow aus, wenn Kompilieren, Flashen und Testen möglichst schnell gehen sollen?

Genau hier spielt One ROM seine Stärken voll aus.

---

Das Ziel

Wer an Firmware für ältere Rechner, Eigenbau-Systeme oder EPROM-basierte Hardware arbeitet, möchte in der Regel immer das Gleiche:

• Quellcode ändern
• Firmware neu bauen
• sofort ins Zielsystem übertragen
• direkt testen

Mit einem klassischen EPROM-Programmiergerät ist das auf Dauer mühsam.
Mit One ROM lässt sich dieser Ablauf deutlich verkürzen.

---

Der Grundgedanke

Die Idee ist einfach:

1. Firmware wird auf dem PC gebaut
2. das erzeugte Binary wird automatisch an One ROM übertragen
3. danach wird das Zielsystem neu gestartet oder zurückgesetzt
4. die neue Firmware läuft sofort

👉 Statt „EPROM ziehen, brennen, einsetzen“ reicht dann oft ein einziger Befehl.

---

Typischer Aufbau

Für so einen Workflow braucht es nicht viel:

• einen PC oder Laptop zum Entwickeln
• One ROM im Zielsystem
• USB-Verbindung zum One ROM
• die One ROM CLI
• ein Build-System, zum Beispiel make

Das Zielsystem selbst bleibt dabei unverändert.
Für den Rechner oder die Platine sieht One ROM weiterhin einfach wie ein normales ROM oder EPROM aus.

---

Der klassische Ablauf – und warum er nervt

Ohne One ROM sieht eine Änderung oft so aus:

1. Code ändern
2. Build starten
3. EPROM programmieren
4. alten Chip entfernen
5. neuen Chip einsetzen
6. testen

Das funktioniert – aber es kostet Zeit und macht gerade bei vielen kleinen Änderungen keinen Spaß.

---

Der moderne Ablauf mit One ROM

Mit One ROM kann derselbe Vorgang so aussehen:

1. Code ändern
2. make flash eingeben
3. wenige Sekunden warten
4. Reset drücken
5. testen

👉 Genau dieser Unterschied macht One ROM beim Entwickeln so interessant.

---

Ein einfaches Beispielprojekt

Nehmen wir an, dein Projekt erzeugt am Ende eine Datei namens firmware.bin.

Die Verzeichnisstruktur könnte zum Beispiel so aussehen:

projekt/
├── src/
├── build/
├── Makefile
└── firmware.bin

Das ist natürlich nur ein Beispiel – entscheidend ist nur, dass dein Build am Ende ein ROM-Image erzeugt.

---

Der erste Schritt: Nur bauen

Bevor wir das Flashen automatisieren, sollte der normale Build bereits sauber laufen.

Ein sehr einfaches Makefile könnte so aussehen:

PROJECT = firmware
BUILD_DIR = build
IMAGE = $(BUILD_DIR)/$(PROJECT).bin

all: $(IMAGE)

$(IMAGE):
	mkdir -p $(BUILD_DIR)
	@echo Erzeuge $(IMAGE)
	@copy /b src\firmware.bin $(IMAGE)

clean:
	rmdir /s /q $(BUILD_DIR)

Das Beispiel ist bewusst simpel gehalten.
In einem echten Projekt würdest du hier natürlich Assembler, C-Compiler oder Linker aufrufen.

---

Der nächste Schritt: Flashen per CLI

Jetzt kommt One ROM ins Spiel.

Sobald dein Binary erzeugt wurde, kann es direkt per CLI übertragen werden.
Der eigentliche Flash-Befehl sieht dabei zum Beispiel so aus:

onerom program build/firmware.bin

Danach ist die neue Firmware im One ROM gespeichert.

---

Makefile mit Flash-Ziel

Spannend wird es, wenn du den Flash-Vorgang direkt in dein Makefile einbaust.

Ein einfaches Beispiel:

PROJECT = firmware
BUILD_DIR = build
IMAGE = $(BUILD_DIR)/$(PROJECT).bin
ONEROM = onerom.exe

all: $(IMAGE)

$(IMAGE):
	if not exist $(BUILD_DIR) mkdir $(BUILD_DIR)
	@echo Erzeuge $(IMAGE)
	copy /b src\firmware.bin $(IMAGE)

flash: $(IMAGE)
	$(ONEROM) scan
	$(ONEROM) inspect
	$(ONEROM) program $(IMAGE)

clean:
	if exist $(BUILD_DIR) rmdir /s /q $(BUILD_DIR)

Damit reicht unter Windows später:

make flash

👉 Das Makefile baut dann zuerst das Binary und überträgt es anschließend direkt auf das One ROM.

---

Variante unter Linux

Unter Linux oder macOS sieht das Ganze fast genauso aus, nur mit anderen Shell-Kommandos:

PROJECT = firmware
BUILD_DIR = build
IMAGE = $(BUILD_DIR)/$(PROJECT).bin
ONEROM = ./onerom

all: $(IMAGE)

$(IMAGE):
	mkdir -p $(BUILD_DIR)
	@echo "Erzeuge $(IMAGE)"
	cp src/firmware.bin $(IMAGE)

flash: $(IMAGE)
	$(ONEROM) scan
	$(ONEROM) inspect
	$(ONEROM) program $(IMAGE)

clean:
	rm -rf $(BUILD_DIR)

---

Warum scan und inspect sinnvoll sind

Man könnte natürlich direkt program aufrufen.
In der Praxis ist es aber oft sinnvoll, vorher noch zwei Dinge zu tun:

• scan prüft, ob das Gerät überhaupt gefunden wird
• inspect zeigt den aktuellen Zustand des One ROM

👉 Gerade wenn man mit mehreren Geräten arbeitet oder verschiedene Testaufbauten auf dem Tisch hat, spart das viele Missverständnisse.

---

Noch komfortabler: Alles mit einem einzigen Befehl

Der eigentliche Charme liegt darin, dass du dir einen sehr kurzen Zyklus aufbauen kannst:

make flash

Das ist dann der gesamte Entwicklungsablauf:

• ändern
• bauen
• flashen
• testen

Mehr braucht es oft nicht.

---

Optional: automatischer Neustart

Wenn dein Aufbau es zulässt, kannst du nach dem Flashen auch noch einen Neustart des One ROM auslösen:

flash: $(IMAGE)
	$(ONEROM) scan
	$(ONEROM) inspect
	$(ONEROM) program $(IMAGE)
	$(ONEROM) reboot

Ob das im konkreten Aufbau sinnvoll ist, hängt vom Zielsystem ab.
Oft reicht auch ein manueller Reset am Rechner oder an der Testplatine.

---

Mehr Sicherheit durch eigenes Flash-Ziel

In der Praxis ist es oft sinnvoll, nicht all automatisch zu flashen, sondern dafür ein eigenes Ziel wie flash zu verwenden.

Der Grund ist einfach:

👉 Nicht jeder Build soll sofort auf die Hardware geschrieben werden.

Manchmal will man nur kompilieren, manchmal disassemblieren, manchmal vergleichen.
Mit einem eigenen Ziel bleibt das sauber getrennt.

---

Beispiel für einen typischen Tagesablauf

Ein realistischer Workflow könnte dann so aussehen:

1. Quellcode ändern
2. make zum schnellen Test des Builds
3. make flash, wenn das Binary auf die Hardware soll
4. Gerät resetten
5. Verhalten prüfen

Das klingt banal – spart aber im Alltag enorm Zeit.

---

Noch besser: verschiedene Firmware-Varianten

Besonders elegant wird es, wenn du mehrere Firmware-Varianten parallel baust.

Zum Beispiel:

• normale Version
• Debug-Version
• Test-Version mit zusätzlichem Logging

Ein Makefile könnte dafür mehrere Ziele bekommen:

flash-release: build/release.bin
	$(ONEROM) program build/release.bin

flash-debug: build/debug.bin
	$(ONEROM) program build/debug.bin

👉 So kannst du gezielt genau die Variante flashen, die du gerade brauchst.

---

One ROM statt EPROM-Brenner

Gerade an dieser Stelle merkt man, wie groß der Unterschied zur klassischen Arbeitsweise ist.

Früher:

• Brenner anschließen
• EPROM löschen
• EPROM programmieren
• Chip wechseln

Heute:

• make flash
• fertig

Das spart nicht nur Zeit, sondern auch mechanischen Verschleiß an Sockeln und Chips.

---

Typische Stolperfallen

Natürlich klappt auch so ein Workflow nicht immer auf Anhieb.

Kein Gerät gefunden

Wenn scan kein One ROM findet, liegt das oft an:

• schlechtem USB-Kabel
• fehlender Verbindung
• einem noch geöffneten Web-Interface
• mehreren angeschlossenen Testgeräten

Gerade der letzte Punkt ist wichtig:
Wenn mehrere Geräte am Tisch liegen, sollte man sauber mit Seriennummern oder getrennten Setups arbeiten.

---

Falsches Binary geflasht

Auch das passiert schneller als man denkt.

Deshalb lohnt es sich:

• Ausgabedateien sauber zu benennen
• Release und Debug klar zu trennen
• alte Builds regelmäßig zu löschen

---

Reset vergessen

Nach dem Flashen muss das Zielsystem die neue Firmware natürlich auch wirklich neu einlesen.

Je nach Aufbau bedeutet das:

• Reset-Taster drücken
• Rechner neu starten
• Versorgung kurz aus- und wieder einschalten

---

Wo dieser Workflow besonders stark ist

Das Ganze lohnt sich vor allem bei:

• Eigenbau-Computern
• 8-Bit- und 16-Bit-Systemen
• Monitor- oder Boot-ROM-Entwicklung
• Diagnosesoftware
• experimentellen Firmware-Versionen

Überall dort, wo häufig kleine Änderungen getestet werden, spart dieser Ablauf enorm Zeit.

---

Praxistipp: erst klein anfangen

Auch wenn die komplette Automatisierung reizvoll ist:

👉 Am Anfang lieber klein starten.

Also zuerst:

• Binary sauber erzeugen
• per CLI manuell flashen
• danach Flash-Schritt ins Makefile übernehmen

So lässt sich jeder Schritt einzeln testen und Fehler sind leichter zu finden.

---

Fazit

One ROM ist als EPROM-Ersatz nicht nur praktisch – mit CLI und Makefile wird daraus ein richtig angenehmer Entwickler-Workflow.

Die Kombination aus:

• Build-System
• One ROM CLI
• schnellem Flashen per USB

macht aus einem früher eher mühsamen Prozess einen sehr direkten Ablauf.

👉 Gerade für Firmware-Entwicklung an älteren oder EPROM-basierten Systemen ist das ein echter Gewinn.

---

Ausblick

Ein sinnvoller nächster Schritt wäre dann zum Beispiel:

• mehrere Firmware-Versionen parallel verwalten
• automatische Vergleichstests
• ein Setup mit Debug- und Release-ROM im selben One ROM