Forum: Mikrocontroller und Digitale Elektronik AVR Studio Simulator


von Matthias Kölling (Gast)


Lesenswert?

Hallo,

also die Suche habe ich bereits benutzt aber nichts passendes gefunden.
Gibt es eine Möglichkeit mit dem AVR Simulator ein C-Programm auf 
Assembler-Ebene zu simulieren?
Ich habe folgendes Problem: Ich übergebe einer Funktion eine Variable. 
In der Funktion wird in Abhängigkeit von dieser Variablen ein Array 
bearbeitet. Wenn ich der Funktion eine globale Variable übergebe - 
klingt kurios, ist aber eine Möglichkeit für den Funktionsaufruf- Dann 
wird immer noch die richtige Aktion im Array ausgeführt und gleichzeitig 
an einer anderen Stelle im Array ein Wert überschrieben. Selbst das 
Zwischenspeichern der globalen Variable auf eine lokale Variable vor dem 
Funktionsaufruf bringt nichts. Ich denke der Compiler optimiert die 
Zuweisung weg. Auf C-Ebene kann ich den Fehler nicht einkreisen. Der 
Simulator zeigt mir die Beeinflussung des Arrays bereits wenn der PC auf 
der ersten ausführbaren C-Zeile in der Fuktion steht.

Gruß Matthias

von Thomas B. (detritus)


Lesenswert?

View->Disassembler im Debug-Modus.

von Falk B. (falk)


Lesenswert?

Quelltext wäre hilfreich. Siehe Netiquette.

von Matthias Kölling (Gast)


Lesenswert?

@Falk
Ich habe auf die Angabe des Codes verzichtet, da man das Problem wohl 
nicht auf die angegebene Funktion beschränken kann. Es handelt sich 
dabei nicht um ein simples Problem ala - Wie bekomme ich eine LED zum 
Blinken?

@Thomas
Bingo! Da hätte ich doch nie hingeschaut. Ich habe immer unter Debug 
gesucht. Danke!

Also Dank Thomas Hinweis gibt es Neuigkeiten. Das Problem hat nichts 
damit zu tun, ob die übergebene Variable global oder lokal ist. Vielmehr 
tritt das Problem auf, wenn in der Funktion eine zusätzliche lokale 
Variable deklariert wird. Ich hatte beim Probieren dummerweise immer 
beides verändert. Dann zeigen Y- und Z-Register irgendwo auf mein Array.

Das sieht mir nach Stack Overflow aus. Wie wird die Stackgröße 
eingestellt? Hat zufällig ein Defaultwert bisher immer gepaßt?
Ich dachte nämlich, dass der Linker den Stack automatisch einstellt, was 
wohl nicht der Fall ist.

Gruß Matthias

von Falk B. (falk)


Lesenswert?

@  Matthias Kölling (Gast)

>Bingo! Da hätte ich doch nie hingeschaut. Ich habe immer unter Debug
>gesucht. Danke!

Die Geschichte auf ASM Ebene zu debuggen ist unsinnig. Geh mal davon aus 
dass der Compiler OK ist. Schalte die Optimierung ab und debugge auf 
C-Ebene. Dann wirst du deinen Fehler schnell finden.

MFG
Falk

von Matthias Kölling (Gast)


Lesenswert?

@Falk
Auf Assembler-Ebene zu debuggen ist nicht unsinnig. Es geht dabei nicht 
darum, herauszufinden, ob der Compiler etwas falsch macht. Es geht eher 
darum herauszufinden, wo etwas schiefgeht. Da sich hinter einer C-Zeile 
mehrere Assembler-Zeilen verbergen ist es schon interessant, bei welcher 
Assembler-Instruction der Fehler auftritt. Auf C-Ebene hätte ich mein 
Problem nie lösen können. Durch die Assembler-Darstellung kam ich drauf, 
dass der Stack zu weit läuft.

Die Sache ist wohl die, dass der Stack im Startup-Code einfach an das 
Ende des SRAM gesetzt wird. Im Programmablauf wird er ja dann nach unten 
aufgebaut. Das stellt sich für mich so dar, dass ich als Entwickler 
einfach einen genügenden Abstand zu meinen SRAM-Variablen einhalten muß.

Nachdem ich jetzt eine Menge an Variablen auskommentiert habe, die nur 
für Debug-Zwecke gebraucht wurden, funktioniert es. Da wird auf jeden 
Fall auf der neuen Hardware der 1281 ranmüssen.

Wieder etwas gelernt! Vielen Dank nochmals!

Gruß Matthias

von Peter (Gast)


Lesenswert?

Welchen Compiler verwendest Du?

Anyway,d ass der Compiler einen Fehler mit dem Stack macht, ist äusserst 
unwahrscheinlich, der Fehler liegt zu 99.999% woanders. (Es sei denn Du 
hast zuwenig RAM und der Stack (Top-Down) läuft in den Heap (Bottom-Up)

Ich habe schon öfters vom Compiler erzeugten ASM-Code debuggt und war 
ebenfalls schon fest davon überzeugt, dass der Compiler einen Mist 
macht! Aber der Compiler hatte bisher immer recht, es war einfach sehr 
verwirrend das ganze richtig zu verstehen....

von Matthias Kölling (Gast)


Lesenswert?

@Peter
Wie ich Falk schon zu sagen versuchte - ich bin nicht davon ausgegangen, 
dass der Compiler einen Fehler macht. Der Assembler-Code ist für mich 
eine Hilfe zu verstehen, was da passiert.
Und noch mal: Der Compiler macht keinen Fehler mit dem Stack. Ich mußte 
nur erst mal verstehen, wie er organisiert ist. Die Funktionsweise habe 
ich mir jetzt mühsam aus Datenblatt und erzeugtem Map-File 
zusammengereimt. Wenn ich erkenne, das der Stack in meinen 
Variablenbereich reinläuft, ist es doch nicht verkehrt ein paar 
Variablen wegzuschmeißen, die nicht unbedingt gebraucht werden.
Ich bin ursprünglich auch davon ausgegangen ,wenn AVR Studio noch 50 
freie Bytes meldet, dass da der Stack schon eingerechnet ist. Dem ist 
aber nicht so.
Die Angabe bezieht sich nur auf den statischen SRAM Verbrauch. Achtung 
Falle!!!

Gruß Matthias

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.