FreeRTOS, dyn.Speicher und Heap

[Thomas Kusch (Gast)]

Hallo!

Ich kaempfe mich hier muehevoll aber stetig durch das FreeRTOS an einem
LPC2148 mit Crossworks durch (danke nochmal an Martin fuer den
wertvollen Tipp mit dem SWI!).
Diesmal gilt die Frage dem Handling der dynamischen
Speicherreservierung. Das FreeRTOS bietet da ja drei mechanismen:
-heap_1.c: FreeRTOS-eigen ohne Speicherfreigabe
-heap_2.c: FreeRTOS-eigen mit Speicherfreigabe aber ohne
Blockzusammenfuehrung
-heap_3.c: Ueber GCC (malloc/free)
Ich spiele gerade mit der dritten Methode, nachdem die zweite
funktioniert hat, jedoch durch die Einschraenkung nicht sehr
befriedigend ist.

Meine Frage dreht sich um die Definition der Heap-Groesse..
Sehe ich es korrekt, dass die Groesse des Heaps in den ersten zwei
Faellen im Header (FreeRTOSConfig.h) und im dritten Fall ueber die
Property vom Linker (Eintrag Heap_Size)?

Ich bin mir dessen nicht sicher, da ich gaenzlich andere Adressen fuer
die allokierten Bloecke erhalte. malloc/free scheint da vom Top des
Heaps nach unten zu allokieren, im anderen Fall vom Bottom nach oben..

BTW: Gibts eine "Faustformel" fuer die Bestimmung der Heapgroesse?

[Martin Thomas (Gast)]

(freut mich, dass der SWI-Hinweis weitergeholfen hat)

Ohne mich mit der Heap-Verwaltung von FreeRTOS genauer
auseinandergesetzt zu haben, ein Abriss ueber die "uebliche"
Implementierung: Im "Fall 3" also der Verwaltung des Heaps ueber
Funktionen der libc (bei WinARM und GNUARM ist es die newlib, der
Compiler hat damit wenig zu tun) gibt man per Linker-Skript die Postion
der ersten freien Speicherstelle vor, die fuer den Heap genutzt werden
kann. Typisch per Definition von "end" im Linker-Skript. Die Adresse
ergibt sich aus der Belegung des RAMs durch die vorgegebenen Bereiche:
data, bss und evtl. noch ein reservierter Bereich fuer den Stack,
"RAM-functions" etc., je nach gewaehltem Memory-Layout. Die libc
benoetigt eine Hilfsfunktion fuer die Heap-Verwaltung, die eine
Verbundung zwischen der allgemeinen (controllerunabhaengigen) Routinen
der libc und der Hardware bereitstellt. Diese Funktion heisst sbrk(_r)
und ist ein sogenannter syscall. sbrk (z.B. newlib default-syscalls,
newlib-lpc) benoetigt die Information der ersten freien Speicherstelle,
eben das besagte "end" (ob man es nun end oder HEAP_START oder
HEAP_BOTTOM nennt ist egal, Hauptsache ein konsistentes "ab hier
geht's los" zwischen Linker-Definition und sbrk). Ob man
"Heap-Size" vorgibt und nutzt haengt von der Impmentierung ab, also
ob in "sbrk" z.B. eine Art Pruefung auf "kein Speicher mehr frei"
enthalten sein soll. Wirklich gebraucht wird das fuer die eigentliche
Vergabe nicht.
Ob man "andere Adressen" von malloc zurueckerhaelt haengt wohl stark
von der Implementierung ab. Kann also gut sein, dass man deutliche
Unterscheide sieht.
Bei malloc/free der newlib startet soweit ich das nachvollzogen habe
von niedrigen Speicheraddressen (ab end) und steigt zu hoeheren.
("nachvollzogen" = ich nutze "malloc" normalerweise nicht,
lediglich indirekt wenn Funktionen aus stdio verwendet werden, die
ihrerseits dynamisch Speicher allokieren).

Moeglicherweise nuetzlich: newlib-manual, newlib source-code,
source-code der newlibc-lpc (Beispiele fuer sbrk-Implementierungen).

Martin Thomas

[Thomas Kusch (Gast)]

Hallo Martin!

Danke fuer die erneut sehr informative Antwort!

Ich glaube, ich verzichte auf die malloc/free-Variante, da sie mir doch
den Quellcode sehr aufblaeht. Ich werde die FreeRTOS-eigene,
vereinfachte Implementierung einsetzten..

Danke nochmal,
Thomas Kusch