Heap zu klein, wo kann man den vergrößern?

[µC-noob (Gast)]

Hi,

während dem Einbinden einer neuen Routine, merkte ich dass diese 
Fehlerhaft läuft.
Nach stundenlangen suchen war es mir logisch unerklärlich warum diese 
Funktion falsch läuft.
Alles auskommentiert und einfach einen Zähler (lokal als Static 
deklariert) hochlaufen lassen und es lief nix.

Wenn ich diese lokale Variable global anlege tuts.
Das ist doch nen eindeutiger Hinweis auf den Heap??

Gut ok, na dann tun wir den mal vergrößern, und nun zu meiner Frage.

Wo zum Henker, find ich diese Möglichkeit?? Im AVR Studio hab ich schon 
alles auf den Kopf gestellt (vielleicht bin ich aber auch nur blind).

Vielleicht bei den Compilereinstellungen?? Aber wo??


Danke, und Gruß

joe

[Jörg W. (dl8dtl) (Moderator)]

µC-noob wrote:

> Das ist doch nen eindeutiger Hinweis auf den Heap?

Ein eindeutiger Hinweis auf den Heap wäre die Benutzung der
Funktion malloc().

Klingt eher nach einer Kollision des Stacks mit deinen globalen
Variablen.  Und nein, den Stack kann man nicht vergrößern...
der hat nämlich standardmäßig die maximale Größe, die dein
Controller unterstützt.

[µC-noob (Gast)]

Hm,...
Also bedeutet das dass meine globalen Variablen den den Stack belegen 
und lokale sachen nicht mehr reinpassen, weil der nich schnell genug 
leer ist??

Also, nur so, wenn ich die Variable global anlege tuts ja.

Was würdet ihr mir empfehlen, wie ich hier vorgehen soll??

Gruß

[Tobi (Gast)]

Hi!

Den Heap könntest du ja auch nicht vergrössern, siehe angehängtes Bild!

Lokale Variablen werden auf dem Stack angelegt, globale nicht! So ist 
eine "dynamsische Speicherverwaltung" möglich.

Was für einen µC benutzt du denn? Und welche Variablen legst du denn an? 
Schau dir mal den Speicherverbrauch deiner globalen Variablen an!

[Peter D. (peda)]

µC-noob wrote:

> Also, nur so, wenn ich die Variable global anlege tuts ja.

Nö, es wird nur ne andere Adresse überschrieben.

Der Fehler ist immer noch da, nur hat er gerade keine für Dich 
sichtbaren Auswirkungen.


Zähl mal zusammen, wo Du überall im Code Variablenfelder definierst und 
dann vergleiche das mit dem verfügbaren SRAM.

Beachte, das int 2 Byte und long, float 4 Byte je Variable kostet.


Peter

[Jörg W. (dl8dtl) (Moderator)]

Beachte auch, dass String-Konstanten ohne weitere Vorkehrungen
erstmal im RAM landen (und im ROM auch, natürlich).  Das ist so,
damit diese zu den Standard-Funktionen wie strlen() etc. kompatibel
sind.

[Niels H. (monarch35)]

Für mich hört sich das nach einem Stack- oder Bufferoverflow an. 
Klassische Fehler von Anfängern sind nicht auflösende Rekursionen und 
das nicht-einhalten von Arraygrössen [0<x>n-1].

Möglicherweise ist auch einfach nur der Speicher voll.

[µC-noob (Gast)]

Nee, der Speicher ist nicht voll,...
Atmega 128, ca. 60% Ram belegt und 16% Flash.

Das mit den Arraygrößen kann ich verneinen, sonst wär das ja längst 
aufgetreten. Weil in meiner Problemroutine wird weder ein Array 
angewendet noch eine Funktion ausgeführt, die eins besitzt.

Niels Worte:
>nicht auflösende Rekursionen??

Was ist damit gemeint?

Danke für die ganzen Tipps, werd mal meinen Code durchgehen,...
schluck das wird ne Arbeit...

Gruß
joe

[Niels H. (monarch35)]

Eine Rekursion ist zum Beispiel eine Funktion, die sich selbst aufruft. 
Wenn dies zu häufig ohne Rücksprung passiert, läuft der Stack über...

Wenn etwas irgendwo nicht funktioniert, dann muss der Fehler nicht 
zwangsläufig an dieser Stelle sein. Häufig sind es Folgefehler aus 
vorhergegangenen Fehlern....

[Jörg W. (dl8dtl) (Moderator)]

µC-noob wrote:

> Atmega 128, ca. 60% Ram belegt und 16% Flash.

Da wäre also Platz für 1600 Bytes an Stack, der die lokalen
Variablen innerhalb von Funktionen mit einschließt.

[Peter D. (peda)]

Ein beliebter Fehler unter C ist, die Arraygröße n als Index zu nehmen.

Der Index darf aber nur von 0 ... n-1 laufen.


Peter