Speicherverbrauch bestimmen mit avr-gcc - Versionsgeschichte

Heha: /* Nutzung des SRAM durch avr-gcc */

2023-10-17T08:55:07Z

‎Nutzung des SRAM durch avr-gcc

SprinterSB: /* Dynamischer RAM-Verbrauch */ static

2014-09-14T20:18:30Z

‎Dynamischer RAM-Verbrauch: static

SprinterSB_alt: /* Dynamischer RAM-Verbrauch */

2013-07-09T16:44:23Z

‎Dynamischer RAM-Verbrauch

SprinterSB_alt: /* Dynamischer RAM-Verbrauch */

2013-07-09T11:32:43Z

‎Dynamischer RAM-Verbrauch

SprinterSB_alt: /* Dynamischer RAM-Verbrauch */ typo

2013-07-09T10:32:53Z

‎Dynamischer RAM-Verbrauch: typo

SprinterSB_alt: /* Dynamischer RAM-Verbrauch */

2011-12-11T14:17:54Z

‎Dynamischer RAM-Verbrauch

SprinterSB_alt: /* Dynamischer RAM-Verbrauch */

2011-11-10T10:35:11Z

‎Dynamischer RAM-Verbrauch

Besserwessi: /* Dynamischer RAM-Verbrauch */

2011-07-31T10:00:23Z

‎Dynamischer RAM-Verbrauch

SprinterSB_alt: /* Dynamischer RAM-Verbrauch */

2010-06-21T10:48:44Z

‎Dynamischer RAM-Verbrauch

SprinterSB_alt: /* Dynamischer RAM-Verbrauch */ typo: blenk

2010-06-21T10:47:31Z

‎Dynamischer RAM-Verbrauch: typo: blenk

@@ Zeile 33: / Zeile 33: @@
 ;<tt>.data</tt>: Statische und (modul-)globale, initialisierte Daten, denen man per Initializer einen Wert ungleich&nbsp;0 zuweist. Beginnt an der unteren SRAM-Adresse <tt>0x60</tt> nach dem SFR-Bereich, je nach AVR-Derivat auch an anderer Adresse.
 ;<tt>.bss</tt>: Statische und (modul-)globale, initialisierte Daten, die zu&nbsp;0 initialisiert sind bzw. keinen Initializer haben (und also auch zu&nbsp;0 initialisiert werden).
-;<tt>.noinit</tt>: Statische und (modul-)globale Daten, die nicht vom Startup-Code initialisiert werden und zum Beispiel einen [[Watchdog]]-Reset überdauern.
+;<tt>.noinit</tt>: Statische und (modul-)globale Daten, die nicht vom Startup-Code initialisiert werden und zum Beispiel einen [[Watchdog]]-Reset überdauern. Das ausgiebige Verwenden von <tt>.noinit</tt> hilft die Ausführungszeit des Initialisierungskodes vor <tt>main()</tt> zu verkürzen. Registervariablen werden ebenfalls nicht initialisiert, fallen jedoch in keine der RAM-Sections.
 Auf diese Sections folgen noch zwei Speicherbereiche für dynamische Daten:
@@ Zeile 44: / Zeile 44: @@
 Heap und Stack müssen sich den Speicher, der nicht von <tt>.data</tt>, <tt>.bss</tt> und <tt>.noinit</tt> belegt ist, teilen
-Wird der Stackbereich zu groß, weil dort zu viele Daten abgelegt werden (zu viele lokale Variablen (lokale Arrays!), zu tief verschaltelte (rekursive) Funktionen, kaskadierende [[Interrupt]] Service Routinen, ...), dann überschreibt man damit womöglich andere Daten und es kommt zur Fehlfunktion des Programmes. Gleiches gilt, wenn die Obergrenze des Heap über der Untergrenze des Stabels hinauswächst.
+Wird der Stackbereich zu groß, weil dort zu viele Daten abgelegt werden (zu viele lokale Variablen (lokale Arrays!), zu tief verschaltelte (rekursive) Funktionen, kaskadierende [[Interrupt]] Service Routinen, ...), dann überschreibt man damit womöglich andere Daten und es kommt zur Fehlfunktion des Programmes. Gleiches gilt, wenn die Obergrenze des Heap über der Untergrenze des Stapels hinauswächst. Genau genommen ist eine Designschwäche von avr-gcc, den angenommenen maximalen Stapelspeicherverbrauch nicht per Kommandozeile oder Linkerskript angeben zu müssen.
 =Flash- und statischer RAM-Verbrauch =

