Avr-gcc/Interna - Versionsgeschichte

SprinterSB_alt: /* Attribute von avr-gcc */ typo

2012-11-27T22:46:59Z

‎Attribute von avr-gcc: typo

SprinterSB_alt: /* Attribute von avr-gcc */

2012-11-27T22:43:59Z

‎Attribute von avr-gcc

SprinterSB_alt: /* Attribute von avr-gcc */ OS_task, OS_main

2012-11-27T22:43:31Z

‎Attribute von avr-gcc: OS_task, OS_main

SprinterSB_alt: /* Allgemeine Charakteristika von avr-gcc */ --> GCC Wiki

2012-11-23T21:52:59Z

‎Allgemeine Charakteristika von avr-gcc: --> GCC Wiki

SprinterSB_alt: /* Registerverwendung */ --> GCC wiki

2012-11-23T21:51:06Z

‎Registerverwendung: --> GCC wiki

SprinterSB_alt: /* Nützliche Attribute von GCC */ Typo

2012-11-23T21:46:13Z

‎Nützliche Attribute von GCC: Typo

SprinterSB_alt: /* Frühe Codeausführung vor main() */

2011-08-21T18:55:49Z

‎Frühe Codeausführung vor main()

SprinterSB_alt: /* Sections */ tippo

2011-07-13T21:29:40Z

‎Sections: tippo

SprinterSB_alt: /* Sections */

2011-07-13T21:28:50Z

‎Sections

SprinterSB_alt: /* Attribute von avr-gcc */

2011-07-01T11:18:52Z

‎Attribute von avr-gcc

@@ Zeile 309: / Zeile 309: @@
   | <tt>progmem</tt>
 !|  || x ||
-  | Lokatiert read-only Daten ins Flash
+  | Lokatiert read-only Daten ins Flash. <tt>progmem</tt> in '''typedef wird nicht unterstützt!'''
   |-
   | <tt>naked</tt>
@@ Zeile 317: / Zeile 317: @@
   |<tt>interrupt</tt>
 !| x || ||
-  |Hier nur wegen der Vollständigkeit erwähnt
+  |Hier nur wegen der Vollständigkeit erwähnt. Verwendet AVR Libc in ISR(·,ISR_NOBLOCK)
   |-
   |<tt>signal</tt>
 !| x ||  ||
   |Hier nur wegen der Vollständigkeit erwähnt. Verwendet AVR Libc in ISR(·)
   |-
   |<tt>OS_main</tt>
@@ Zeile 340: / Zeile 336: @@
 <pre>
 void __attribute__ ((constructor))
-foo()
+foo (void)
+{
     /* Code */

@@ Zeile 336: / Zeile 336: @@
   |}
-'''Beispiele:'''
+;Beispiele:
 <pre>
 void __attribute__ ((constructor))
 foo()

@@ Zeile 309: / Zeile 309: @@
   | <tt>progmem</tt>
 !|  || x ||
-  | Lokatiert ins Flash
+  | Lokatiert read-only Daten ins Flash
   |-
   | <tt>naked</tt>
@@ Zeile 321: / Zeile 321: @@
   |<tt>signal</tt>
 !| x ||  ||
-  |Hier nur wegen der Vollständigkeit erwähnt
+  |Hier nur wegen der Vollständigkeit erwähnt. Verwendet AVR Libc in ISR(·)
   |}

