Wie Stackermittlung ?

"RAMEND - Heap-Start" müsste doch die Lösung sein, oder?

Aber nur, wenn Du auch malloc() benutzt. ;-)

Ansonsten, ist schon x-mal diskutiert worden: den ganzen RAM (am
besten im .init1, also vor der Initialisierung von .data und .bss) mit
einem Muster füllen.  Später auswerten, bis wohin das Muster noch
existiert.

Aha, ich habe gerade mal ein wenig experimentiert!
Das Problem bei der Verwendung von malloc liegt darin, daß "brkval"
nicht existiert.
Wenn man kein malloc verwendet, dann ist die Sache recht einfach:

#include <avr/io.h>

extern unsigned int __bss_end;

volatile unsigned int sp;
volatile unsigned int bss = (unsigned int) &__bss_end;
volatile unsigned int sz = 0;

void foo(void);
void bar(void);

int
main(void)
{
        while(1)
        {
    sp = SP;
    sz = sp - bss;
    foo();
        }

        /* NEVEREACHED */
        return 0;
}

void
foo(void)
{
  sp = SP;
  sz = sp - bss;
  bar();
}

void
bar(void)
{
  volatile unsigned char c[32];

  sp = SP;
  sz = sp - bss;
  foo();
}

Das einfach mal im AVRStudio simulieren und ein paar watches anlegen:
sp zeigt den Stackpointer, bss das Ende der statischen Variablen (wer
hätte das gedacht? ;) und sz zeigt den verbleibenden Platz zwischen
__bss_end und SP.

Der einfachste Weg herauszufinden, wer malloc() benutzt, ist das Lesen
der Doku. ;-)  (OK, ich sehe gerade, da fehlt noch was... das werde
ich schnellstens nachholen.)

Der zweiteinfachste wäre das Lesen des Sourcecodes...

Im Ernst: derzeit wird malloc() ausschließlich von Mitgliedern der
stdio-Familie benutzt.  Insbesondere benutzt fdevopen() es, um die
struct __iob anzulegen, und die printf- und scanf-Familien benutzen es
in ihrer höchsten Ausbaustufe (floating point IO, bei scanf() dann
auch noch character class recognition), da m. E. die
Speicheranforderungen dieser Aufgaben das Maß, was man statisch
allozieren sollte, überschreiten.

Wenn Du eine eigene Mustererkennung machen willst, dann nimm ein
eigenes malloc().  Da kannst Du dann tun und lassen, was Du willst.
Auch die Bibliotheksroutinen würden in diesem Falle auf Dein malloc()
zugreifen.

Eine alternative Implementierung für fdevopen(), die ohne malloc()
auskommt, ist übrigens auch im Gespräch, bin ich aber noch nicht dazu
gekommen.  Das Problem ist dabei weniger, dass die Leute der
zusätzlich allozierte RAM stören würde, vielmehr ist oft genug der
ROM-Overhead dafür zu viel.  (Wenn man kein fdevopen() benutzt,
sondern nur die sprintf/sscanf-Varianten, und kein floating point
braucht, kommt man auch jetzt bereits komplett ohne malloc() aus.)

Nein, Link zu den Threads habe ich nicht parat, aber das Thema ist
schon paarmal angefragt worden.  Auch Patrick `OldBug' hatte da wohl
schon seinen Senf dazu gegeben, soweit ich mich erinnern kann.

Ich hab mal weiter gemacht.

Es würde ausreichen, "brkval" aus malloc.c global Verfügbar zu
machen.
Ich habe mal das modifizierte malloc.c angehangen (source war malloc
aus der avr-libc 1.0.4).

Hier das "Tesprogramm":

--8<--
#include <avr/io.h>
#include <stdlib.h>

volatile unsigned int heapsz;

void *p;

void foo(void);
void bar(void);

unsigned int freemem(void);

int
main(void)
{
        while(1)
        {
                heapsz = freemem();
                foo();
        }

        /* NEVEREACHED */
        return 0;
}

void
foo(void)
{
        heapsz = freemem();
        bar();
}

void
bar(void)
{
        volatile unsigned char c[32];

        p = malloc(32);
        heapsz = freemem();
        //free(p);
        foo();
}

unsigned int
freemem(void)
{
        extern char *brkval;

        return (unsigned int) SP - (unsigned int) brkval;
}
-->8--

Was ist zu tun?

1. main.c und (angehängtes) malloc.c in ein Verzeichnis
2. Makefile erstellen, und eigenes malloc.c als src angeben
3. Testen...

Man müsste jetzt noch beide Varianten (malloc/kein malloc) vereinen und
schon könnte man sich genüsslich die Größe des Verbleibenden Speichers
ansehen.

Moment mal...wolltest Du "nur" die Größe des Stacks wissen?
Dann müsste doch (RAMEND - SP) das gewünschte Ergebnis liefern.

Btw., brkval heißt mittlerweile (CVS-HEAD von avr-libc) __brkval und
ist in der Tat global.  Ist natürlich kein garantiertes Interface.
Die Öffnung wurde notwendig, um realloc() implementieren zu können.

Ja, das hatte ich auch schon gesehen, deswegen auch der Hinweis auf den
Source der v1.0.4. :-)

Leichenschänder!

Peter D. schrieb:
> So, ich habs nochmal überarbeitet, funktioniert super:

Das sind die (klitze)kleinen Juwelen dieses Forums. Dinge die ich
schon immer wissen wollte aber zu faul war diese selbst zu erforschen
oder zu erarbeiten. Bin ja noch nicht so lang präsent hier im
Forum, daher findet man so etwas nur durch Zufall beim Aufwärmen
eines Threads. Also danke an den peda. Kaum 11 Jahre später ....