Hallo, gibt es mittlerweile eine Möglichkeit GNU Assembler Programme mit AVRStudio (4.11 SP3) zu debuggen? Nach 3 Abenden googlen bin ich nicht schlauer geworden. Ich mache Folgendes: avr-as --mmcu attiny15 --gstabs -o main.o main.S avr-ld main.o -o $(TARGET) avr-objcopy -O coff-ext-avr --debugging main.elf main.cof AVRStudio erzählt mir beim Laden des .cof Files: "Coordinator The object file does not contain source code information. StudioMain InitDisassembler Error in accessing parser" Ich sehe im Prinzip nur den disassemblierten Code. '--gstabs' habe ich auch mal mit '--gdwarf2' ersetzt; gleiches Resultat. Ich arbeite unter Cygwin. Im Moment habe ich einen ATtiny15 in der Mache und das ist nur in Assembler möglich. Ich würde gern GNU verwenden, nur stellt mich das Debuggen bzw. Simulieren des Codes vor ziemlich große Schwierigkeiten. 'simulavr' im aktuellen WinAVR Package unterstützt leider keinen ATtiny15. Scheint aber eine ältere Version zu sein (0.1.2.1). Eine neuere Version von simulavr konnte ich unter Cygwin nicht bauen ('configure' erzählt mir nach einer Weile irgenwas von: "...checking bfd search- /usr/binutils/avr/2.15 + coff-avr-patch (20030831)/i686-pc-cygwin/avr in "include" and "lib"... ./configure: line 22464: test: too many arguments)" und bricht ab.) Ist es beim Tiny15 vielleicht doch besser auf den originalen AVR Assembler umzusteigen? Ich bin fast schon soweit... Neil
Gast
#238897
>Ist es beim Tiny15 vielleicht doch besser auf den originalen AVR >Assembler umzusteigen? Ich bin fast schon soweit... Vertausche die ersten beiden worte und lasse das 'vielleicht' weg ;)
simulavr muss auch nicht sehr viel von deinem Controller wissen, du kannst also eine at90s2313 oder sowas stattdessen auswählen (irgendwas mit gleicher Speichergröße). Du könntest auch -gstabs mit dem leidigen COFF-Konverter probieren. Da musste man noch irgendwie zwei .stabs-Anweisungen reinwerfen, damit der Konverter den aktuellen Dateinamen auch kennt und in die COFF-Debug-Info schreibt, aber ansonsten haben das wohl Leute benutzt. Dass -gdwarf2 nicht wirklich geht, ist noch ein Bug in der DWARF-2-Unterstützung der Toolchain. Nur zur Erinnerung, dass DWARF-2 überhaupt einigermaßen funktioniert, ist nur ein Seiteneffekt davon, dass die mainstream-Plattformen (i386, amd64) auf DWARF-2 umgestiegen sind, für den AVR hat diesen Umstieg niemand vorsätzlich getan. Leider ist aber auch mainstream der DWARF-2-Support eher parziell (schreibt man das jetzt so?), z.B. kann avr-objcopy kein DWARF-2 selbst parsen noch kann es aus stabs DWARF-2 erzeugen.
Ich nehme den Assembler von Atmel. Alles andere 'verbrennt' nur noch mehr Zeit. Also danke für Eure Hinweise. Steffen
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.