Hallo, ich habe mir für das Atmel Studio 6.1 aus den Extension Manager das Plugin CodeSize installiert. Dieses zeigt mir nun an, dass der RAM 100% ausgelastet ist. Jetzt habe ich noch aus dem ASF das "FREERTOS_UC3_EXAMPLE1" getestet. Bei diesem wird auch eine Auslastung von 99% angezeigt. Was wird eigentlich im RAM genau gespeichert? Beim AVR32 UC3 wird doch alles (Programm+Daten) in den Flash gespeichert, oder nicht? Wie kann ich den RAM verbrauch reduzieren? Meine Hardware: Alvidi Board mit AT32UC3A0512 Prozessor. Ein SDRAM ist auch auf dem Board verfügbar.
Kann es sein, dass dieses Tool "Code Size" den RAM nicht richtig berechnet? Also der RAM wird ja nur mit dem Stack (Rücksprungadressen der Funktionen) befüllt. Wie kann dann dieses Tool den Stack beim compilieren berechnen? Oder befüllt das freeRTOS den RAM? Ich kann mir irgendwie nicht vorstellen, dass mein mini-Programm oder auch das freeRTOS Example vom ASF den RAM von 64kB komplett befüllt.
Gast
#3202257
godi S. schrieb: > Also der RAM wird ja nur mit dem Stack (Rücksprungadressen der > Funktionen) befüllt. und alles globalen Variaben. Und reicht schon ein globales Array int a[65535] und der Ram ist mehr als Voll.
Gast
#3202275
Vermutlich wird das OS den Stack verwalten und dafür einfach den gesamten freien Speicher "reservieren". Das Studio-Plugin kommt damit nicht klar und zeigt einen voll belegten Speicher an.
Gast
#3202304
Hab's grad mal in meinem Projekt ausprobiert. Das Studio-Plugin zeigt einfach nur die Summe der Größen der .bss- und .stack-Section an, egal wieviel vom Stack dann zur Laufzeit verwendet wird (das kann es ja auch garnicht wissen). Zudem rundet das Plugin falsch: aus 4kB Stack + ~900Bytes BSS werden 4kB in der Anzeige. Wenn ich die BSS auf über 1kB aufblase, werden 5kB Verbrauch angezeigt.
Peter II schrieb: > godi S. schrieb: >> Also der RAM wird ja nur mit dem Stack (Rücksprungadressen der >> Funktionen) befüllt. > > und alles globalen Variaben. Und reicht schon ein globales Array > > int a[65535] und der Ram ist mehr als Voll. Hmm... Wenn ich das richtig gelesen und verstanden habe dann hat ja der AVR32 eine Neumann Architektur => Alle Daten und Code werden im flash gespeichert. Ich habe es auch Probiert mit einem großen Array, da ändert sich nur der Flash.
Martin schrieb: > Hab's grad mal in meinem Projekt ausprobiert. Das Studio-Plugin zeigt > einfach nur die Summe der Größen der .bss- und .stack-Section an, egal > wieviel vom Stack dann zur Laufzeit verwendet wird (das kann es ja auch > garnicht wissen). > Zudem rundet das Plugin falsch: aus 4kB Stack + ~900Bytes BSS werden 4kB > in der Anzeige. Wenn ich die BSS auf über 1kB aufblase, werden 5kB > Verbrauch angezeigt. Ok, also ist das Plugin für den RAM nicht brauchbar... Vielen Dank! :)
Gast
#3202474
godi S. schrieb: > Wenn ich das richtig gelesen und verstanden habe dann hat ja der AVR32 > eine Neumann Architektur => Alle Daten und Code werden im flash > gespeichert. maximal const arrays. Normale array und Variablen können nicht im Flash liegen dann könnte man sie ja nicht ändern.
Gast
#3288198
Hallo miteinander, auch wenns vielleicht nicht mehr ganz aktuell ist: FreeRtos hat, wenn entsprechend konfuguriert, eine Heap-Verwaltung. (soweit ich weiss, ist das letztlich die malloc-Lib des GCC). Ich habe mich auch immer gewundert, warum ich fast keinen freien Speicher mehr habe, egal, ob ich ein 30KByte-Array anlege, oder das ganze Array auf ein paar Bytes verkleinere. Die Heap-Verwaltung belegt (zur Link-Zeit) den ganzen noch verbliebenen Speicher. Wenn ich viele Variable deklariere, sinkt entsprechend der ( durch malloc()/free() ) verfügbare Heap. Wie das geht, habe ich nicht genau nachvollziehen können, es scheint aber möglich sein, im Linker ein Segment anzulegen, das den ganzen restlichen Speicher belegt, und dessen Eckpunkte durch entsprechende Labels zu markieren. Diesen Bereich verwendet dann die Heap-Verwaltung. Eigentlich ganz praktisch, wenn es in der malloc-Lib einen Aufruf gäbe, der die Größe des verfügbaren Heaps anzeigen würde. Ein kleines Programm ohne FreeRtos müsste sich da ganz anders verhalten... vorausgesetzt man benutzt weder malloc() noch free(). Ich hab's aber noch nicht probiert. mfg Hartmut
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.