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

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.

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 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.

1

extern uint8_t __heap_start;

2

3

uint8_t *ptr = &__heap_start;

PS: Was ist überhaupt der Hintergrund?

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.