AVR: Modulares programmieren und WinAVR/gcc Debuginformationen

[Markus M. (adrock)]

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

[Hc Z. (mizch)]

> - 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:

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

[Stefan E. (sternst)]

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

[Markus M. (adrock)]

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

[Markus M. (adrock)]

...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

[Stefan E. (sternst)]

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. ;-)

[Markus M. (adrock)]

...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

[Hc Z. (mizch)]

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 ...