Hallo FReaks, ich bin kurz vorm Verzweifeln: Wie kann ich in WinAVR reinen Assembler compilieren lassen. Lasse ich im Make-File Target leer, meckert er rum, daß er die ganzen ".hex" und wie sie alle heißen, nicht erzeugen kann, trage ich eine leere Datei ein (Temp für Temp.c, da stand nur ein Kommentar drin) so meckert er rum, daß er kein main-Programm findet, trage ich ein leeres Main Programm ein main(){} meckert er zwar nicht mehr rum, aber ich kann dem .lss-File entnehmen, daß er einen leeren Programmrumpf erzeugt hat, und die Interruptvektoren alle selber eingesetzt hat: d.h er hat sich Müll ausgedacht. Wie mache ich es denn nun richtig?? - AVRStudio ist dann die einzige Alternative, wollte aber was für mehrere Plattformen (Win, MAC) haben, um nicht dauernd neue Probleme lösen zu müssen.
Matthias wrote: > Hallo FReaks, > ich bin kurz vorm Verzweifeln: > Wie kann ich in WinAVR reinen Assembler compilieren lassen. Meine Meinung: Einen C Compiler für reines Assembler zu misbrauchen grenzt an Perversion. > Wie mache ich es denn nun richtig?? - AVRStudio ist dann die einzige > Alternative, wollte aber was für mehrere Plattformen (Win, MAC) haben, > um nicht dauernd neue Probleme lösen zu müssen. Die hast du sowieso, selbst wenn alle Assembler dieser Welt die leiche Syntax sprechen würden. Unterschiedliche Plattformen prorammieren sich nun mal unterschiedlich.
Ich wollte eigentlich Hilfe und keine Polemik. Und wenn es so pervers ist, wie mache ich es denn dann???
@ Matthias (Gast) >Und wenn es so pervers ist, wie mache ich es denn dann??? Nimm einfach AVR Studio und leg ein Assembler-Projekt an. Fertig. MFG Falk
Vorab: Ich kann mir das auch nur vage zusammenreimen.
Du brauchst ein gutes Verständnis, wei as und ld von make aus aufgerufen
werden. D.h. wie man Regeln und Kommandozeilen im Makefille erstellt und
welche Optionen du für as und ld benötigst. Hilfe kann dir die Doku
geben (bei winAVR in doc/binutils/...)
as soll dir aus *.s ein *.o machen. Und ld soll dir aus *.o ein
*.elf machen. avr-objcopy erstellt dann aus dem *.elf das brennfertige
*.hex.
Die Kunst ist jetzt, den ld alles vergessen zu lassen, was mit dem
Linken von C-Programmen zusammenhängt.
Im Einzelnen heisst das, es soll kein C-Startupcode ("der Teil vor und
nach deinem Quellcode") und keine Libraries eingebunden werden.
Und das auf C-Programme angepasste Speicherlayout für die einzelnen AVRs
ist anzupassen, d.h. die Linkercontrolscripte (avr/lib/ldscripts/...)
sind durch eine eigene Version zu ersetzen
Der Haken an WinAVR ist IMHO, dass die Pfade und Optionen zum Dazulinken
von Startupcode und Standardlibrary bei der Übersetzung der Toolchain im
ld selbst oder im Steuerprogramm gcc fest dort eincodiert wurden. Es ist
vielleicht nicht so einfach das auseinanderzuklamüstern.
Ich würde hier hingehen entweder ein offeneres AVR-GCC Paket holen, bei
dem alle Quellen dabei sind (z.B. bei Linux) oder ich würde mir mal per
Option vom gcc ausgeben lassen, welche vollständigen Kommandozeilen an
as und ld übergeben werden.
Ein Mogelweg ist vielleicht auch noch offen. Du könntest die Toolchain
wie vorhanden benutzen und dein Dummy-main verwenden aber nur den
C-Startupcode gegen dein ASM-Programm austauschen.
Damit die Linkercontrolscripte passen (bzw. das eine für dein Target),
sind einige Symbole und Sektionen in deinem ASM-Code zu definieren.
Welche kann dir der Quellcode des C-Startupcodes sagen. Leider musst du
um den zu sehen auch auf eine andere Distribution als WinAVR ausweichen;
denn bei dem ist nur der Objektcode vorhanden.
Oh, danke (erst mal), vor allem Stefan, @Falk: AVRStudio ist schon installiert und läuft auch scheinbar ganz gut, natürlich nervt die etwas andere Syntax, aber das sind ja beherrschbare Probleme. Ich werde in der Folge wohl doch etwas tiefer einsteigen müssen, evtl den gas direkt ansprechen, oder so, mal sehen, was die Zeit dazu sagt. Sollte ja mit einem guten Makefile zu machen sein -:). Auf jeden Fall will ich die Assembler-syntax konform haben, so daß ich nicht erst ein Übersetzungstool schreiben muß, welches mir einen Assembler-Text in den anderen übersetzt, damit ich am PC (auf Arbeit) und am MAC (zu Hause) konform arbeiten kann. Natürlich ist mir klar, daß selbst 'gleiche' Programme auf Mac und PC anders reagieren, (Microsoft hat es ja vorgemacht) am besten halten sich da noch die Browser (Firefox und Co), aber über so etwas rege ich mich schon gar nicht mehr auf.
Klar ist es möglich, mit der GNU-Toolchain reine Assemblerprogramme zu schreiben. Karl heinz schrieb: > Einen C Compiler für reines Assembler zu misbrauchen grenzt an > Perversion. Richtig, wenn man versucht, den Assemblercode in ein .c-File zu quetschen, d.h. in Form endloser __asm-Statements ;-) Matthias fragte aber nach WinAVR. Das ist kein C-Compiler, sondern eine ganze GNU-Toolchain (die als eine Komponente einen C-Compiler enthält) und noch ein paar Dinge mehr. Damit kann man, außer in C programmieren, noch viele andere Dinge tun. > Die hast du sowieso, selbst wenn alle Assembler dieser Welt die > leiche Syntax sprechen würden. Unterschiedliche Plattformen > prorammieren sich nun mal unterschiedlich. Ich glaube, Matthias meint mit "Plattform" die Entwicklungs- und nicht die Targetplattform. Das Target ist immer ein AVR. Da ist es in der Tat angenehm, wenn man auf allen Entwicklungsplattformen (Windows und Mac bei Matthias, bei anderen auch Linux, BSD usw.) die gleichen Entwicklungstools verwenden und den gleichen AVR-Sourcecode auf unterschiedlichen Rechnern übersetzen kann. Und AVRStudio gibt es leider nur für eine einzige (aus meiner Sicht völlig unbedeutende ;-)) Plattform, nämlich Windows. > Die Kunst ist jetzt, den ld alles vergessen zu lassen, was mit dem > Linken von C-Programmen zusammenhängt. Das ist kein großes Problem. Der ld weiß zunächst ziemlich wenig über das Linken von C-Programmen, da er nicht nur kompilierten C-, sondern bspw. auch Fortran-, Ada- und eben Assemblermodule linkt. Von C weiß der ld erst durch die Kommandozeilenoptionen, die ihm vom gcc übergeben werden. Dazu gehören u.a. die Angaben darüber, welcher Startup-Code und welche Libraries gelinkt werden sollen. Wenn du also den as und den ld direkt benutzt, hast du keine Probleme mit irgendwelchen C-Reliquien. Du musst dich dann allerdings von den mit mfile automatisch generierten Makefiles trennen und deine eigenen schreiben. Alternativ kannst du Assemblerprogramme auch mit gcc assemblieren und linken indem du ihn mit .S- oder .s-Dateien fütterst. Dann werden as und ld vom gcc aufgerufen. Der eigentliche C-Compiler (der heißt cc1, gcc ist eigentlich nur ein Delegator, der andere die Arbeit machen lässt) bleibt dabei aber außen vor. Allerdings nimmt der gcc beim Linken an, dass mindestens das Hauptprogramm ein C-Modul ist und lässt den ld den Startup-Code und die Standardbibliothek mitlinken. Um das zu vermeiden muss, für den Linkvorgang gcc mit der Option -nostdlib aufgerufen werden. Kurz und klein: Du kannst versuchen, die von mfile generierten Makefiles zu verwenden, in dem du als Quelldateien nur Assemblerdateien und bei den Linkeroptionen -nostdlib angibst. Wenn dein Assemblerprogramm nur aus einer Quelldatei besteht, wird der Code defaultmäßig an die Adresse 0 geschrieben, so dass der nach dem Reset normal ausgeführt wird. Verwendest du Interrupts, muss der erste Assemblerbefehl ein Sprung ins Hauptprogramm sein. Auf diesen Sprung folgen weitere Sprungbefehle für die einzelnen Interrupts. Besteht das Programm aus mehreren Assemblermodulen, musst du mittels geeigneter Direktiven im Assemblercode dafür sorgen, dass die Sprungliste für den Reset und die Interrupts an Adresse 0 zu liegen kommen. Wie das genau geht, habe ich gerade nicht im Kopf, da ich selten Assembler programmiere, aber es geht. Noch etwas: Die meisten Leute programmieren AVR-Assembler mit den Tools von Atmel. Deren Assemblersyntax unterscheidet sich von der GNU-Syntax. Du wirst deswegen für den AVR wenig GNU-fähigen Assemblercode im Netz finden und musst ggf. Atmel-Code nach GNU umschreiben.
Danke an Yalu, so habe ich noch Hoffnung, daß ich eines Tages wirklich auf verschiedenen Rechnern quasi das gleiche tun kann. Habe, wie oben geschrieben, um des Fortschritts Willen, erst mal das AVRStudio benutzt, aber die Option steht immer noch, die GNU-Toolchain dafür zu verwenden. Ich habe nun zumindest einige Hinweise, wie und die Gewißheit, daß es geht. Matthias
Schau mal in meinen Beitrag >AES, Rijndael, WinAVR, Library<. Die aes Library ist in Assembler codiert und ein makefile ist auch dabei. Vielleicht hilft Dir das ja weiter. Gruss, Ludger
Hallo *, bei meinem letzten Eintrag war ich wohl etwas voreilig. Bei genauerem Nachdenken ist natuerlich klar, dass man nicht das object des Assemblers direkt mit OBJDUMP in ein hex-File wandeln darf, da ja die Sprungadressen noch nicht aufgeloest sind. Nun denn, diese Version sollte nun wirklich in der Lage sein lauffaehiges Programm aus einem Assembler Source File zu erzeugen. Viel Spass, Ludger
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.