Hallo,
irgendwie stecke ich in einem Dilemma (oder vielleicht nicht?):
Ich möchte mit AVR Studio sowohl in Assembler als auch evtl. später in
"C" programmieren (kann beide Sprachen bereits, würde aber ASM für
zeitkritische Sachen bevorzugen). Sehe aber folgende Probleme nach
kleineren Tests:
- Assembler von AVR Studio
+ Debuginformationen werden richtig generiert
- Kann nicht mehrere Objektfiles verlinken (ist das wirklich so?)
- Module können später nicht mit WinAVR C-Programmen gelinkt werden
- Assembler von WinAVR (gas)
+ Modulares Programmieren durch Linker möglich
+ Module können später mit C Objektfiles gelinkt werden
- Debuginformationen werden nicht korrekt erzuegt :-(
Habe ich etwas übersehen, oder trifft das so zu?
Die Methode mehrere Assemblerprogramme mit "include" quasi
"zusammenzulinken" ist ja eigentlich etwas ungewöhnlich, scheint aber
das Standardverfahren unter AVR Studio zu sein, oder?
Leider sind ja auch die Direktiven für die Assemblersteuerung vom AVR
Assembler nicht mit denen vom gas kompatibel, so dass man nicht mal
schnell die Sourcen dann mit einem anderen Assembler übersetzen kann.
Was wäre dnen die "best practice" für mein Anliegen?
Ciao...
Markus
> - Assembler von WinAVR (gas)>> + Modulares Programmieren durch Linker möglich
Ja.
> + Module können später mit C Objektfiles gelinkt werden
Ja.
> - Debuginformationen werden nicht korrekt erzuegt :-(
Das ist mir neu. Sag' das mal nicht meinem Assembler.
Die ASFLAGS-Zeilen in meinen Makefiles lauten:
zum Debuggen mit avarice/avr-gdb/emacs. Für AVR-Studio solltest Du
stabs+ durch dwarf-2 ersetzen, dann sollte das auch gehen. Es ist aber
schon länger her, dass ich das mal gemacht habe. Aufgefallen ist mir
dabei debug-mäßig, es ging alles auch in Asm (jedenfalls nichts außer
dass es mit Studio eine extreme Mausschubsorgie ist, und das ist
Geschmackssache).
Für kleine Aufgaben mag der AVR-Assembler ja ganz nett sein, aber da er
zu nichts Weiterführendem kompatibel ist (und das ideale uC-Programm
beseht für mich aus einer Kombination von Assembler mit Hochsprache,
wobei jeder der zwei Anteile mal bis auf 0 gehen kann), bleibt
AVR-Assembler für so was eine Sackgasse.
Hazeh Zimmerer schrieb:
> Für AVR-Studio solltest Du stabs+ durch dwarf-2 ersetzen, dann sollte das> auch gehen.
Tja, und genau das geht eben nicht.
Oder zumindest "ging nicht". Das Problem ist bekannt und es gibt
Patches. Kann also sein, dass es mittlerweile geht.
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=77693
Stefan Ernst schrieb:
> Hazeh Zimmerer schrieb:>> Für AVR-Studio solltest Du stabs+ durch dwarf-2 ersetzen, dann sollte das>> auch gehen.>> Tja, und genau das geht eben nicht.
Ja, genau DAS ist das Problem, auf das ich bei der Nutzung gestossen
bin. Seit März 2009 gab es ja auch kein neues Release von WinAVR.
> Oder zumindest "ging nicht". Das Problem ist bekannt und es gibt> Patches. Kann also sein, dass es mittlerweile geht.>> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=77693
Ein sehr interessanter Thread, vielen Dank! Werde mal den Patch
ausprobieren der dort gepostet wurde (allerdings nur den Binary, habe
keine Lust auf Selbstcompilieren unter Windows...).
Ciao...
Markus
...habe den Patch von AVR Freaks mal ausprobiert, scheint soweit zu
funktionieren.
Bei gemischtem C/Assembler-Code funktioniert es nun auch richtig!
Super, Danke für den Link! Hoffentlich gibt es bald ein neues Release
von WinAVR wo das schon korrigiert ist.
EINE Frage habe ich aber noch: Wenn ich meine ASM-Files für (g)as
schreibe, kann ich ja sowohl den C Präprozessor als auch noch die
Direktiven vom as selbst verwenden.
Z.B. um eine Headerdatei einzubinden könnte man schreiben
.include "bla.h" (as-style)
#include "bla.h" (c-style)
Kann man das nach Belieben mischen, oder ist das unsauber? Wenn ich ein
und dieselbe Headerdatei für C als auch ASM verwenden will (spezielle
Bereiche mit #ifdef _ASSEMBLER_ getrennt), macht das doch Sinn den
c-style zu verwenden, oder?
CIao...
Markus
Markus M. schrieb:
> Z.B. um eine Headerdatei einzubinden könnte man schreiben>> .include "bla.h" (as-style)> #include "bla.h" (c-style)
Der Punkt dabei ist folgender:
Wenn du .include benutzt, bekommt der Präprozessor den Inhalt von bla.h
nicht zu sehen (wird ja erst vom Assembler inkludiert, also nachdem der
Präprozessor schon fertig ist). Das hat natürlich Einfluss darauf, was
in bla.h stehen darf.
> Wenn ich ein> und dieselbe Headerdatei für C als auch ASM verwenden will (spezielle> Bereiche mit #ifdef ASSEMBLER getrennt), macht das doch Sinn den> c-style zu verwenden, oder?
Das z.B. kann man dann gar nicht mit .include inkludieren ohne dass dir
der Assembler einiges husten wird. ;-)
...und gibt es da ein "best practice" ob man lieber den C-Präproz. oder
die Assembler Direktive nimmt?
Was ist z.B. bei den Makros besser: #define bla(x) oder mit .macro
arbeiten?
Ciao...
Markus
Der C-Präprozessor ist standardisiert. Wenn Dein Programm jemand anders
liest, kannst Du davon ausgehen, dass er/sie eher Standard-C als die
Makrosprache eines einzelnen Tools kennt, die Einlernzeit ist also
kürzer. Der C-Präprozessor ist portabler, denn der C-Präprozessor lässt
sich auch notfalls mal auch als Zwischenschritt vor ein fremdes Tool
schnallen. Du siehst, wo meine Präferenzen liegen ...
Eine eigene Frage?
Dieser Thread ist über 16 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