← Nächstältere Version		Version vom 23. November 2012, 21:52 Uhr
Zeile 52:		Zeile 52:

	=Allgemeine Charakteristika von avr-gcc=		=Allgemeine Charakteristika von avr-gcc=
		+
		+	:→ ''[http://gcc.gnu.org/wiki/avr-gcc#ABI avr-gcc: Application Binary Interface (ABI)] im GCC Wiki''

	;Groß- und Kleinschreibung: C unterscheidet generell zwischen Groß- und Kleinschreibung, sowohl bei Variablen- und Funktionsnamen, bei Sprungmarken als auch bei Makros, und je nach Betriebssystem auch bei Pfad- und Dateinamen/Dateierweiterungen.		;Groß- und Kleinschreibung: C unterscheidet generell zwischen Groß- und Kleinschreibung, sowohl bei Variablen- und Funktionsnamen, bei Sprungmarken als auch bei Makros, und je nach Betriebssystem auch bei Pfad- und Dateinamen/Dateierweiterungen.

@@ Zeile 70: / Zeile 70: @@
 ==Registerverwendung==
 avr-gcc verwendet die Prozessor-Register [[GPR]]s auf eine definierte Art und Weise. Wie die Register verwendet werden, muss man wissen, wenn man Assembler-Funktionen schreibt, die mit durch avr-gcc übersetztem C-Code zusammenpassen sollen. Der "reinen" C-Programmierer muss sich keine Gedanken um die Register-Verwendung machen.
 ;R0: ein temporäres Register, in dem man rumwutzen darf. Der Compiler verwendet dieses Register als Scratch-Register.

@@ Zeile 262: / Zeile 262: @@
   |Funktion wird geinlinet falls möglich
   |-
-  |<tt>always-inline</tt>
+  |<tt>always_inline</tt>
 !| x  || ||
   |Funktion wird geinlinet

@@ Zeile 344: / Zeile 344: @@
 * Vorbelegung globaler Datenobjekte: Daten ohne Initializer werden zu 0 initialisert ([[avr-gcc/Interna#Sections|Section]] <tt>.bss</tt>). Für Daten mit Initializer (Section <tt>.data</tt>) werden die Werte aus dem Flash ins SRAM kopiert.
 * Initialisierung von Registern wie R1, in dem bei avr-gcc immer die Konstante 0 gehalten wird.
 Im Linker-Script werden Sections von <tt>.init0</tt> bis <tt>.init9</tt> definiert, die nacheinander abgearbeitet werden. Erst danach wird <tt>main</tt> betreten. Um Code früh auszuführen, legt man die Funktion in eine dieser Sections:
-  void code_init3() __attribute__ ((naked, section (".init3")));
+  void code_init3(void) __attribute__ ((naked, used, section (".init3")));
   {{comment|!!! never call this function !!!}}
@@ Zeile 355: / Zeile 357: @@
+  }
-Der Code in den <tt>.init''n''</tt>-Sections wird sequenziell ausgeführt, daher darf in diese Sections nur der nackte Funktions-Code, ohne Prolog und ohne Epilog (also auch ohne <tt>ret</tt>-Instruktion!). Da disee nackten Funktionen kein <tt>ret</tt> haben, dürfen sie nicht explizit aufgerufen werden! Ihr Aufruf erfolgt implizit dadurch, daß ihr Code in einer <tt>init</tt>-Section steht.
+Der Code in den <tt>.init''n''</tt>-Sections wird sequenziell ausgeführt, daher darf in diese Sections nur der nackte Funktions-Code, ohne Prolog und ohne Epilog (also auch ohne <tt>ret</tt>-Instruktion!). Da diese nackten Funktionen kein <tt>ret</tt> haben, dürfen sie nicht explizit aufgerufen werden! Ihr Aufruf erfolgt implizit dadurch, daß ihr Code in einer <tt>init</tt>-Section steht.
 Zu beachten ist dabei
@@ Zeile 362: / Zeile 364: @@
 * Lokale Variablen müssen in Registern liegen, denn vor Ende von <tt>.init2</tt> ist der Stackpointer noch nicht initialisiert. Zudem ist die Funktion <tt>naked</tt>, hat also insbesondere keinen Prolog, der den Framepointer (Y-Register) setzen könnte, falls er benötigt wird.
 * Gegebenenfalls ist daher die Verwendung von [[Inline-Assembler in avr-gcc|inline-Assembler]] angezeigt oder die Implementierung in einem eigenen Assembler-Modul, das dazu gelinkt wird. Der erzeugte Code ist im List-File zu überprüfen.
-* Werden mehrere Funktionen in die selbe init-Section gelegt, ist die Reihenfolge ihrer Ausführung nicht spezifiziert und i.a. nicht die gleiche wie in der Quelle.
+* Werden mehrere Funktionen in die selbe init-Section gelegt, ist die Reihenfolge ihrer Ausführung nicht spezifiziert und i.A. nicht die gleiche wie in der Quelle.
 Unbenutzte init-Sections haben die Nummern 0, 1, 3 und 5 bis 8. Die verbleibenden werden vom Startup-Code verwendet:
-;<tt>.init2</tt>: Initialisieren von R1 mit 0 und setzen des Stackpointers
+;<tt>.init2</tt>: Initialisieren von R1 mit 0 und Setzen des Stackpointers
-;<tt>.init4</tt>: Kopieren der Daten vom Flash ins SRAM (<tt>.data</tt>) und löschen von <tt>.bss</tt>
+;<tt>.init4</tt>: Kopieren der Daten vom Flash ins SRAM (<tt>.data</tt>, <tt>.rodata</tt>) und Löschen von <tt>.bss</tt>
-;<tt>.init6</tt>: C++ Konstruktoren
+;<tt>.init6</tt>: Ausführung von globalen Konstruktoren
-;<tt>.init9</tt>: Sprung zu <tt>main</tt>
+;<tt>.init9</tt>: Aufruf von <tt>main</tt>
 Ein Programmbeispiel für Code in einer init-Section ist in "[[Speicherverbrauch bestimmen mit avr-gcc#Dynamischer RAM-Verbrauch|Speicherverbrauch bestimmen mit avr-gcc]]".
 [[Kategorie:Microcontroller]]

@@ Zeile 125: / Zeile 125: @@
 Sections sind mit Fächern vergleichbar, in die Daten, Code, Debug-Informationen usw. einsortiert werden. Zur Section <tt>.text</tt> gehört z.B. der ausführbare Code, welcher letztendlich im Flash landet. Wo genau das ist, braucht man nicht zu wissen und es spielt auch keine Rolle, wo eine bestimmte Funktion landet.
-Für 'normalen' Code und 'normale' Daten braucht man sich nicht um die Sections zu kümmern, sie werden von avr-gcc automatisch richtig zugeordnet. Für spezielle Anwendungen kann es aber notwendig sein, die Ablage in eine andere Section zu machen; etwa wenn man Daten im EEPROM lesen/schreiben will. Wie das genau gemacht wird, steht im Abschnitt "[[#Attribute|Attribute]]" und es gibt ein Beispiele in den Abschnitten
+Für 'normalen' Code und 'normale' Daten braucht man sich nicht um die Sections zu kümmern, sie werden von avr-gcc automatisch richtig zugeordnet. Für spezielle Anwendungen kann es aber notwendig sein, die Ablage in eine andere Section zu machen; etwa wenn man Daten im EEPROM lesen/schreiben will. Wie das genau gemacht wird, steht im Abschnitt "[[#Attribute|Attribute]]" und es gibt Beispiele in den Abschnitten
 "[[avr-gcc#SRAM, Flash, EEPROM: Datenablage am Beispiel Strings|Datenablage am Beispiel Strings]]" und "[[Zufallszahlen mit avr-gcc|Zufall]]".

@@ Zeile 136: / Zeile 136: @@
 |-
 |<tt>.data</tt> ||SRAM  ||Daten ||wird vom Startup-Code initialisiert
 |-
 |<tt>.bss</tt>  ||SRAM  ||Daten ||wird vom Startup-Code zu 0 initialisiert
@@ Zeile 143: / Zeile 145: @@
 |<tt>.progmem.data</tt> ||Flash  ||Daten ||Daten im Flash, die dort mit <tt>PROGMEM</tt> bzw. <tt>__attribute__((progmem))</tt> abgelegt wurden und mit <tt>pgm_read_*</tt>-Funktionen gelesen werden können
 |-
-|<tt>.eeprom</tt>  ||EEPROM ||Daten ||Daten im EEPROM
+|<tt>.eeprom</tt>  ||EEPROM ||Daten ||Daten im EEPROM, die dort z.B. mit <tt>EEMEM</tt> hingelegt werden
 |-
 |<tt>.noinit</tt>  ||SRAM   ||Daten ||wird nicht initialisiert
@@ Zeile 156: / Zeile 158: @@
 |-
 |<tt>.bootloader</tt> ||Flash||Code ||für den Bootloader
 |}