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ß
:
Verschoben durch Moderator
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.
Mod: dicht machen, würde ich sagen ...
:
Wiederhergestellt durch Moderator
Irgendwie kam nicht mal die Fragestellung durch. Daniel hat sich in Sunny gemorpht. Aber so wird das eh nichts. Genaue Antworten bedingen genaue Fragen.
Jobst M. schrieb: > Mod: dicht machen, würde ich sagen ... Ja, weg damit. Vom TE wurde sowieso nichts mehr gesehen.
Thread beobachten
Seitenaufteilung abschalten