Forum: Compiler & IDEs wie mach ich's?


von Leif U. (boing)


Angehängte Dateien:

Lesenswert?

Hallo,

ich möchte an dieser Stelle nochmal bezug nehmen auf diesen post:
http://www.mikrocontroller.net/forum/read-2-408840.html#409148

Um das lesen zu ersparen, in aller kürze:
Es ging darum daß sich einige Variablen reproduzierbar überschrieben
haben, wenn man ihnen werte zugewiesen hat. Am ende der diskussion lag
die vermutung nahe, daß es warscheinlich am simulator (AVRStudio)
liegt.
Ich habe letztendlich 2 Wege gefunden das Problem zu umgehen, die aber
jeweils ein anderes Problem auftreten lassen. Womit sich mir die Wahl
zwischen 3 Übeln stellt:

(A)
Compilieren und Linken vermittels AVRStudio
Problem:
Schrittweises debuggen von Assembler Code ist nicht mehr möglich.
(B)
Compilieren und Linken vermittels selbst erstelltem Batchfile:
Problem:
Zeigerübergabe von C nach Assembler funktioniert nicht mehr
zuverlässig, da sich variablen überschreiben.
Im Beispielprogramm, sieht man dies gut an der Stelle wo die swap
variablen im Assemblerteil zurück in die Register geladen werden.
(C)
Compilieren und Linken vermittels Makefile (via "mfile" erstellt)
Problem:
Structs funktionieren nicht mehr in der Watchlist.

In allen 3 Fällen wird zum debuggen das AVR-Studio benutzt, tests auf
der Hardware sind derzeit leider nicht möglich.
Ich hoffe es lässt sich eine Lösung finden, in der keines der Probleme
auftritt...
Sourcen, Batchfile, Makefile finden sich im Anhang. Wietere Dateien
Stelle ich gern dazu.

Cheers,
Leif

