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?
(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
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.