Hallo Zusammen, ich möchte Daten, welche ich in Libre-Office Calc (Excel) generiert habe, auf ein EPROM brennen. Mein Kollege hat ein Prog-Express von Batronix, welches div. Fileformate unterstütze. Ausser die Datei-Extensions habe ich allerdings nichts gefunden, wie die Daten auf dem File sein müssen, z.B. "Straight Hex". Kompliziertere Formate habe ich auf Google gefunden. Kann mir für einfach zu generierende Fileformate jemand helfen?
Am einfachsten in ein S-RECORD File konvertieren.
1 | $ srec_cat text.hex -binary -o - -motorola |
2 | S0220000687474703A2F2F737265636F72642E736F75726365666F7267652E6E65742F1D |
3 | S108000048616C6C6F07 |
4 | S5030001FB |
5 | $ srec_cat text.hex -binary -o - -intel |
6 | :020000040000FA |
7 | :0500000048616C6C6F0B |
8 | :00000001FF |
wobei man auch noch die spezielle Ausgabe konfigurieren kann.
Die universellen Standardformate sind Intel-Hex oder Motorola-S19. Beide zeichnen sich dadurch aus, daß nicht der komplette Inhalt des EPROMs gespeichert werden muss, sondern nur die genutzten Stellen, und daß sie zur Fehlersicherung auch noch eine Prüfsumme für jeden Block enthalten. Ein Gegenentwurf ist eine Binärdatei, die einfach für jede Speicherzelle des EPROMs genau ein Byte enthält, und damit immer exakt so groß ist wie der Adressraum des EPROMS. Für ein 2764 sind das 8192 Bytes. So eine Binärdatei aber kann mit einem normalen Texteditor nicht betrachtet und erst recht nicht bearbeitet werden. Intel-Hex und Motorola-S19 hingegen sind Textdateien, in der jede Zeile einen sogenannten "Record" enthält - letztlich ein Datenhäppchen. Neben den Daten des Häppchens wird auch eine Adresse angegeben, die als Offset zum Beginn des EPROMs betrachtet werden kann (aber nicht zwingend muss; eine gute Eprom-Programmiersoftware sollte hier Korrekturmöglichkeiten vorsehen). Zum Häppchen gehört noch eine Nutzlängenangabe und eben eine Prüfsumme. Wenn zum Beispiel bei einem EPROM aus irgendeinem Grund nur das erste und das letzte Byte programmiert werden soll, besteht die Binärdatei unverändert aus allen Bytes, die das EPROM enthält (beim 2764 also 8192 Bytes). Bei Intel-Hex oder Motorola-S19 aber besteht die Datei aus nur zwei Records - einem mit der Adresse 0 und einem Nutzbyte, und einem mit der Adress 8191 und einem Nutzbyte. Dazu noch eine Prüfsumme ... und fertig ist der Salat. Hier mal als Beispiel mit dem Werten AA und BB Bei S19 sieht das so aus: S1 01 0000 AA cs S1 01 1FFF BB cs Und bei Intel-Hex sieht das so aus: :01 0000 00 AA cs :01 1FFF 00 BB cs (der Übersichtlichkeit halber habe ich zwischen die Feldelemente Leerzeichen eingefügt und auf die Berechnung der Prüfsumme 'cs' verzichtet) Direkt lassen sich solche Dateien mit einem Tabellenkalkulationsprogramm eher nicht erzeugen, aber Du kannst ein "Metaformat" nutzen: CSV, in der ersten Spalte steht die Adresse, und in den folgenden Spalten die Datenbytes, die ab dieser Adresse gespeichert werden sollen. Nach z.B. 32 Bytes beginnst Du eine neue Zeile, wieder mit einer Adresse (diesmal um 32 gegenüber der vorhergehenden Zeile erhöht) und gefolgt von den Nutzbytes. Ein Programm zu schreiben, was daraus wiederum Intel-Hex oder Motorola-S19 erzeugt, ist dann eine leichte Übung. https://de.wikipedia.org/wiki/S-Record https://de.wikipedia.org/wiki/Intel_HEX
Beitrag #8056014 wurde vom Autor gelöscht.
Intel-Hex und Motorola-S19 habe ich bei Wicki gesehen, schienen mir abeer zu kompliziert zum Erzeugen. Ich würde sowieso nicht mit einem Texteditor arbeiten, sondern ein kleines Programm schreiben. Wenn ich einfach die Hex-Zahlen oder ev. Binäre Bytes auf das File schreiben könnte, ohne noch Adressen und Checksummen zu generieren, dachte ich, dass das einfacher währe. Wobei ich mit dem Programm natürlich das auch noch generieren könnte. Habe schon einen Fileconverter geschrieben, welcher das CBM-Format in das "Paper Tape Format" von KIM-1 umwandelt, das hat auch checksummen und so.
von Harald K. schrieb: >Für ein 2764 sind das 8192 Bytes. So eine Binärdatei aber kann mit einem >normalen Texteditor nicht betrachtet und erst recht nicht bearbeitet >werden. In Linux geht das so. Betrachten: xxd -u -g1 Datei.bin In Text wandeln um mit einen Texteditor betrachten und bearbeiten zu können: xxd -u -g1 Datei.bin > Datei_bin.txt In echte Binärdatei zurückwandeln: xxd -r Datei_bin.txt > Datei.bin
Sind denn die Daten, die Du da ins EPROM schreiben willst, kontinuierlich, d.h. von Anfang an und ohne Lücken?
Es ist eine relativ kleine Datei von ca. 200 Bytes mit nur kleinen Lücken. Es handelt sich um eine Look Up Table für die Hardware. Das EPROM wird dann mit einem Hardware-Zähler an der Adresse angesteuert und steuert Magnete in einem zeitlichen Ablauf.
Rolf E. schrieb: > Wenn ich einfach die Hex-Zahlen oder ev. Binäre Bytes auf das File > schreiben könnte, ohne noch Adressen und Checksummen zu generieren, > dachte ich, dass das einfacher währe. "Checksummen" beim Intel-Hex Format hört sich wilder an, als es ist. Auf deutsch ist das einfach eine Prüfsumme. Die Bytes eines Records (=Zeile) aufzuaddieren und zu negieren, ist wirklich kein Hexenwerk und die Adresse ergibt sich bis auf einen Offset aus dem Zähler deiner Ausgabeschleife.
:
Bearbeitet durch User
von Rolf E. schrieb: >Es ist eine relativ kleine Datei von ca. 200 Bytes mit nur kleinen >Lücken. In eine Binärdatei gibt es aber keine Lücken. Etwas muß da immer stehen, entweder 00 oder vielleicht FF.
Rolf E. schrieb: > Es ist eine relativ kleine Datei von ca. 200 Bytes mit nur kleinen > Lücken. Wenn es Lücken gibt, musst Du Dich drum kümmern, sie zu füllen -- oder Du verwendest ein Dateiformat, das Lücken zulässt. Der Aufwand, Intel-Hex oder Motorola-S19 zu erzeugen, ist sehr überschaubar.
Der Prog-Express nimmt auch Binärdateien. Also Tabelle als *.csv speichern und in *.bin wandeln. Am einfachsten online. https://www.filesmonkey.com/csv-bin
Günter L. schrieb: > von Rolf E. schrieb: >>Es ist eine relativ kleine Datei von ca. 200 Bytes mit nur kleinen >>Lücken. > > In eine Binärdatei gibt es aber keine Lücken. > Etwas muß da immer stehen, entweder 00 oder vielleicht FF. Bei EPROM FF das beschleunigt das programmieren.
Rolf E. schrieb: > Intel-Hex und Motorola-S19 habe ich bei Wicki gesehen, schienen mir > abeer zu kompliziert zum Erzeugen Vielleicht hättest du nicht nur Wickie fragen sollen, sondern auch die starken Männer? > Ich würde sowieso nicht mit einem > Texteditor arbeiten, sondern ein kleines Programm schreiben. Wozu? Du hast doch Rolf E. schrieb: > Daten, welche ich in Libre-Office Calc (Excel) generiert habe Also liegen die ja schon in irgendeinem Format vor. Welches? Ich rate mal: Binärdateien. Dann laß sie so. Zu jedem EPROM-Programmiergerät gehört eine Programmiersoftware. Die kann Binärdateien lesen. Alternativ kannst du die Binärdateien auch umwandeln. Es gibt gefühlt 1000 Programme, die Binär nach Intel HEX oder Motorola S19 umwandeln können. Und zurück. Du mußt dieses Rad nicht neu erfinden.
Mein Problem ist, dass das einzige halbwegs vernünftige Format, welches Excel zustande bringt ist .csv (siehe angehängte Datei). Pro linie ist nur ein Byte als Hex-ASCII mit Space dazwischen und am Schluss der Zeile. Diese muss ich herausnehmen und vermutlich auch wirklich als Binär-Byte auf das File schreiben. Vermutlich macht das auch kein Konverter-Programm.
- Datei speichern - Datei in Notepad++ öffnen - Strg H: Leerzeichen/nix/Alles ersetzen - Inhalt kopieren - https://tomeko.net/online_tools/hex_to_file.php?lang=en aufrufen - Einfügen - convert anklicken - myfile.dat bekommen Fertig. Eine Binärdatei die nur die Tabelle nackt als direktes File enthält. Alle Angaben wie immer ohne Gewehr. Die Umwandelseite hab ich nach 30 Sekunden Googlen gefunden, Stichworte "convert a file with one hex byte per line into binary" Kontrolle per HxD sagt mir das es so aussieht wie es soll.
:
Bearbeitet durch User
Rolf E. schrieb: > Vermutlich macht das auch kein Konverter-Programm. jetzt schon. Braucht "bash", "xxd" und "objcopy" aus den binutils. Notfalls WSL nehmen, falls Windows. Oder auf Powershell umschreiben.
Jens M. schrieb: > - Inhalt kopieren > - https://tomeko.net/online_tools/hex_to_file.php?lang=en aufrufen > - Einfügen Hat sehr geholfen. Vorherige Bearbeitung erübrigt sich eigentlich, da der Converter alle anderen Zeichen sowieso ignoriert. Danke Euch Allen für die Hilfe
Bei fraglichen Fileformaten hätte ich mir zuerst einen Muster-EPROM eingelesen und mit meinem erzeugten Daten verglichen. z.B. Hex-Editor
Lu schrieb: > Muster-EPROM > eingelesen und mit meinem erzeugten Daten verglichen Richtig, wollte ich auch machen, jedoch steht der Programmer bei meinem Kollegen, welcher im verlängerten Wochenende ist. 2. Ansatz war, mit dem Assembler (ACME) ein File zu generieren, von welchem steht, dass es für Programmer geeignet sei. Da hatte jedoch die Option in der Anleitung nicht gefunden. Ich verwende dort eigentlich immer das Format für CBM, da dort die Anfangsadresse im File ist. danke jedoch für den Ansatz. Rolf E.
Ist zwar etwas off topic, ich machte das immer so, Programm in Adressen und Daten aufsplitten. Hängt von der Organistation des zu brennenden EPROMs ab. "Meine" alten 2716-er waren 8-bittig und hatten 24V an Vpp. Auf einer Adresse steht die Höhe von Vpp. Die Daten auf der Adresse mussten dann auch gelöscht werden. Also vorher in das UV-Gerät, um sicherzugehen, dass es "leer" ist. ciao gustav
:
Bearbeitet durch User
Rolf E. schrieb: > ich möchte Daten, welche ich in Libre-Office Calc (Excel) generiert > habe, auf ein EPROM brennen. Im Anhang zum diesem Thread: Beitrag "Mülltonnen-Blinker" ist ein LibreOffice Calc Sheet enthalten, das in Verbindung mit dem mitgelieferten Shellscript (conv.sh) etwas sehr ähnliches macht. Das Sheet enthält die Primärdaten und erzeugt aus diesen eine Liste von Bytes. Das Script wandelt das Sheet in CSV um (mit LibreOffice), extrahiert die Bytes aus Spalte 12 (mit awk) und erzeugt wahlweise eine Binärdatei, SREC oder Intel-Hex (mit xxd und avr-objcopy). Letzteres läßt mich vermuten, daß Ernst B. im Beitrag "Re: Fileformat für EPROM-Programmer" dieses Vorgehen entweder geklaut oder neu erfunden hat. Ich habe den Tonnenblinker übrigens auch am laufen und verwende das .bin File um es anschließend in das I²C EEPROM zu brennen (mit eeprog). Das Binärformat ist dafür vollkommen ausreichend, da die Daten ab Adresse 0 geschrieben werden und egal ist, welchen Wert die anderen Bytes haben. Beim OP wird das genauso aussehen.
:
Bearbeitet durch User
Karl B. schrieb: > ich machte das immer so, Programm in Adressen und Daten aufsplitten. > Hängt von der Organistation des zu brennenden EPROMs ab. "Meine" alten > 2716-er waren 8-bittig und hatten 24V an Vpp. Das ist ein ... überaus ungünstiges Format. Offenbar kannst Du nicht mehr als 256 Byte damit verarbeiten (ein 2716 aber fasst 2048 Bytes). Und die Idee, ein Datenbyte in Deinem "Format" für die Höhe der Programmierspannung zu verballern, verdient sicherlich Kreativitätspunkte, ist sonst aber, äh, hust.
Angehängte Dateien:
Mein Libre-Office Calc (Excel) berechnet die Hex-Bytes und transferiert diese mittels Formel auf das Sheet "Output" aus welchem dann das .csv File generiert wird. Dieses wird dann mit Jens M. schrieb: > - https://tomeko.net/online_tools/hex_to_file.php?lang=en aufrufen in "Myfile.dat" konvertiert, welches vorsichtshalber in "MyFile.hex" umbenannt wird und dann einwandfrei eingelesen wird.
Das war das, was ich noch aus der hintersten Ecke des Gedächtnisses herauskramte: "...Ausnahmen, bei denen über Programmier-Pins (wie A₉) Informationen abgerufen wurden, bezogen sich meist auf die sogenannte Electronic Signature. Dabei legte der EPROM-Brenner eine leicht erhöhte Spannung (meist 12 V) an Pin A₉ an. Dadurch gab das Bauteil dann zwei Bytes aus: eines für den Hersteller-Code und eines für die Bauteil-Kennung (Device ID). Die genaue Programmierspannung musste der Programmierer jedoch anhand dieser ID aus seiner internen Datenbank beziehen..." Jetzt weiß ich auch wieder, dass diese Info auf Adresse A9 lag. Und ja, nur ein Beispiel aus der Datensicherung hier. BTW: Für die Neugierigen: Es ist ein Beispiel für einen Codewandler. Daten, die an den Adressbus angelegt werden, geben gespeicherte Daten am Datenbus aus. (Man kann das ja auch noch bis FFFF erweitern.) Für die Handvoll Daten extra einen Eprombrenner kaufen... Und TO hat ja auch gesagt: Rolf E. schrieb: > Es ist eine relativ kleine Datei von ca. 200 Bytes mit nur kleinen > Lücken. Fehlt noch Angabe, welches Eprom er bevorzugt. Oder habe ich etwas überlesen. ciao gustav
Rolf E. schrieb: > in "Myfile.dat" konvertiert, welches vorsichtshalber in "MyFile.hex" > umbenannt wird und dann einwandfrei eingelesen wird. Üblicherweise ist ein *.hex-File eine Textdatei, die einen Hexdump enthält, und nicht eine Binärdatei. Passender wäre es also, Deine Datei *.bin zu nennen.
Beitrag #8058114 wurde vom Autor gelöscht.
Der TO hat sein Problem gelöst. Jeder soll auch die Werkzeuge nehmen, die er gewohnt ist. Aber aus Programmierer-Sicht sieht die Lösung aus, als würde man einen Nagel mit der Zange einschlagen. Ein sicherlich passenderes Werkzeug wäre ein Assembler, bei dem man die Werte symbolisch definiert und dann in Datenbytes übersetzen lässt. Die Datei im Anhang lässt sich mit dem "nasm" in eine Binärdatei oder mit der Option "-f ith" in eine Intel-Hex-Datei übersetzen.
Hallo, Die Assembler-Ansicht finde ich persönlich jedoch nicht so übersichtlich. In meiner allerletzten Version des LibreOffice Calc habe ich auch noch einen Fehler-Check integriert, da "Lo" und "Hi" für dieselben Magnete nicht gleichzeitig 1 sein dürfen. Nach all den Disskussiunen habe ich den Eindruck, dass auch meine ASCII-Binär-Darstelung (0/1) mit schon vorhandenem Konverter direkt in eine richtige Binärdatei umgewandelt werden könnte, was all die Formeln in der Tabelle überflüssig gemacht hätten. Danke nochmals Allen für die Hilfe!
Rolf E. schrieb: > Nach all den Disskussiunen habe ich > den Eindruck, dass auch meine ASCII-Binär-Darstelung (0/1) mit schon > vorhandenem Konverter direkt in eine richtige Binärdatei umgewandelt > werden könnte Was stellst Du Dir unter einer Binärdatei vor?
Harald K. schrieb: > Ein Gegenentwurf ist eine Binärdatei, die einfach für jede > Speicherzelle des EPROMs genau ein Byte enthält, und damit immer exakt > so groß ist wie der Adressraum des EPROMS Das meine ich. Für meinen Teil ist alles gelöst und funktioniert.
Rolf E. schrieb: > Das meine ich. Dann ist völlig unklar, wozu Deine "ASCII-Binär-Darstelung (0/1)" gut sein soll.
Die ganze Rechnerei mit den Bits lässt sich vereinfachen durch
1 | =BININHEX(TEXTKETTE(B3:I3);2) |
Die ASCII 0/1 Datei ist meine Handeingabe, damit ich sehe, was ich ansteure. Es ist ein Hardware-Projekt, in welchem das EPROM zweckentfremdet eingesetzt wird, um eine Sequenz zu steuern. Siehe ganz oben! Mit der ASCII-Binär-Datei sehe ich, welche Magnete angesteuert werden. daher gebe ich das auch so ein. P.S.: In meinem Assembler könnte ich mit %10010110 das eigentlich danach gut konvertieren.
Rolf E. schrieb: > Es ist ein Hardware-Projekt, in welchem das EPROM > zweckentfremdet eingesetzt wird, um eine Sequenz zu steuern. Auf die Art hab ich vor über 30 Jahren mal einen Selektivruf für CB-Funk gebaut (Prinzip Codeschloss). Leider sind weder der Aufbau noch der Schaltplan erhalten geblieben.
Angehängte Dateien:
-
Eprombrenner_0.jpg
120 KB -
Hex_Tastatur_9d.jpg
90 KB
Rolf E. schrieb: > Das meine ich. > Für meinen Teil ist alles gelöst und funktioniert. Als Programmier-"Eselsbrücke" möchte ich das bezeichnen, was ich mir dafür zurechtbastelte. Also, Eprombrenner, Hextastatur-Ausgabegerät, dann Ausdruck der Programmieranweisung. Daten aus Liste lesen und eintippen, Adressen per Mäuseklavier einstellen, Strobe drücken, abhaken im Ausdruck. Nächste Adresse. Brauche auch nur die Nullen zu brennen. Überschlage die Zeilen mit Hexangabe FF. Klappte ganz gut bei ein paar Bytes. Zur Not legt man das Eprom wieder in das UV-Löschgerät. Und von vorne. Das meinte der TO wohl mit "Binärdatei". ciao gustav
Angehängte Dateien:
-
frontpanel-PDP-11_45.jpg
57 KB
Karl B. schrieb: > Daten aus Liste lesen und eintippen, Adressen per Mäuseklavier > einstellen, Strobe drücken, abhaken im Ausdruck. Gut das damals die Speichergrößen noch in Byte gehandelt wurden. Das ist über 40 Jahre her ... Bei der PDP-11 musste man die Startadresse auch mit Schaltern einstellen, allerdings wurde die Adresse octal angegeben.
Karl B. schrieb: > Als Programmier-"Eselsbrücke" möchte ich das bezeichnen, was ich mir > dafür zurechtbastelte. Vor fünfzig oder vielleicht vierzig Jahren ... ja, da war so etwas hilfreich. Aber seitdem gibt es doch ein klein wenig mehr Komfort und Zuverlässigkeit.
Rolf E. schrieb: > dass auch meine ASCII-Binär-Darstelung (0/1) mit schon > vorhandenem Konverter direkt in eine richtige Binärdatei umgewandelt > werden könnte, was all die Formeln in der Tabelle überflüssig gemacht > hätten. Hab den Gedanken mal weiter gesponnen. Beim Druck auf den "Exportieren"-Button wird ein (mit KI-Hilfe erstelltes) Makro aufgerufen, das die Daten in die per Dateidialog ausgewählte Datei schreibt. Man muss lediglich in den OpenOffice-Einstellungen Makros erlauben.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.