Nach ersten EEPROM Versuch komisches Verhalten - kann mir das einer erklären

[Nico B. (vegetico)]

Moin...

Falls einer von euch mit dem AVR Studio 5 arbeitet könnte er mir einen 
riesen Gefallen tun und das angehängt Projekt kompilieren und kurz im 
Simulator starten.

Ich habe bei mir folgendes Problem, was ich mal wieder nicht verstehe:
Ich hatte zum ersten Mal mitm EEPROM gespielt und versucht das struct 
DeviceColorData im EEPROM zu speichern (sieht man in main.c).
Weiterhin hatte ich viel 'aufgeräumt', zumindest was ich als Hobbiest 
darunter verstehe.

Nun habe ich das Phenomen, dass, wenn ich nen ATTINY2313 brenne, nichts 
mehr passt. Die Sendestrings des UART sind auf einmal falsch (teilweise 
fehldetektiert), nichts geht mir - und ich versteh nicht an was das 
liegt.
Beim debuggen im Simulator sieht man auch, dass das Verhalten komisch 
ist (uart_init wird zig mal aufgerufen etc), die 'current Position' ist 
total komisch.
Ich check das einfach nicht.

Ich hab aus diesem Grund auch einfach das gesamte Projekt drangehängt - 
bevor es hier mit Stücklarbeit los geht.

Ich vermute, dass es entweder an den globalDefines.h oder am 
deviceColorData liegt... Aber ich versteh nicht wieso und weiß auch 
nicht wie ich das reparieren kann...

Bitte nicht falsch verstehen, ich will nicht das einer mein Spielkrams 
macht... Aber ein Hinweis worans momentan scheitert - ob n Prinzipfehler 
oder irdend was triviales... Ich bin für alles dankbar...

Sorry für die Arbeit...
Gruß
Nico

[holger (Gast)]

Ich würde sagen dein RAM ist überlastet.

[Nico B. (vegetico)]

Woran kann ich das sehen???
Der Kompiler steht zwar auf Platzoptimierung - aber ich dachte wenn die 
Werte rein passen funzt der Rest auch

AVR Memory Usage
    ----------------
    Device: attiny2313
    Program:    1810 bytes (88.4% Full)
    (.text + .data + .bootloader)
    Data:         69 bytes (53.9% Full)
    (.data + .bss + .noinit)
    EEPROM:        7 bytes (5.5% Full)

[holger (Gast)]

>Woran kann ich das sehen???

Zähl mal deine lokalen Variablen mit. Die werden
nicht mit angezeigt. Ansonsten finde ich 64 Bytes
für die UART Puffer wenn nur 128 gesamt da sind
schon recht heftig;)

[Nico B. (vegetico)]

Mhh,
ich hatte den Ringpuffer ehrlich gesagt blind übernommen. Ist jetzt auf 
32byte in Summe reduziert...
Was ich auch gesehen hab - das Verhalten ändert sich wenn ich von 
'Größenoptimierung' auf 'einfach Optimierung' springe (bzw. weg von 
Größenoptimierung, und ich bin mittlerweile bei 'einfacher 
Optimierung)...
Also bei 'weniger Optimierung' siehts vom Verhalten her besser aus...
Macht das Sinn???
Hätte eigentlich das umgekehrte Verhalten erwartet - speziell bei 
ausgehendem RAM???

[Nico B. (vegetico)]

Also,
so wirklich schlauer werd ich hier nicht... Ich hab jetzt mal n Teil 
sinnlosen Krams rausgeschmissen, den Ringbuffer verkleinert und generell 
aufgeräumt...
Momentan siehts wie folgt aus:

Device: attiny2313
    Program:    1580 bytes (77.1% Full)
    (.text + .data + .bootloader)
    Data:         37 bytes (28.9% Full)
    (.data + .bss + .noinit)
    EEPROM:        7 bytes (5.5% Full)
    (.eeprom)

Wobei das Verhalten immernoch 'komisch' ist...
Wenn ich checken will, ob der RAM voll ist - heißt das, ich addiere jede 
Variable in main() und muß halt unter 128byte bleiben??? Wenn ich 
Funktionen aufrufe muß ich die doch großteils (von den Übergabewerten) 
nicht mit addieren, oder... Das müßte doch... Ja, eigentlich aufm Stack 
landen - der wiederum im RAM ist...
Scheiße ich hab von sowas zu wenig Ahnung...

Gibts da zufällig ne einfacherer/ sichere Methode als mein raten???

Gruß
Nico

[holger (Gast)]

>Wobei das Verhalten immernoch 'komisch' ist...

'komisch' hilft irgendwie nicht weiter.

>Wenn ich checken will, ob der RAM voll ist - heißt das, ich addiere jede
>Variable in main() und muß halt unter 128byte bleiben???

Du musst auf jeden Fall unter 128 Byte bleiben.
Lokale Variablen landen auf dem Stack, was logischerweise RAM
benötigt. Mach die Variablen in main() vorläufig einfach mal static.
Dann wird dir der Speicherbedarf auch angezeigt. Alles static
zu machen ist jetzt aber auch nicht gut. Das soll dir nur zeigen
wo es lang geht.

>Wenn ich
>Funktionen aufrufe muß ich die doch großteils (von den Übergabewerten)
>nicht mit addieren,

Doch, die Return Adresse landet auf dem Stack (wenn der Compiler
nicht inlinen kann). Ob die Übergabeparameter auf dem Stack landen
hängt von Anzahl und Größe ab. Oft kann der Compiler sie in Register
packen. Wenn eine Funktion bearbeitet wird kann es nötig sein
auch Register auf den Stack zu packen.

>Gibts da zufällig ne einfacherer/ sichere Methode als mein raten???

Leider nein. Das ist wohl das übelste Thema bei der C Programmierung.
Einfacher Tip: Nimm einen uC mit mehr RAM. Dann schiebst du das Problem
ein wenig nach oben;)