Hi, Wie ist es möglich, mit avrgcc ein reines .ASM - File zu kompilieren ? mfg andy
avr-gcc -mmcu=<whatever> foo.S -o foo.o foo.S ist dabei Deine Assemblerquelldatei, die auch noch Dinge wie #include oder #define enthalten kann, da sie noch durch den C Präprozessor geschickt wird. Die gängigen herumfliegenden Makefile-Templates haben dafür auch Standardregeln. Wichtig ist, daß auf der Kommandozeile der Suffix als .S (Großbuchstabe) angegeben wird, bei einem kleinen ,s' würde kein Präprozessor aufgerufen.
C:\avrgcc\DDS>avr-gcc -mmcu=at90s2313 myprog.S -o myprog.o C:\avrgcc\WinAVR\bin\..\lib\gcc-lib\avr\3.3\..\..\..\..\avr\lib\crts2313 .o(.init 9+0x0): undefined reference to `main'
Umm, sorry, da fehlt ein -S in meiner Beschreibung. So versucht er nicht nur, Dein myprog.S zu assemblieren, sondern will es auch gleich noch linken.
Quark, nach 0 Uhr sollte man nichts mehr posten. ;-) -S macht aus einer C-Quelle ein Assemblerfile. -c compiliert, was im Falle einer Assemblerquelle dann halt assemblieren bedeutet.
Dabke für deine schnelle Hilfe ! Aber mit "avr-gcc -mmcu=at90s2313 -S myprog.S -o myprog.o" macht er zwar was, der ganze assembler-code ist sichtabr bzw läuft am bildschirm durch, jedoch erzeugt er mir kein *.hex ,... file. auch kommt keine Fehlermeldung. Mysteriös.
Um Assembler-Proggramierfehler auszuschliessen, dachte ich mal ein 100% richtiges Programm zu nehemen, und zwar von Jespers AVR-Page das miniDDS. Siehe Anhang. Ist jemand das möglich zu kompilieren ? Mir nicht. In der Datei steht auch was von einer "-x" - Option. Damit gehts allerdings auch nicht. Vg.
Naja, das mit dem -S war ja auch falsch, siehe einen Artikel drüber. Du brauchst ein -c. Außerdem ist das nur das Compilieren, das Linken wird davon noch nicht angestoßen, folglich auch keine endgültige Ausgabedatei, und erst aus der kann man ein iHex-File erzeugen lassen. Aber sag mal, es gibt so viele Makefile-Templates, WinAVR hat ja selbst auch eins dabei, warum nimmst Du nicht das als Ausgangspunkt? Deine Wißbegierde in allen Ehren, aber erstens kann man das natürlich auch alles durch das Lesen der man pages rausfinden (das sogenannte RTFM) -- keine Ausrede, WinAVR installiert diese mit :)... Irgendwie haben wir das ja schließlich auch mal gelernt... Zweitens kommt es Dir vermutlich ja gar nicht so sehr drauf an, alle Zusammenhänge zu verstehen, sondern Du willst erstmal ein Ergebnis sehen, vermute ich. Jespers File bietet gleich mehrere Fallen: . Es endet auf dem nonstandard-Suffix (aus Unix- bzw. GCC-Sicht) .asm. Dadurch wird das im File beschriebene -x assembler-with-cpp nötig. Benenne es minidds.S (großes ,S', siehe oben), und es funktioniert ohne solche Tricks. . Es benutzt teilweise obsolete Konstruktionen, die im aktuellen avr-gcc/avr-libc so nicht mehr funktionieren, da es mal für eine viel ältere avr-gcc-Version geschrieben worden ist. Die Anpassung auf die aktuelle Version ist zwar nicht schlimm, aber alles andere als eine Übung für einen Anfänger. Von daher bietet sich sowas als Anfängerprojekt überhaupt nicht an, da sollte man IMHO erstmal mit einem simplen und gut dokumentierten kleinen Stückchen C beginnen, wie es ja auch bei avr-libc (und damit bei WinAVR) aus ebendiesem Grunde beiliegt. . Es ist als standalone-Assembler-Programm geschrieben, d. h. es benutzt nicht die normalerweise auch bei Assemblerprogrammen automatisch dazugelinkte C-Infrastruktur für Interruptvektoren, automatische Initalisierung der Variablen, und dann Aufruf von main(). Damit läßt es sich nicht so ohne weiteres in ein normales Makefile-Template integrieren, ist also auch aus diesem Grunde alles andere als ein Anfängerprojekt. Ich hänge mal spaßeshalber das daraus generierte ihex-File mit an.
Herzlichen Dank dafür ! Mit deinen Bemerkungen hast du voll ins Schwarze getroffen. Ist das eigentlich "normal", dass in deinem hex-file am Anfang so viele Nullen stehen ? Vg, Andy
Das kommt vom .org 0x100. Keine elegante Methode, wenn Du mich fragst, da auf diese Weise die Verplemperung von ~ 240 Bytes ROM garantiert ist. Besser wäre es gewesen, die Tabellen ganz ans Ende zu setzen und die 256-Byte Grenze mit einem .align abzusichern.
Also dein File funktioniert nacweislich ! respekt! würdest du mir bitte verraten, wie genau du das kompiliert hast ? hast du änderungen am code vorgenommen ?
Ja, die Änderungen am Code stehen unten als context diff. Ansonsten: avr-gcc -nostdlib -o minidds.out -mmcu=at90s2313 minidds.S avr-objcopy -O ihex minidds.out minidds.hex Allerdings sind die Änderungen am Code der ,,faule Weg''. Besser wäre es, entsprechend der Doku zu verfahren und die IO-Port-Zugriffe auf _SFR_IO8() umzustellen. --- minidds.S~ Sat Jul 26 09:52:49 2003 +++ minidds.S Sat Jul 26 09:50:13 2003 @@ -63,7 +63,8 @@ ;*********************************************************************** ******* -#include <io2313.h> +#define __SFR_OFFSET 0 +#include <avr/io.h> .section .text
@Jörg: Man muss allerdings dazusagen dass ein Assemblerprogramm auf diese Weise ziemlich hässlich wird, wenn jedes IO-Register mit _SFR_IO8() umklammert ist...
Für das gibts doch Macros: Auszug auf meiner I2C assembler library: http://www.mysunrise.ch/users/pfleury/avr-software.html #define SDA 4 // SDA Port D, Pin 4 #define SDA_OUT _SFR_IO_ADDR(PORTB) // SDA Port D output Im Program wird dann nur mittels diesen Macros auf den Port zugegriffen, damit kann das Programm leicht auf andere Ports/Pins angepasst werden. cbi SDA_OUT,SDA
Es sind ja nicht nur die Ports betroffen, sondern auch alle anderen IO-Register für Timer, AD-Wandler, EEPROM usw.
Bitte 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.