AVR GCC: "restliches RAM" für Array abschätzen

[kxr (Gast)]

uint8_t ramlog[RESTRAMSIZE - 64];

Das Program wächst und wächst ...
Wie kann man die Größe des restliche RAM RESTRAMSIZE (minus etwas 
Stack)im AVR GCC Preprocessor auto bestimmen/abschätzen?

Grüße

[g457 (Gast)]

> [..] im AVR GCC Preprocessor [..]
                  ^^^^^^^^^^^^
Dieses Problem ist in dieser allgemeinen Version zu diesem Zeitpunkt 
mindestens NP-schwer -> lass es bleiben und such Dir eine andere Lösung 
zum hier nicht näher beschriebenen eigentlichen Problem.

HTH

[Karl H. (kbuchegg)]

kxr schrieb:
> uint8_t ramlog[RESTRAMSIZE - 64];
>
> Das Program wächst und wächst ...
> Wie kann man die Größe des restliche RAM RESTRAMSIZE (minus etwas
> Stack)im AVR GCC Preprocessor auto bestimmen/abschätzen?

gar nicht.

Wieviel SRAM durch Variablen belegt ist, weißt du erst, nachdem der 
Linker das komplette Programm zusammengebaut hat.

[Stefan P. (form)]

Man könnte das makefile umstricken (oder ein Script drumherum bauen), so 
das er 2x kompiliert.
Das erste mal um zu sehen wieviel RAM frei bleibt.
Das zweite mal um auch den gesamten RAM (mit Reserve) zu benutzen.

[kxr (Gast)]

Stefan P. schrieb:
> Man könnte das makefile umstricken (oder ein Script drumherum bauen), so
> das er 2x kompiliert.

die iterations-methode mittels Skript funktioniert.

Was mich noch stört, ist daß der GCC/Linker dieses (uninitialisierte) 
Array an eine recht zufällige Position ins RAM legt (COMMON abschnitt). 
und überhaupt nicht in übereinstimmung mit der Definitionsreihenfolge in 
C.

(die DATA und explizit null-initialsierten BSS Variablen scheinen 
ordentlicher gereiht zu sein)

Ich hätte das Array am liebsten aber am Ende als letztes vor dem Stack - 
aus gewissen Sicherheits/Debug-Gründen und überhaupt...   wie kann man 
das erzwingen?

und/alternativ: wie kann man im C-Code einen Pointer auf das Ende der 
Daten (__bss_end im map file) erhalten?

[Stefan E. (sternst)]

kxr schrieb:
> Was mich noch stört, ist daß der GCC/Linker dieses (uninitialisierte)
> Array an eine recht zufällige Position ins RAM legt (COMMON abschnitt).
> und überhaupt nicht in übereinstimmung mit der Definitionsreihenfolge in
> C.
>
> (die DATA und explizit null-initialsierten BSS Variablen scheinen
> ordentlicher gereiht zu sein)

Hä? Das Array ist offensichtlich nicht uninitialisiert, sondern liegt in 
bss, sonst könnte es nicht "mittendrin" liegen. Übrigens liegen in bss 
auch die implizit null-initialisierten Variablen.

kxr schrieb:
> Ich hätte das Array am liebsten aber am Ende als letztes vor dem Stack

Dann mache daraus tatsächlich eine uninitialisierte globale Variable, 
denn die noinit Section liegt hinter data und bss.

kxr schrieb:
> und/alternativ: wie kann man im C-Code einen Pointer auf das Ende der
> Daten (__bss_end im map file) erhalten?

Da (wie gesagt) nach bss noch noinit kommt, nimmst du als Anfang des 
ungenutzten Bereichs besser __heap_start.

extern uint8_t __heap_start;

uint8_t *ptr = &__heap_start;

PS: Was ist überhaupt der Hintergrund?

[Karl H. (kbuchegg)]

Da frag ich mich schön langsam, ob nicht ein einzelner malloc am 
Programmstart, der sich den restlich verbliebenen Speicher (ohne Array) 
krallt, nicht die einfachere Variante wäre.

[kxr (Gast)]

Karl Heinz Buchegger schrieb:
> Da frag ich mich schön langsam, ob nicht ein einzelner malloc am
> Programmstart, der sich den restlich verbliebenen Speicher (ohne Array)
> krallt, nicht die einfachere Variante wäre.

da sonst kein heap verwendet wird, ists ähnlich. nur kosten die malloc 
Funktionen an die 500Byte und vom RAM auch noch was..
für freien Speicher ermitteln seh ich jetzt auch keine dynamische 
Funktion.

verwende ich also besser direkt __heap_start  ... RAMEND - stacksize

[holger (Gast)]

>verwende ich also besser direkt __heap_start  ... RAMEND - stacksize

stacksize ist aber unbekannt und hängt vom Programm ab.

Damit ist dein Konzept fürn Arsch.