Hallo!
Ich möchte für ein Projekt Assembler-Code per C-Programm in ein Hex-File
umwandeln. Grund: Auf dem Zielsystem, auf dem meine Software später
installiert werden soll, sollen keine Atmel-Produkte installiert werden.
Gibt es da vielleicht bereits eine Bibliothek die ich verwenden kann?
Gruß
D.h. du willst mal schnell einen Assembler schreiben? Gut, es ist
einfacher einen Compiler für eine Hochsprache. Trotzdem ist das ne Menge
Arbeit. Und warum? Der GNU Assembler aus der (avr-)gcc Toolchain ist
nicht von Atmel. Also wo ist das Problem?
Und warum muss bei dir auf dem Zielsystem assembliert werden?
gruß cyblord
Daniel schrieb:> Ich möchte für ein Projekt Assembler-Code per C-Programm in ein Hex-File> umwandeln. Grund: Auf dem Zielsystem, auf dem meine Software später> installiert werden soll, sollen keine Atmel-Produkte installiert werden.> Gibt es da vielleicht bereits eine Bibliothek die ich verwenden kann?
Mein Gott, denk doch bloß mal nach!
Was macht wohl normalerweise aus deinem C-Programm Assemblercode, daraus
wiederum ein Objektfile und daraus wiederum ein Hexfile?
Wenn du das herausbekommen hast, könntest du möglicherweise daraus sogar
eine Vermutung ableiten, welches Programmpaket eventuell die benötigten
Bibliotheken enthalten könnte...
Daniel schrieb:> Grund: Auf dem Zielsystem, auf dem meine Software später> installiert werden soll, sollen keine Atmel-Produkte installiert werden.
Was hast du auf dem Zielsystem vor, dass du den AVR Assembler neu
erfinden möchtest?
Normalerweise würde man da einen Bootloader draufspielen - vorausgesetzt
es handelt sich um einen µC - und dem zum Firmware-Update den neuen
Hex-File zuschieben.
Daniel schrieb:> Grund: Auf dem Zielsystem, auf dem meine Software später> installiert werden soll, sollen keine Atmel-Produkte installiert werden.
Was soll das heissen?
A keine Atmel-Software - brauchst du ja auch nicht, nur dein Programm
(binär).
B keine Atmel Hardware - was willst du denn dann übersetzen?
Gruss Reinhard
Nur zu!
So schwer ist das nicht.
Mein Assembler-compiler für den 8051 besteht aus 930 Zeilen, 29kB -
incl. aller Kommentare und Leerzeilen. In php ;-)
1: Datei einlesen und Kommentare und Leerzeilen rausschmeissen.
2: Zeilenweise die Befehle anschauen und damit die Befehlslänge nebst
Adresse im Array ablegen.
3: Werte der Definitionen, Sprungmarken, SFR (...) in einem Array
ablegen
4: Befehl in Zahlenwert wandeln und Parameter, Definitionen,
Sprungmarken einfügen.
5: Hexfile erzeugen und schreiben.
... hier und da noch ein paar Assemblerdirektiven, die Du benötigst,
berücksichtigen.
Gruß
Jobst
Jö, das ist vielleicht nicht schwer für jemanden der sich damit
auskennt, aber so einfach und schnell geht's auch nicht.Da muss man sich
schon sehr gut damit auskennen.
Sunny schrieb:> Da muss man sich schon sehr gut damit auskennen.
Die Hex-Codes zu den Assemblerbefehlen entsprechend der Adressierungsart
kann man aus dem Datenblatt ablesen und der Rest ist Verwaltung von
Sprungadressen und Speicherplätzen.
Natürlich sollte man wissen was man tut - "but it's no rocket science"
1.) Ist die Syntax der Assemblermnemonics schon hersteller- und manchmal
sogar noch produktspezifisch und manchmal alles andere, als intuitiv und
logisch klingend. (Siehe Atmel: Equ, statt Zero..., etc...). Die kann
nicht einfach 1:1 portiert werden.
2.) Ist der daraus dann übersetzte Maschinen(Hex-)Code erst recht
chip-spezifisch und auf keine andere Hertsteller- und Produktserie
einfach übertragbar.
Daraus folgt:
Das Maximale was du hersteller- und produktreihenübergreifend machen
kannst, ist eine Translationssoftware zu schreiben, die den
Assemblerdialekt vom einen zum andereren Hersteller/Produkt überträgt.
Daran wirst du aber wegen der fehlenden, verbindlichen ASM-Nomenklatura
verzweifeln... Die Befelssätze sind rudimentär und spezifisch in Bezug
auf erlaubten Anwendungsfall und Parametrierung, auch wenn es sich um
scheinbar(!) identische Befehlsmnemonics handelt...
Aber das wäre dann eh eine Scriptsache und keine Sache eines
vermeintlichen Universal-Hex-Maschinencode! Letzteren gibt es nicht
systemübergreifend.
Daniel schrieb:> sollen keine Atmel-Produkte installiert werden.
Daraus schliesse ich, dass du einen Assembler für die AVR von Atmel
brauchst?
Wie weiter oben schon gesagt: Nur zu, so schwer ist das nicht.
Das ist hauptsächlich eine Übung, ob du mit Stringverarbeitung in C klar
kommst.
'hauptsächlich' - nicht ausschliesslich. Aber der Rest ist nicht mehr so
wild. Um ein Studium, wie sich beim besagten Prozessor die Opcodes
zusammensetzen, wirst du allerdings nicht rumkommen. Daraus leiten sich
dann Hilfsfunktionen für die Aufbereitung der diversen Adressierungsmodi
ab. Noch eine Labelverwaltung dazu und du hast die Hauptkomponenten fürs
erste fertig.
Da der AVGCC einen open source Assembler mitbringt und der per command
line gefüttert wird, kann er doch den einfach mit seiner Software
ausliefern. Wenn er nur die exe mit reinpackt, muss er wahrscheinlich
nichtmal seine Software an die AVRGCC Lizenz anpassen. Somit muss kein
AVR Produkt installiert sein.
Karl Heinz Buchegger schrieb:> Um ein Studium, wie sich beim besagten Prozessor die Opcodes> zusammensetzen, wirst du allerdings nicht rumkommen.
Das ist genau das Problem.Woher kann er dieses Wissen bekommen?
Da gibt's nur eine Möglichkeit, es von anderem Assembler zu kopieren.
Sunny schrieb:> Das ist genau das Problem.Woher kann er dieses Wissen bekommen?> Da gibt's nur eine Möglichkeit, es von anderem Assembler zu kopieren.
Unsinn, das ist alles dokumentiert im AVR Instruction Set, gibt's als
Pdf.
Daniel schrieb:> Ich möchte für ein Projekt Assembler-Code per C-Programm in ein Hex-File> umwandeln. Grund: Auf dem Zielsystem, auf dem meine Software später> installiert werden soll, sollen keine Atmel-Produkte installiert werden.
Ich verstehe das so, dass er ein vorhandenes Atmel-Assemblerprogramm in
ein Hexfile für ein völlig anderes Zielsystem (Nicht-Atmel) umwandeln
will. Also eine Art "Cross"-Assembler, der mit AVR-Mnemonics für
Nicht-Atmel-Prozessoren übersetzt.(Ich weiss, was ein Cross-Assembler
ist, deshalb in Anführungszeichen.) Ist keine sinnvolle Aufgabe, wenn
man C kann.
Aber auch das ist reine Spekulation. Wäre schon gut, wenn der
Thread-Starter mehr dazu sagt.
Wenn'es so einfach ist dann weiss jemand wie man Pic18 MOVFF Befehl
implementieren kann?
Main:
; *** main code goes here ***
nop
nop
movff H'003', LATB
nop
;***********************************************************************
*******
;End of program
Hier ist die Hexfile Zeile mit dem Befehl
:0E003000100011000000000003C08AFF000055
Also der Befehl movff 03C08AFF wird in zwei Befehle zerlegt.
Zuerst C0 und variable und dann FF + Bestimmungsort.
So ich brauch eine gescheite Routine die das macht.
Sunny schrieb:> So ich brauch eine gescheite Routine die das macht.
Die wird Dir hier sicherlich keiner schreiben. Schon gar nicht bei
dieser Tonart.
Ich verstehe allerdings auch nicht, an welcher Stelle Du dabei
scheiterst.
Mach ausserdem einen eigenen Thread auf. Aber mit mehr Infos.
Gruß
Jobst
Ich scheitere dran, das es zwei Befehle lang ist sind und alle anderen
Befehle nur ein Befehl lang, wie z.B NOP = 0000.
Und der Assembler in den ich das einfügen will ist so ausgelegt, dass er
mit solchen langen Befehlen nicht umgehen kann.
Und deswegen war meine Idee diesen Befehl in zwei Teile zu zerlegen und
nacheinander zu schreiben.Aber bischer hab ich noch kein Erfolg damit.
In meinen Anfängen kamen Leute zu mir mit handgeschriebenem
Assembler-Listing und rechts daneben notiertem Hex-Code. Diesen haben
sie auf meinem Computer eingetippt und davon direkt den EPROM gebrannt.
Das war kurz nach Erfindung des Rades.
Sunny schrieb:> Und der Assembler in den ich das einfügen will ist so ausgelegt, dass er> mit solchen langen Befehlen nicht umgehen kann.
Kann er Macros?
Sunny schrieb im Beitrag #3060620:
> Ich weiss dass hier nur Angeber sind,
Vielen Dank. Du trittst gerade auf die ein, die Dir wertvolle Tips geben
wollen. Da finde ich eine andere Tonart etwas angebrachter!
> bei denen ist alles so einfach,> aber wenn man sie wirklich um Hilfe fragt, dann weiss niemand was.
Wer sagt, daß es einfach war, das alles zu lernen? Damals™ gab es kein
Internet, niemanden in der Umgebung, den man mal eben schnell fragen
konnte. Da war man froh um jedes Datenblatt (Kopie!) die einem vom
Hersteller oder Vertrieb bestenfalls kostenlos zugeschickt wurde!
Heutzutage ist es so einfach an all diese Informationen zu kommen.
Trotzdem verdummen die Leute immer mehr. Oder vielleicht gerade deshalb?
Stell vernünftige Fragen, dann bekommst Du auch brauchbare Antworten!
Und so Sätze wie: "So, ich brauch das jetzt" solltest Du Dir verkneifen!
> Dan heisst es, schreib es selber oder Die wird Dir hier sicherlich> keiner schreiben.
Natürlich musst Du es selber schreiben. Du musst Dir auch selbst den
Arsch abwischen. Hoffe ich. Ich muß mir meine Software auch selber
schreiben. Und was habe ich gemacht? Ich habe es mir beigebracht!
Sunny schrieb im Beitrag #3060624:
> Ausserdem möchte Ich nicht, dass mir jemand so einfach was schreibt.Ich> brauche eine fertige und arbeitende Lösung von jemandem der sich damit> schon beschäftigt hat.
Also brauchst Du einen anderen Assembler ...
Im übrigen finde ich es immernoch total uncool von Dir, hier diesen
Thread zu karpern ...
Ross schrieb:> Assembler-Listing und rechts daneben notiertem Hex-Code. Diesen haben> sie auf meinem Computer eingetippt und davon direkt den EPROM gebrannt.> Das war kurz nach Erfindung des Rades.
Hmmm. Habe ich noch mit DIP-Schaltern ins EPROM gebrannt. War noch kurz
vor der Erfindung des Rades ;-)
Gruß
Jobst
Daniel schrieb:> Hallo!>> Ich möchte für ein Projekt Assembler-Code per C-Programm in ein Hex-File> umwandeln. Grund: Auf dem Zielsystem, auf dem meine Software später> installiert werden soll, sollen keine Atmel-Produkte installiert werden.> Gibt es da vielleicht bereits eine Bibliothek die ich verwenden kann?
So eine dämliche Fragestellung hab ich selten gehört.
Du willst Assembler mit C.????
Du willst alles, außer ATMEL. ????
Weißt du, wie viele verschiedene Prozessorsysteme es gibt?
Am Ende sind es alles Hex-Files in verschiedener Ausführung, die in den
Proizessor geschrieben werden.
Sunny schrieb:> Karl Heinz Buchegger schrieb:>> Um ein Studium, wie sich beim besagten Prozessor die Opcodes>> zusammensetzen, wirst du allerdings nicht rumkommen.>> Das ist genau das Problem.Woher kann er dieses Wissen bekommen?
Indem er sich auf seinen Allerwertesten setzt und die Instruction Sets
studiert?
Was ist denn da das Problem?
In jeder Instruction Set Beschreibung ist auch immer drinnen, welche
Bits im Oopcode konstant sind und welche Bits sich aus Registernummern,
Konstanten oder Addressen ergeben und welche Nebenbedingungen es gibt.
Dann muss man halt mal 2 Minuten nachdenken, wie man das in eine
vernünftige Programmstruktur giesst. Beim ersten Befehl dauert es noch 5
Minuten, dafür hat man andere in kürzerer Zeit ausgehorcht. Aber alles
in allem ist das nicht weiter schwer. Schliesslich muss ja die Umkehrung
dieses Prozesses auch in der CPU in Silizium durchgeführt werden.
Irgendwie kam nicht mal die Fragestellung durch. Daniel hat sich in
Sunny gemorpht. Aber so wird das eh nichts. Genaue Antworten bedingen
genaue Fragen.