von Peter (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Leif

Also ich hab's im AVR-Studio (4.12 SP3) mit WinAVR (20060421)
ausprobiert! Hab einige kleine Details angepasst und kann's nun prima
compilieren und auch debuggen, sogar auf Assembler Level!

Einziger Vermutstropfen: Strukts lassen sich offenbar beim AvrStudio
nicht im Watch-Window anzeigen. Oder weiss hier irgend jemand eine
Lösung?

MfG  peter

p.s. Anbei meine gezippte Version...

von Leif U. (boing)


Lesenswert?

Danke soweit.
Allerdings sehe ich keinen wiklichen unterschied zu meiner Version.
Ich bin mir auch nciht sicher ob wir unter "Schrittweises debuggen von
Assembler" das gleicher verstehen. Ich stelle mir das so vor, daß ich
mit F11 in die Assemblerfunktion springe und den dortigen Code
zeileweise durchgehen kann. Das gelang mit deiner Version nicht.

von Stefan K. (_sk_)


Lesenswert?

Das ist geil!

Zuerst eine Überschrift, die NULL Aussagekraft besitzt.

Dann ein Link auf einen weiteren Thread, den man sich durchlesen soll,
um zu verstehen, welches Problem Du genau hast.

Dann ein zip-File, das man erst abspeichern und entpacken soll, um dann
(vielleicht!) zu erkennen, wo es bei Dir hakt.

Vielleicht kannst Du ja mal etwas besser zusammenfassen, wo Dein
Problem liegt?

Ich benutze zum Compilieren und Debuggen die Lösung c (Makefile) und
habe noch nie Probleme mit Structs im Watchfenster gehabt. Im
Gegenteil, das einfache Betrachten von Strcuts und auch Daten, auf die
Pointer zeigen, finde ich sehr komfortabel in der
gcc/AVR-Studio-Kombination. Vielleicht kannst Du ja auch  hier etwas
detailierter mitteilen, was

"Structs funktionieren nicht mehr in der Watchlist"

genau bedeutet.

Viele Grüße, Stefan

von Leif U. (boing)


Lesenswert?

Gut, die Überschrift ist nicht besonders aussagekräftig...
Allerdings ich meine gelesen zu haben, daß man sein makefile sowie
sourcen, die auf ein minimu reduziert sind, anhängen soll.
Der Post muss ja auch nicht gelesen werden.

< was
< "Structs funktionieren nicht mehr in der Watchlist"
< genau bedeutet.
Fügt man das Struct der Watch List hinzu, so erscheint es dort, lässt
sich allerdings nicht aufklappen. Die im Struct enthaltenen Werte
lassen sich nicht beobachten. Ich meine auch die dort angegebene
Adresse des Structs wird nicht korrekt angezeigt, da bin ich mir jetzt
allerdings nicht ganz sicher.

< Vielleicht kannst Du ja mal etwas besser zusammenfassen, wo Dein
< Problem liegt?
Gern:

Ich habe 3 möglichkeiten ein und denselben Code zu Compilieren und zu
Linken. Das Hauptgrogramm ist in C geschrieben und ruft eine in
Assembler geschrieben Funktion auf, an die mit Hilfe globaler volatile
Variablen Werte übergeben werden.

Jede der drei (im folgenden beschriebenen) Variationen des Übersetztens
und Linkesn verursacht 1 anderes Problem beim Debuggen mit dem Studio.
(Nummerierung wie im obigen Post)

(A)
Compiliere ich mit dem Studio funktionieren Structs und Zeigerübergabe,
aber Assembler Code lässt sich nicht Schrittweise debuggen.
(Diese Problem wurde auch schonmal hier diskutiert und führte mich zu
Variation (B))
(B)
avr-gcc -c -gstabs -mmcu=atmega128 -o dasproblem.o dasproblem.c
avr-gcc -Wa,--gstabs -c -mmcu=atmega128 -o mul.o mul.S
avr-gcc -g -Xlinker -Map=dasproblem.map -o dasproblem.elf mul.o
dasproblem.o
avr-objcopy -O coff-ext-avr --debugging dasproblem.elf dasproblem.cof
Diese Variante bewirkt, daß ich AssemblerCode Schrittweise debuggen und
Structs in der Watchlis betrachten kann, allerdings klappt die
Zeigerübergabe an den Assemblerteil nicht mehr.
(Dieses Problem wurde hier schonmal Diskutiert, in dem Eingangs
erwähnten Post)
(C)
Das mit "mfile" erstelle Makefile führt zu einem .cof das sich
ebenfalls mit dem Studio ausführen läßt. Assembler lässt sich
Schrittweise debuggen, Variablemübergabe klappt auch, aber Structs
können in der Watchlist nicht mehr aufgeklappt werden.

Cheers, Leif

von Leif U. (boing)


Angehängte Dateien:

Lesenswert?

/** Hier der Code der aus dasproblem.c **/

#include <avr/io.h>
volatile uint8_t dummy;
volatile uint8_t swap1;
volatile uint8_t swap2;
volatile uint8_t swap3;
volatile uint8_t swap4;
volatile uint8_t swap5;
volatile uint8_t swap6;
volatile uint8_t startadresshA1;
volatile uint8_t  startadresshA0;
volatile uint8_t  startadresslA0;
volatile uint8_t  startadresslA1;
volatile uint8_t  startadresshB0;
volatile uint8_t  startadresslB0;
volatile uint8_t  startadresshB1;
volatile uint8_t  startadresslB1;
volatile uint8_t  startadresshC0;
volatile uint8_t  startadresslC0;
volatile uint8_t  startadresshC1;
volatile uint8_t  startadresslC1;
volatile uint8_t  startadresshC2;
volatile uint8_t  startadresslC2;
volatile uint8_t  startadresshC3;
volatile uint8_t  startadresslC3;

extern void swapit();
extern void multi();
int main (void){

typedef struct
{
   uint8_t a[20];   //multiplier
   uint8_t b[20];   //multiplier
   uint8_t ab[40];  // ab=a*b
}mupliva;

mupliva mupli;

int i;

for(i =0; i<=19; i++){
  mupli.a[i]=0x41;
}
for(i =0; i<=19; i++){
  mupli.b[i]=0x42;
}
for(i =0; i<=19; i++){
  mupli.ab[i]=0x43;
}

swap1 = 0xAF;
swap2 = 0xFA;
swap3 = 0xCF;
swap4 = 0xCF;
swap5 = 0xDA;
swap6 = 0xDB;
startadresshC3= 0xDE;
multi();
return(0);
}



/**   Hier der Code aus mul.S    **/
.stabs  "",100,0,0,multi
.stabs  "mul.S",100,0,0,multi
;;#include "avr/io.h"
.extern dummy
.extern swap1
.extern swap2
.extern swap3
.extern swap4
.extern swap5
.extern swap6
.extern startadresshA0
.extern startadresslA0

.extern startadresshA1

.extern startadresslA1
.extern startadresshB0
.extern startadresslB0
.extern startadresshB1
.extern startadresslB1
.extern startadresshC0
.extern startadresslC0
.extern startadresshC1
.extern startadresslC1
.extern startadresshC2
.extern startadresslC2
.extern startadresshC3
.extern startadresslC3

.global multi
.func multi
multi:
;;;;;;;;Initialise;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
cli ; disable interrupts
push 18
push 19
push 20
push 21
push 22
push 23
push 24
in 24,0x3F ;SREG
push 24
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
lds 18, swap1
lds 19, swap2
lds 20, swap3
lds 21, swap4
lds 22, swap5
lds 23, startadresshC3
;;;;;;;;;;;;;;;;;cleanup;;;;;;;;;;;;;;;;;;;;;;;;
pop 24
out 0x3F, 24 ;SREG
pop 24
pop 23
pop 22
pop 21
pop 20
pop 19
pop 18
sei ; Enable interrupts
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
ret
.endfunc



// Makefile im Anhang

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

> ... aber Structs
> können in der Watchlist nicht mehr aufgeklappt werden.

Das ist wahrscheinlich ein Problem des COFF-Parsers im AVR Studio.
Prinzipiell konnte COFF diese Information weiterreichen, aber ich
glaube mich an eine Aussage zu erinnern, dass dieses Feature nie
implementiert worden ist im AVR Studio.

Ich fürchte, die einzige Methode, alles unter einen Hut zu bekommen,
ist derzeit die Benutzung des GDB bzw. eines Frontends dazu.  Da du
aber keine reale Hardware hast sondern nur eine Simulation, rennst
du damit an eine andere Schwachstelle: simulavr ist ziemlich
spartanisch.

von Stefan K. (_sk_)


Lesenswert?

Hallo Leif,

wie gesagt, ich benutze die Methode c (nicht ganz, ich habe das
Makefile selber gebaut, bzw. das Beispiel-Makefile aus der
WINAVR-Installation modifiziert).

Damit funktioniert das Debuggen von Structs prima. Allerdings benutze
ich nicht das .cof für AVRStudio, sondern das .elf.

Wenn ich mich recht erinnere, klappte das Debuggen per .elf-File früher
nur mit einer Beta-Version von Atmel-Norwegen. Aber mittlerweile liegt
bei Atmel eine neue AVRStudio-Version vor
(16. Sept. 2006), mit der es keinerlei Probleme gibt.

Ich benutze allerdings nicht den Simulator, sondern debugge direkt auf
der Zielhardware per jtag (kann ich übrigens nur empfehlen ...). Ob der
Simulator hier eingeschränkter ist, kann ich nicht sagen, würde mich
aber wundern.

Variante a) habe ich noch nie benutzt, ka wie AVRStudio sein make genau
aufbaut.

