Variable ändert Wert bei Portzugriff

[ATV (Gast)]

Hallo Leute,

bei mir tritt ein seltsamer Fehler auf, wenn ich eine Variable im 
Watch-Window des AVR-Studios 4 beobachte, ändert diese plötzlich ihren 
Wert wenn ich auf PORTB zugreife (PIN setze etc.). Die Optimerung  ist 
komplett ausgeschaltet, eingesetzt wird ein ATmega64, Speicher ist zu 
100% voll.
AVR toolchain wird in der Version 3.4.0.1146 eingesetzt. Hat jemand 
schonmal ein ähnliches Verhalten gehabt?

[Dieter M. (Gast)]

Also Speicher >= 100% ergibt immer komische Effekte.
Hat es einen teiferen Sinn, dass Du die Optimierung ausschaltest?

[Klaus (Gast)]

ATV schrieb:
> Speicher ist zu
> 100% voll.

Ein AVR hat ja auch nur einen Speicher...


WELCHER?!?

[ATV (Gast)]

Dieter M. schrieb:
> Hat es einen teiferen Sinn, dass Du die Optimierung ausschaltest?

Ja damit ich nach dem Fehler suchen kann, sonst sehe ich ja die 
Variableninhalte im Debugger nicht (Not in Scope, etc...). Hatte keine 
Lust mich durch den erzeugten Assemblercode zu hangeln.

[ATV (Gast)]

Klaus schrieb:
> Ein AVR hat ja auch nur einen Speicher...

Der Flashspeicher! Habe es jetzt auf 98,1% drücken können, indem ich 
unbenutzte Funktionen rausgelöscht habe.

Im Prinzip ist ja ein Portregister auch nur ein Bereich im Speicher, das 
der gcc den überschreibt obwohl er es nicht tun sollte?

[Klaus (Gast)]

ATV schrieb:
> Der Flashspeicher! Habe es jetzt auf 98,1% drücken können, indem ich
> unbenutzte Funktionen rausgelöscht habe.

Ok :) Also voller Flashspeicher ist in der Regel unbedenklich. Probleme 
gibts, wenn der SRAM zu voll wird. Wie voll ist der? Die Anzeige ist der 
statische Verbrauch, dazu musst du noch abschätzen, wie viele lokale 
Variablen gleichzeitig existieren können und das draufrechnen. Wenn sich 
das in die Nähe von 100%  (>80% ist da schon ein Alarmsignal) kann es 
die merkwürdigsten Fehler geben.

[ATV (Gast)]

Also SRAM ist zu 61% voll. Habe mir jetzt doch mal den erzeugten 
Assemblercode angesehen, das Problem liegt wohl doch nicht an der 
Zuweisung des Portpins sondern tritt viel früher auf wenn die Addresse 
mittels PUSH auf den Stack geschrieben wird. Wird wohl auf einen 
Stacküberlauf herauslaufen. Habt ihr diesbezüglich irgendwelche tipps 
wie man den Fehler eingrenzen kann. *.s Files habe ich schonmal 
überflogen, dabei ist stage usage teilweise doch recht hoch (max. ca. 
34)

[ATV (Gast)]

Keiner irgendwelche tipps bezüglich Stacküberläufe?

[Robert N. (metrux)]

Du setzt nicht zufällig Bits im PINB Register?
Das toggelt den entsprechenden Pin in PORTB.

[ATV (Gast)]

Robert N. schrieb:
> Du setzt nicht zufällig Bits im PINB Register?
> Das toggelt den entsprechenden Pin in PORTB.

Nein!

[Thomas E. (thomase)]

ATV schrieb:
> Keiner irgendwelche tipps bezüglich Stacküberläufe?
Schalte die Optimierung wieder ein.
char statt int.
Schränk dich bei Arrays ein.


ATV schrieb:
> (Not in Scope, etc...).
Das lässt sich ganz einfach lösen:

void function(void)
{
  char a;
}
Das kannst du nicht debuggen.

volatile char a;
void function(void)
{
//  char a;
}
Und jetzt geht's.

Ist zwar auch eine Krücke, aber immer noch besser als die Optimierung 
abschalten. Gerade wenn der Speicher am Anschlag ist.

mfg.

[ATV (Gast)]

Der Speicher scheint wohl ingesamt an seinen maximum zu sein. Wenn ich 
eine Funktion reinnehme die viel Konstanten Text beeinhaltet der auf dem 
LCD angezeigt werde soll, kommt es zu den Stackfehler.
Der Bereich des Heap und der Bereich des Stack scheinen zu kollidieren, 
wie auch hier illustriert
http://www.mikrocontroller.net/attachment/30494/Avr-ram.png.
Gibt es da irgendeine abhilfe?

[Frank M. (ukw) (Moderator)]

Du brauchst:

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Programmspeicher_.28Flash.29

um Deine Strings aus dem RAM zu verbannen.

[mh (Gast)]

wenn dein programm nicht hochgeheim ist, dann lad es doch hier hoch... 
es finden sich sicherlich verbesserungsvorschläge.

[Ralf G. (ralg)]

ATV schrieb:
> Ja damit ich nach dem Fehler suchen kann, sonst sehe ich ja die
> Variableninhalte im Debugger nicht (Not in Scope, etc...).

Das hat richtig Sinn, dass die Variable nicht sichtbar ist! Denn als 
lokale Variable ist sie nur in der Funktion gültig. In einer anderen 
Funktion kann der Speicherplatz anders genutzt werden.

Variablen, die lokal in Registern gehalten werden, können manchmal auch 
nicht angezeigt werden. Dann hilft das:

Thomas Eckmann schrieb:
> volatile char a;
> void function(void)
> {
> //  char a;
> }
... allerdings würde ich die Variable trotzdem in der Funktion belassen.

[Thomas E. (thomase)]

ATV schrieb:
> Wenn ich
> eine Funktion reinnehme die viel Konstanten Text beeinhaltet der auf dem
> LCD angezeigt werde soll, kommt es zu den Stackfehler.
Das hat im RAM ja nun überhaupt nichts verloren.

Ralf G. schrieb:
> ... allerdings würde ich die Variable trotzdem in der Funktion belassen.
Nach dem Debuggen kommt sie ja wieder rein.

Aber vielleicht sollte man sich auch mal von der alten Gurke Atmega64 
verabschieden und einen 2561 nehmen.

mfg.