@@ Zeile 137: / Zeile 137: @@
   {{ccomment|!!! because it allocates on stack.}}
-  {{ccomment| Get minimum of free memory (in bytes) up to now.}}
+  {{ccomment|Get minimum of free memory (in bytes) up to now.}}
   unsigned short
   get_mem_unused (void)
@@ Zeile 156: / Zeile 156: @@
   {{ccomment|!!! Never call this function, it is part of .init-Code}}
-  void [[Avr-gcc/Interna#Attribute|__attribute__]] ((naked, used, section(".init3"))) init_mem (void);
+  static void [[Avr-gcc/Interna#Attribute|__attribute__]] ((naked, used, section(".init3")))
-  void init_mem (void)
+  init_mem (void)
+  {
-     {{ccomment| Use inline assembler so it works even with optimization turned off}}
+     {{ccomment|Use inline assembler so it works even with optimization turned off.}}
      __asm volatile (
         "ldi r30, lo8 (__heap_start)"  "\n\t"
@@ Zeile 169: / Zeile 171: @@
         "cpi r30, lo8 (%1)"            "\n\t"
         "cpc r31, r25"                 "\n\t"
-        "brlo 0b"
+        "brne 0b"
+           :
-           : "i" (MASK), "i" (RAMEND+1)
+           : "i" (MASK), "i" (RAMEND)
      );
+  }

@@ Zeile 103: / Zeile 103: @@
      uint16_t momentan_frei = SP - (uint16_t) &__heap_start;
-Interessanter ist es jedoch, den Maximalverbrauch an Speicher bzw. das Minimum an ungenutztem Speicher seit Applikationsstart zu bestimmen.
+Interessanter ist es jedoch, den Maximalverbrauch an Speicher bzw. das Minimum an ungenutztem Speicher seit Programmstart zu bestimmen.
-Mit der folgenden kleinen Routine kann der noch freie SRAM-Bereich bestimmt werden. Es wird nicht der momentan freie Speicher bestimmt, sondern das Minimum an Speicher, das bis dato ungenutzt geblieben ist. Dazu wird im Startup-Code das Muster <tt>0xaa</tt> in den SRAM geschrieben. Durch Aufruf der Funktion <tt>get_mem_unused</tt> wird bestimmt, wieviel von diesem Muster noch intakt ist.
+Mit der folgenden kleinen Routine kann der noch freie SRAM-Bereich bestimmt werden. Es wird nicht der momentan freie Speicher bestimmt, sondern das Minimum an Speicher, das bis dato ungenutzt geblieben ist. Dazu wird im Startup-Code das Muster <tt>0xaa</tt> in den SRAM geschrieben. Durch Aufruf der Funktion <tt>get_mem_unused</tt> wird bestimmt, wieviel von diesem Muster zum Zeitpunkt des Aufrufs noch intakt ist.
-Dieses Vorgehen ist deshalb notwendig, weil es auch [[ISR]]-Routinen gibt, die dynamisch Speicherplatz auf dem Stack brauchen, und man eine Routine zur Bestimmung des Speicherverbrauchs nicht in den ISRs aufrufen lassen will.
+Dieses Vorgehen ist deshalb notwendig, weil unter Umständen auch [[ISR]]-Routinen dynamisch Speicherplatz belegen, man jedoch <tt>get_mem_unused</tt> nicht ''in'' der ISR aufrufen will.
 Mit optimierendem Compiler brauchen die beiden Routinen zusammen 42 Bytes an Flash.

@@ Zeile 109: / Zeile 109: @@
 Dieses Vorgehen ist deshalb notwendig, weil es auch [[ISR]]-Routinen gibt, die dynamisch Speicherplatz auf dem Stack brauchen, und man eine Routine zur Bestimmung des Speicherverbrauchs nicht in den ISRs aufrufen lassen will.
-Mit optimierendem Compiler brauchen die beiden Routinen 42 Bytes an Flash.
+Mit optimierendem Compiler brauchen die beiden Routinen zusammen 42 Bytes an Flash.
 Damit der Code den richtigen Wert liefert, darf keine dynamische Speicherallokierung mit <tt>malloc()</tt> etc. geschehen sein; ein <tt>[[Avr-gcc/Interna#Dynamische Speicherallokierung|__builtin_alloca]]</tt> ist hingegen kein Problem, da letzteres den Platz vom Stapel nimmt.

@@ Zeile 103: / Zeile 103: @@
      uint16_t momentan_frei = SP - (uint16_t) &__heap_start;
-Interessanter ist es jedoch, den Maximalverbrauch an Speicher bzw. das Minimum an freiem Speicher seit Applikationsstart zu bestimmen.
+Interessanter ist es jedoch, den Maximalverbrauch an Speicher bzw. das Minimum an ungenutztem Speicher seit Applikationsstart zu bestimmen.
-Mit der folgenden kleinen Routine kann der noch freie SRAM-Bereich bestimmt werden. Es wird nicht der momentan freie Speicher bestimmt, sondern das Minimum an Speicher, das bis dato frei geblieben ist. Dazu wird im Startup-Code das Muster <tt>0xaa</tt> in den SRAM geschrieben. Durch Aufruf der Funktion <tt>get_mem_unused</tt> wird bestimmt, wieviel von diesem Muster noch intakt ist.
+Mit der folgenden kleinen Routine kann der noch freie SRAM-Bereich bestimmt werden. Es wird nicht der momentan freie Speicher bestimmt, sondern das Minimum an Speicher, das bis dato ungenutzt geblieben ist. Dazu wird im Startup-Code das Muster <tt>0xaa</tt> in den SRAM geschrieben. Durch Aufruf der Funktion <tt>get_mem_unused</tt> wird bestimmt, wieviel von diesem Muster noch intakt ist.
-Dieses Vorgehen ist deshalb notwendig, weil es auch [[ISR]]-Routinen gibt, die dynamisch Splatz (auf dem Stack) brauchen, und man eine Routine zur Bestimmung des Speicherverbrauchs nicht in den ISRs aufrufen will.
 Mit optimierendem Compiler brauchen die beiden Routinen 42 Bytes an Flash.
@@ Zeile 174: / Zeile 175: @@
+  }
-Der Grund, hier auf [[Inline-Assembler in avr-gcc|Inline Assembler]] zurückzugreifen, ist folgender: Durch normalem C/C++-Code kann man nicht garantieren, daß alle Variablen in Registern leben. In diesem Falle würden Variablen, die auf dem Stack angelegt werden, durch die init-Routine überschrieben. Davon abgesehen wird der Frame-Pointer erst zu Anfang von <tt>main</tt> gesetzt und um ihn zu lesen, bräuchte man ohnehin Inline-Assembler.
+Der Grund, hier auf [[Inline-Assembler in avr-gcc|Inline Assembler]] zurückzugreifen, ist folgender: Durch normalem C/C++-Code kann man nicht garantieren, daß alle Variablen in Registern leben. In diesem Falle würden Variablen, die auf dem Stack angelegt werden, durch die init-Routine überschrieben.
-−
-<!--
-Auskommentiert. Diese Zeile verstehe ich nicht. get_mem_unused liefert doch 16-Bit Ergebnisse.
---[[Benutzer:SprinterSB|SprinterSB]] 11:35, 10. Nov 2011 (CET)
-−
-Wenn der µC viel RAM hat und mehr als 255 bytes frei sein können, sollte man auch ein 16 Bit Ergebnis erlauben.
--->
 =Siehe auch=