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:
1 | ASFLAGS = -Wa,-adhlns=$(<F).lst,--listing-cont-lines=100,-gstabs+ |
2 | ASFLAGS += -Wundef |
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 ...
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.