Welche Versionen von WINAVR und AVRStudio  benutzt Du?
Kannst Du mal versuchen, per .elf File zu debuggen?

Viel Erfolg, Stefan

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

> Kannst Du mal versuchen, per .elf File zu debuggen?

Damit kann er seine Assembler-Dateien nicht debuggen, das ist ja
Teil seines Problems.  Ist ein Bug in den GNU binutils, in denen
die Unterstützung für DWARF-2 nicht vollständig implementiert ist.

von Leif U. (boing)


Lesenswert?

> > ... aber Structs
> > können in der Watchlist nicht mehr aufgeklappt werden.
>
> Das ist wahrscheinlich ein Problem des COFF-Parsers im AVR Studio.
> Prinzipiell konnte COFF diese Information weiterreichen, aber ich
> glaube mich an eine Aussage zu erinnern, dass dieses Feature nie
> implementiert worden ist im AVR Studio.

Variante (b) und (c) produzoeren beide ein .cof.
Bei (b) klappts ja mit den structs.

Ich habe version (b) und (c) gemischt um herauszufinden welche
konkreten parameter welcher GNU tools welche problem beheben/erzeugen.
Es scheint alles am umwandeln von .elf in .cof zu hängen.

Die spezielle angabe von adressraäumen aus (c) scheitn das prblem der
mislingenden zeigerübergabe von (b) an den assembler zu beheben:
--change-section-address .data-0x800000 --change-section-address
.bss-0x800000 --change-section-address .noinit-0x800000
--change-section-address .eeprom-0x810000

Das das struct nicht mehr funktioniert liegt vermutlich daran, daß (c)
im gegensatz zu (b) ein coff und kein extcoff erzeugt.
Ersetzt man in version (c) den parameter
coff-avr durch coff-ext-avr funktioniert alles ohne einschränkung.

(Alternativ kann man das per mfile erzeuge makefile auch mit der option
extcoff starten - das sicherlich der schnellste und einfachste Weg,
falls noch jemand das gleiche problem hat)

Vielen Dank allen die mitgeholfen haben!

Cheers,
Leif

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Jetzt, wo du's sagst, erinnere ich mich: die erste COFF-Version,
die AVR Studio verstanden hat, konnte keine structs.  Daher haben
sie dann irgendwann die erweiterte Spezifikation veröffentlicht,
das ist das "extcoff".

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
Noch kein Account? Hier anmelden.