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
@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
@ 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
@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
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....
@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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.