Im letzten Beitrag ging es darum, One ROM als EPROM-Ersatz f\u00fcr schnelle Firmware-Tests zu verwenden.
Diesmal gehen wir noch einen Schritt weiter:<\/p>\n
\ud83d\udc49 Wie sieht ein wirklich praxisnaher Entwickler-Workflow aus, wenn Kompilieren, Flashen und Testen m\u00f6glichst schnell gehen sollen?<\/strong><\/p>\n Genau hier spielt One ROM seine St\u00e4rken voll aus.<\/p>\n Wer an Firmware f\u00fcr \u00e4ltere Rechner, Eigenbau-Systeme oder EPROM-basierte Hardware arbeitet, m\u00f6chte in der Regel immer das Gleiche:<\/p>\n Mit einem klassischen EPROM-Programmierger\u00e4t ist das auf Dauer m\u00fchsam. Die Idee ist einfach:<\/p>\n \ud83d\udc49 Statt \u201eEPROM ziehen, brennen, einsetzen\u201c reicht dann oft ein einziger Befehl.<\/p>\n F\u00fcr so einen Workflow braucht es nicht viel:<\/p>\n Das Zielsystem selbst bleibt dabei unver\u00e4ndert. Ohne One ROM sieht eine \u00c4nderung oft so aus:<\/p>\n Das funktioniert \u2013 aber es kostet Zeit und macht gerade bei vielen kleinen \u00c4nderungen keinen Spa\u00df.<\/p>\n Mit One ROM kann derselbe Vorgang so aussehen:<\/p>\n \ud83d\udc49 Genau dieser Unterschied macht One ROM beim Entwickeln so interessant.<\/p>\n Nehmen wir an, dein Projekt erzeugt am Ende eine Datei namens Die Verzeichnisstruktur k\u00f6nnte zum Beispiel so aussehen:<\/p>\n Das ist nat\u00fcrlich nur ein Beispiel \u2013 entscheidend ist nur, dass dein Build am Ende ein ROM-Image erzeugt.<\/p>\n Bevor wir das Flashen automatisieren, sollte der normale Build bereits sauber laufen.<\/p>\n Ein sehr einfaches Makefile k\u00f6nnte so aussehen:<\/p>\n Das Beispiel ist bewusst simpel gehalten. Jetzt kommt One ROM ins Spiel.<\/p>\n Sobald dein Binary erzeugt wurde, kann es direkt per CLI \u00fcbertragen werden. Danach ist die neue Firmware im One ROM gespeichert.<\/p>\n Spannend wird es, wenn du den Flash-Vorgang direkt in dein Makefile einbaust.<\/p>\n Ein einfaches Beispiel:<\/p>\n Damit reicht unter Windows sp\u00e4ter:<\/p>\n \ud83d\udc49 Das Makefile baut dann zuerst das Binary und \u00fcbertr\u00e4gt es anschlie\u00dfend direkt auf das One ROM.<\/p>\n Unter Linux oder macOS sieht das Ganze fast genauso aus, nur mit anderen Shell-Kommandos:<\/p>\n Man k\u00f6nnte nat\u00fcrlich direkt \ud83d\udc49 Gerade wenn man mit mehreren Ger\u00e4ten arbeitet oder verschiedene Testaufbauten auf dem Tisch hat, spart das viele Missverst\u00e4ndnisse.<\/p>\n Der eigentliche Charme liegt darin, dass du dir einen sehr kurzen Zyklus aufbauen kannst:<\/p>\n Das ist dann der gesamte Entwicklungsablauf:<\/p>\n Mehr braucht es oft nicht.<\/p>\n Wenn dein Aufbau es zul\u00e4sst, kannst du nach dem Flashen auch noch einen Neustart des One ROM ausl\u00f6sen:<\/p>\n Ob das im konkreten Aufbau sinnvoll ist, h\u00e4ngt vom Zielsystem ab. In der Praxis ist es oft sinnvoll, nicht Der Grund ist einfach:<\/p>\n \ud83d\udc49 Nicht jeder Build soll sofort auf die Hardware geschrieben werden.<\/p>\n Manchmal will man nur kompilieren, manchmal disassemblieren, manchmal vergleichen. Ein realistischer Workflow k\u00f6nnte dann so aussehen:<\/p>\n Das klingt banal \u2013 spart aber im Alltag enorm Zeit.<\/p>\n Besonders elegant wird es, wenn du mehrere Firmware-Varianten parallel baust.<\/p>\n Zum Beispiel:<\/p>\n Ein Makefile k\u00f6nnte daf\u00fcr mehrere Ziele bekommen:<\/p>\n \ud83d\udc49 So kannst du gezielt genau die Variante flashen, die du gerade brauchst.<\/p>\n Gerade an dieser Stelle merkt man, wie gro\u00df der Unterschied zur klassischen Arbeitsweise ist.<\/p>\n Fr\u00fcher:<\/p>\n Heute:<\/p>\n Das spart nicht nur Zeit, sondern auch mechanischen Verschlei\u00df an Sockeln und Chips.<\/p>\n Nat\u00fcrlich klappt auch so ein Workflow nicht immer auf Anhieb.<\/p>\n Wenn Gerade der letzte Punkt ist wichtig: Auch das passiert schneller als man denkt.<\/p>\n Deshalb lohnt es sich:<\/p>\n Nach dem Flashen muss das Zielsystem die neue Firmware nat\u00fcrlich auch wirklich neu einlesen.<\/p>\n Je nach Aufbau bedeutet das:<\/p>\n Das Ganze lohnt sich vor allem bei:<\/p>\n \u00dcberall dort, wo h\u00e4ufig kleine \u00c4nderungen getestet werden, spart dieser Ablauf enorm Zeit.<\/p>\n Auch wenn die komplette Automatisierung reizvoll ist:<\/p>\n \ud83d\udc49 Am Anfang lieber klein starten.<\/p>\n Also zuerst:<\/p>\n So l\u00e4sst sich jeder Schritt einzeln testen und Fehler sind leichter zu finden.<\/p>\n One ROM ist als EPROM-Ersatz nicht nur praktisch \u2013 mit CLI und Makefile wird daraus ein richtig angenehmer Entwickler-Workflow.<\/p>\n Die Kombination aus:<\/p>\n macht aus einem fr\u00fcher eher m\u00fchsamen Prozess einen sehr direkten Ablauf.<\/p>\n \ud83d\udc49 Gerade f\u00fcr Firmware-Entwicklung an \u00e4lteren oder EPROM-basierten Systemen ist das ein echter Gewinn.<\/p>\n Ein sinnvoller n\u00e4chster Schritt w\u00e4re dann zum Beispiel:<\/p>\n One ROM \u2013 Praxis: Entwickler-Workflow mit Makefile und automatischem Flash per CLI Im letzten Beitrag ging es darum, One ROM als EPROM-Ersatz f\u00fcr schnelle Firmware-Tests zu verwenden.Diesmal gehen wir noch einen Schritt weiter: \ud83d\udc49 Wie sieht ein wirklich praxisnaher Entwickler-Workflow … Weiterlesen
\nDas Ziel<\/h2>\n
\n
Mit One ROM l\u00e4sst sich dieser Ablauf deutlich verk\u00fcrzen.<\/p>\n
\nDer Grundgedanke<\/h2>\n
\n
\nTypischer Aufbau<\/h2>\n
\n
make<\/code><\/li>\n<\/ul>\n
F\u00fcr den Rechner oder die Platine sieht One ROM weiterhin einfach wie ein normales ROM oder EPROM aus.<\/p>\n
\nDer klassische Ablauf \u2013 und warum er nervt<\/h2>\n
\n
\nDer moderne Ablauf mit One ROM<\/h2>\n
\n
make flash<\/code> eingeben<\/li>\n
\nEin einfaches Beispielprojekt<\/h2>\n
firmware.bin<\/code>.<\/p>\nprojekt\/\r\n\u251c\u2500\u2500 src\/\r\n\u251c\u2500\u2500 build\/\r\n\u251c\u2500\u2500 Makefile\r\n\u2514\u2500\u2500 firmware.bin\r\n<\/pre>\n
\nDer erste Schritt: Nur bauen<\/h2>\n
PROJECT = firmware\r\nBUILD_DIR = build\r\nIMAGE = $(BUILD_DIR)\/$(PROJECT).bin\r\n\r\nall: $(IMAGE)\r\n\r\n$(IMAGE):\r\n\tmkdir -p $(BUILD_DIR)\r\n\t@echo Erzeuge $(IMAGE)\r\n\t@copy \/b src\\firmware.bin $(IMAGE)\r\n\r\nclean:\r\n\trmdir \/s \/q $(BUILD_DIR)\r\n<\/pre>\n
In einem echten Projekt w\u00fcrdest du hier nat\u00fcrlich Assembler, C-Compiler oder Linker aufrufen.<\/p>\n
\nDer n\u00e4chste Schritt: Flashen per CLI<\/h2>\n
Der eigentliche Flash-Befehl sieht dabei zum Beispiel so aus:<\/p>\nonerom program build\/firmware.bin\r\n<\/pre>\n
\nMakefile mit Flash-Ziel<\/h2>\n
PROJECT = firmware\r\nBUILD_DIR = build\r\nIMAGE = $(BUILD_DIR)\/$(PROJECT).bin\r\nONEROM = onerom.exe\r\n\r\nall: $(IMAGE)\r\n\r\n$(IMAGE):\r\n\tif not exist $(BUILD_DIR) mkdir $(BUILD_DIR)\r\n\t@echo Erzeuge $(IMAGE)\r\n\tcopy \/b src\\firmware.bin $(IMAGE)\r\n\r\nflash: $(IMAGE)\r\n\t$(ONEROM) scan\r\n\t$(ONEROM) inspect\r\n\t$(ONEROM) program $(IMAGE)\r\n\r\nclean:\r\n\tif exist $(BUILD_DIR) rmdir \/s \/q $(BUILD_DIR)<\/pre>\n
make flash<\/pre>\n
\nVariante unter Linux<\/h2>\n
PROJECT = firmware\r\nBUILD_DIR = build\r\nIMAGE = $(BUILD_DIR)\/$(PROJECT).bin\r\nONEROM = .\/onerom\r\n\r\nall: $(IMAGE)\r\n\r\n$(IMAGE):\r\n\tmkdir -p $(BUILD_DIR)\r\n\t@echo \"Erzeuge $(IMAGE)\"\r\n\tcp src\/firmware.bin $(IMAGE)\r\n\r\nflash: $(IMAGE)\r\n\t$(ONEROM) scan\r\n\t$(ONEROM) inspect\r\n\t$(ONEROM) program $(IMAGE)\r\n\r\nclean:\r\n\trm -rf $(BUILD_DIR)<\/pre>\n
\nWarum
scan<\/code> und inspect<\/code> sinnvoll sind<\/span><\/h2>\nprogram<\/code> aufrufen.
In der Praxis ist es aber oft sinnvoll, vorher noch zwei Dinge zu tun:<\/p>\n\n
scan<\/code> pr\u00fcft, ob das Ger\u00e4t \u00fcberhaupt gefunden wird<\/li>\ninspect<\/code> zeigt den aktuellen Zustand des One ROM<\/li>\n<\/ul>\n
\nNoch komfortabler: Alles mit einem einzigen Befehl<\/h2>\n
make flash<\/pre>\n
\n
\nOptional: automatischer Neustart<\/h2>\n
flash: $(IMAGE)\r\n\t$(ONEROM) scan\r\n\t$(ONEROM) inspect\r\n\t$(ONEROM) program $(IMAGE)\r\n\t$(ONEROM) reboot<\/pre>\n
Oft reicht auch ein manueller Reset am Rechner oder an der Testplatine.<\/p>\n
\nMehr Sicherheit durch eigenes Flash-Ziel<\/h2>\n
all<\/code> automatisch zu flashen, sondern daf\u00fcr ein eigenes Ziel wie flash<\/code> zu verwenden.<\/p>\n
Mit einem eigenen Ziel bleibt das sauber getrennt.<\/p>\n
\nBeispiel f\u00fcr einen typischen Tagesablauf<\/h2>\n
\n
make<\/code> zum schnellen Test des Builds<\/li>\nmake flash<\/code>, wenn das Binary auf die Hardware soll<\/li>\n
\nNoch besser: verschiedene Firmware-Varianten<\/h2>\n
\n
flash-release: build\/release.bin\r\n\t$(ONEROM) program build\/release.bin\r\n\r\nflash-debug: build\/debug.bin\r\n\t$(ONEROM) program build\/debug.bin<\/pre>\n
\nOne ROM statt EPROM-Brenner<\/h2>\n
\n
\n
make flash<\/code><\/li>\n
\nTypische Stolperfallen<\/h2>\n
Kein Ger\u00e4t gefunden<\/h3>\n
scan<\/code> kein One ROM findet, liegt das oft an:<\/p>\n\n
Wenn mehrere Ger\u00e4te am Tisch liegen, sollte man sauber mit Seriennummern oder getrennten Setups arbeiten.<\/p>\n
\nFalsches Binary geflasht<\/h3>\n
\n
\nReset vergessen<\/h3>\n
\n
\nWo dieser Workflow besonders stark ist<\/h2>\n
\n
\nPraxistipp: erst klein anfangen<\/h2>\n
\n
\nFazit<\/h2>\n
\n
\nAusblick<\/h2>\n
\n