Mikrocontroller.net - Benutzerbeiträge [de]

AVR-GCC-Codeoptimierung

2010-10-07T23:33:00Z

78.42.25.70: /* Laufzeit messen */

Entstanden aus diesem [http://www.mikrocontroller.net/topic/66690 Thread] sollen hier ein paar Hinweise/Erfahrungen gegeben werden, um den Quellcode in Punkto Größe und Geschwindigkeit zu optimieren. ''En detail'' ist das Thema komplex, da es stark von der Codeoptimierung des Compilers abhängt. Es ist im Einzelfall ratsam zu prüfen, ob die eigenen Maßnahmen auch erfolgreich waren. Folgende Diskussionen können als Anhaltspunkt dienen, wie eine solche Prüfung ablaufen kann:

* [http://www.mikrocontroller.net/topic/132624]
* [http://www.mikrocontroller.net/topic/180800#new]

== Prinzipien der Optimierung ==

Wie so oft sollte man nicht einfach wild drauf los optimieren und sich zunächst ein paar Dinge klar machen.

* Warum will ich optimieren?
* Was kann man sinnvoll optimieren?
* Wieviel Rechenzeit oder Speicher soll dabei gespart werden?
* Wie kann optimiert werden?
* "Verfrühte Optimierung ist die Wurzel allen Übels"

Viele Optimierungen sind "Angst-Optimierungen", die nicht wirklich nötig sind. Die Gefahr mit Optimierungen ist, den Code tot zu optimieren, sprich Lesbarkeit und ggf. Fehlerfreiheit sinken massgeblich. Kurz und knapp in diesem [http://blogs.msdn.com/b/audiofool/archive/2007/06/14/the-rules-of-code-optimization.aspx BLOG] formuliert.

=== Warum ===

Optimieren sollt man nur, wenn
* der Speicher nicht mehr ausreicht (RAM, Flash)
* Die Laufzeit für bestimmte Programmteile zu groß wird und somit die Funktion nicht mehr erreicht wird

Weiter sollte man folgende Punkte gegeneinander abwägen:

* Codeverbrauch
* Datenverbrauch. Statisch/Stack/Heap
* Mittlere/maximale Laufzeit
* Entwicklungszeit
* Portabilität (Compiler, Hardware, ...)
* Verständlichkeit der Quelle, siehe [[Strukturierte Programmierung auf Mikrocontrollern]]
* ABI-Konformität

=== Was ===

Die goldene Regle lautet: 90% der Rechenleistung werden in 10% des Codes verbraucht. Diese 10% muss man finden und zum richtigen Zeitpunkt optimieren. Der Rest muss nur sauber und lesbar geschrieben sein. Was jedoch nichts bringt, das ist eine Funktion um den Faktor 10 schneller zu machen, die von 1 Minute Programmlaufzeit lediglich 1 Sekunde verbraucht. Die Programmlaufzeit sinkt dann von 60 Sekunden auf 59.1 Sekunden. Der Aufwand, die Funktion um einen Faktor 10 schneller zu machen ist aber meistens beträchtlich! Kann ich aber den Code, der für die 59 Sekunden verantwortlich ist um einen Faktor 10 schneller machen, dann sinkt die Gesamtlaufzeit von 60 Sekunden auf 6.9 Sekunden. Dort bringt Optimieren augenscheinlich viel mehr!

Um die optimierungswürdigen Stellen zu finden, muss man sein Programm analysieren. Dazu gibt es verschiedene Möglichkeiten.

====Speicherverbrauch nach Funktionen aufschlüsseln====

*Map File anschauen
**dort sind alle globalen und statischen Variablen enthalten
**Aus der Differenz der Anfangsadressen kann man die Programmgröße der Funktionen berechnen
*Hilfsmittel einkaufen oder selber bauen. Es gilt rauszufinden, welche Funktion massig Stack durch lokale Variablen verbraucht. Stacktracer können das. Wenn man keinen hat, dann muss man sich eben selber einen bauen, indem man den Stackpointer mitlogt. Zur Not einen Code-Review machen: Alle Funktionen optisch durchgehen und die identifizieren, die viele Variablen anlegen. Dann die Aufrufhierarchie der Funktion feststellen: Wirken sich die vielen Variablen überhaupt aus oder ensteht mein Problem durch eine tiefe Funktionsaufrufhierarchie, bei der zwar wenige Variablen pro Funktion im Spiel sind, aber die Menge der ineinandergeschachtelten Aufrufe 'das Kraut fett macht'
* Profitools können das alles fast auf Knopfdruck, kosten aber viel Geld

====Laufzeit messen====

*Simulator
*In Echtzeit mittels Testpin, welche an Anfang einer Funktion/Blocks gesetzt wird und am Ende wieder gelöscht wird. Mit einem [[Oszilloskop]] kann man so sehr einfach die Laufzeit messen.

=== Wieviel ===

Der Aufwand von Optimierungen wächst exponentiell. Die letzten paar Prozent brauchen überproportional viel Aufwand.

=== Wie ===

Meist muss man die Wahl treffen ob man Speicher oder Rechenzeit sparen will, beides gleichzeitg geht meist nicht. Das Konzept heißt 'Space for Time' und kann in beide Richtungen verwendet werden. Als Beispiel soll eine komplizierte Berechnung dienen. Diese kann man relativ kompakt in eine Funktion packen, welche dann aber eher langsam ist. Oder man benutzt eine sehr große Tabelle, in welcher die Ergebnisse schon für jeden Eingangswert vorausberechnet wurden. Diese Lösung ist sehr schnell, verbraucht aber sehr viel Speicher.

* Inlining von Funktionen erhöht den Speicherverbrauch, senkt aber die Laufzeit. Beispiel: Funktion A ist 50 Byte groß und wird 10 mal im Programm aufgerufen. Ein Aufruf kostet 10 Byte:
** Ohne Inline: 10 * 10Byte + 50 Byte = 150 Byte Platzverbrauch
** Mit Inline: 10 * 50 Byte = 500 Byte
* Optimierer einschalten
* möglichst keine Floating Point Operationen, besser ist meist [[Festkommaarithmetik]]
* Formeln umstellen und zusammenfassen
* Variablen so klein wie möglich, uint8_t wo's nur geht.
* Wirklich zeitkritische Funktionen und Interrupts als Assemblercode in separater Datei

==Optimierung der Größe==

===GCC-interne Optimierung===

Im AVR-Studio kann bei den Projekteinstellungen der gewünschte Optimierungsgrad eingestellt werden. Hier gibt es folgende Möglichkeiten:
*O0 - keine Optimierung, Code wird direkt in Assembler umgesetzt
*O1-O3 - Optimierung auf Geschwindigkeit, Grad 1-3; von O3 ist für Mikrocontroller abzuraten, da durch Function-Inlining die Code-Größe sehr stark zunimmt
*Os - Optimierung vorrangig auf Codegröße. Durch diese Einstellung lässt sich vor allem bei umfangreicheren Projekten sehr viel Platz sparen. Für Mikrocontroller oft sehr vorteilhaft.

===Nullinitialisierung von statischen Variablen===

Bisher hatte ich mich in meinen Init-Funktionen nicht auf den Startup-Code verlassen, sondern die nötigen Variablen genullt. So kann ich auch eine Re-Initialisierung machen, habe aber keinen Gebrauch davon gemacht. Stattdessen starte ich komplett neu. Entfernung der Null-Inits brachte einiges. (OK, kann man doch als Anfängerfehler bezeichnen, ich mußte erst im C-Standard nachlesen
daß das BSS-Nullen keine Eigenart von gcc ist.)

===Statische (globale) Variablen in ein struct sammeln===

Das erleichtert dem Compiler die Adressierung, da er den Basiszeiger wiederverwenden kann. Die Codegröße kann dann noch von der Reihenfolge der struct-Member abhängen. Die häufigst benutzte Variable sollte am Anfang stehen, dann kann sie ohne Offset direkt mit dem Basiszeiger adressiert werden. Ansonsten in Gruppen, wie die Variablen auch gebraucht werden. Hier kann man viel rumprobieren...

Beispiel:
<c>
typedef struct
{
uint16_t sec; // Meistbenutze Variable an den Anfang
uint16_t minute;
uint16_t hour;
} t;

t global; // Globale Struktur definieren
uint8_t min; // Als Vergleich: einzelne globale Variable

int main(void)
{
t *time = &global; // Zeiger auf die globale Struktur
// LDI R30,LOW(global) ; Init Z pointer
// LDI R31,(global >> 8) ; Init Z high byte
if (++time->sec == 60)
{
// LDD R16,Z+2 ; Load with displacement
// INC R16 ; Increment
// STD Z+2,R16 ; Store with displacement
// CPI R16,LOW(60) ; Compare
// BRNE ?0005 ; Branch if not equal
}
if ( ++min == 60)
{
// LDS R16,LWRD(min) ; Load direct from SRAM
// INC R16 ; Increment
// STS LWRD(min),R16 ; Store direct to SRAM
// CPI R16,LOW(60) ; Compare
// BRNE ?0005 ; Branch if not equal
}
return 0;
}
</c>

Dadurch, dass die Strukturvariable über LDD/STD (LDD/STD 2 Bytes; LDS/STS 4 Bytes) angesprochen werden kann, werden an dieser Stelle 4 Bytes eingespart.
Hinzu kommen jedoch noch einmal die 4 Bytes für die Initialisierung des Z-pointers, sodass die Einsparung erst bei mehreren Globalvariablen zum Tragen kommt.

===Multiplikationen mit Konstanten===

Der Compiler instanziiert sofort eine teure allgemeine Bibliotheksfunktion, auch wenn es anders ginge. Ich hatte eine einzige 32-bit Multiplikation mit 10 drin, die mir ein mulsi3 beschert hat. Mit a = (b<<3) + (b<<1) geht es in dem Fall kürzer. Wie gesagt, map-File beobachten.
Anmerkung: Variablen als unsigned definieren, dann sollte der Compiler das selbst machen.

===Alle Variablen nur so breit wie nötig===

Hatte ich eigentlich schon, nur an einigen wenigen Stellen war ich da etwas nachlässig. Mitunter reicht ein kleinerer Typ doch, wenn man z. B. vorher geeignet skaliert. Am besten nur die skalaren Typen aus <stdint.h> verwenden, das erleichtert auch das Folgende. Bei RAM Knappheit: kann ich Strings sinnvollerweise aus dem RAM ins Flash verbannen? Kann ich es mir leisten mehere Flag-Variablen in ein Byte zusammenzufassen, auch wenn dann die Zugriffe mglw. etwas langsamer werden.

===Logische Operatoren werden auf int-Größe erweitert===

Obwohl der AVR ein 8-Bit Controller ist, weitet der AVR-GCC an manchen Stellen Vergleiche von zwei 8-Bit Variablen auf 16-Bit auf.
Als Beispiel sei dabei folgendes gezeigt:

<c>
void foo(uint8_t a, uint8_t b)
{
if (a == b)
{
// tue dies
}
if (a == ~b)
{
// tue das
// clr r19 ; clear register
// mov r24,r22 ; copy register
// clr r25 ; clear register
// com r24 ; one's complement
// com r25 ; one's complement
// cp r18,r24 ; compare registers
// cpc r19,r25 ; compare registers with carry
// brne .L1 ; branch if not equal
}
}
</c>
Den zweiten Vergleich mit der Negation weitet der Compiler auf 16 Bit auf.
Ein Cast verhindert dieses:
<c>
void foo(uint8_t a, uint8_t b)
{
if (a == b)
{
// tue dies
}
if (a == (uint8_t) ~b)
{
// tue das
// com r22 ; one's complement
// cp r25,r22 ; compare registers
// brne .L1 ; branch if not equal
}
}
</c>
Die Einsparung an Speicher zwischen den beiden Versionen beträgt 12 Bytes. Außerdem ist die zweite Version um 6 Takte schneller.

'''Achtung:''' Tatsächlich handelt es sich dabei nicht um ein Optimierungsproblem, sondern einen typischen Programmierfehler. Die beiden Varianten sind keineswegs identisch. Bei Variablen vom Typ uint8_t wird der Ausdruck (a == ~b) immer falsch sein (a=0x0000:0x00FF, ~b=0xFF00:0xFFFF). Dem Compiler ist allenfalls anzulasten, dass er nicht darauf hinweist.

===Eine bool-Variable negieren===

Das geht ganz gut so:
<c>
c = not c ;
</c>
oder besser so:
<c>
if ( c ) c = false ; else c = true ;
</c>
Am besten geht das mit WinAVR20090313, wenn geschrieben wird:
<c>
c = c ^ true ;
</c>

===Compileroption -mint8 für 8-Bit Arithmetik als Default===

Mit obigen casts überall sähe der Code ziemlich schlimm aus. Blöd auch, wenn man mal einen Type ändert, dann muß man sorgsam nach den zugehörigen casts
suchen. Mit dem Compilerschalter -mint8 wird das zum Standard. Bei mir
hat das etwa 200 Byte gespart! Man sollte dafür aber keine ints mehr im
Code haben, nur noch Typen definierter Größe aus <stdint.h>.
Literal-Werte muß man ggf. anpassen (z. B. mit postfix L long machen)
damit sie nicht überlaufen, Compiler-Warnings beachten. Ist anscheinend
noch etwas experimentell(?), mit dem aktuellen gcc 4.1.1 gibt es eine
Unverträglichkeit in <stdint.h>, der kriegt ein Problem mit den 64-bit Typen. Ist aber wohl in Arbeit, ich habe einen Patch gesehen.

Die meisten Funktionen der avr-libc vertragen sich nicht mit -mint8!

===Stack auf 256 Bytes begrenzen===

Mit dem Compileflag -mtiny-stack wird für den Stack eine einfachere Adressierung möglich, die aber "nur" 256 Byte Stacktiefe erlaubt. Wenn man nicht exzessiv automatische Variablen benutzt (Arrays!) oder eine hohe
Verschachtelungstiefe hat, sollte das ausreichen. Hat mir nochmal knapp 100 Byte (!) kleineren Code erzeugt.

===Prolog/Epilog von main() verkleinern===

''main()'' ist für Embedded-Anwendungen unnötigerweise eine normale Funktion.
Das könnten wir nur dann gebrauchen, wenn ''main()'' rekursiv aufgerufen wird,
und das wäre auf einem Mikrocontroller nicht sonderlich sinnvoll. Schon eine einfache Endlosschleife ''for(;;)'' am Ende läßt den Compiler wohl erkennen, das er sparen kann, wird 4 Byte kürzer.

Für die Verwendung von ''noreturn'' muss in der '''main.h'''
int main(void) __attribute__((noreturn));
und in der '''main.c''' das normale
int main(void)
{
..
}
verwendet werden. Eine Warnung wird jedoch darauf hinweisen, das es keinen Retun gibt, trotz ''int'' definition.

Definiert man hier ein
void main (void) __attribute__((noreturn));
so wird sich der Compiller über das fehlende ''int'' beschweren, die Codegröße bleibt bei beiden Varianten die gleiche: es werden 12 Bytes gesparrt (gegenüber ''int main(void)'').

Um die Warnungen endgültig zu unterdrücken, einfach -Wno-main als Compiler Schalter verwenden.

===Speichern von globalen Flags===

Oft werden in den Programmen Flags verwendet um beispielsweise eingetroffene Interrupts in der main-Routine auszuwerten. Hierzu wird üblicherweise eine globale Variable verwendet.

Um den Wert dieser Variable abzufragen, muss sie jedoch erst aus dem SRAM in ein Register geladen werden, und kann dann erst auf ihren Status hin überprüft werden. Eine Möglichkeit ist, der globalen Variablen ein einziges Register fest zuzuordnen:
<c>
register uint8_t counter8_1 asm("r2");
register uint8_t counter8_2 asm("r3");
register uint16_t counter16_1 asm("r4"); // r4:r5
register uint16_t counter16_2 asm("r6"); // r6:r7
</c>
siehe auch: http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_regbind

Als Alternative kann man ein nicht verwendetes Register des I/O-Bereichs verwenden. Dabei würde sich z. B. das Register eines zweiten UARTs, oder das EEPROM-Register anbieten, falls diese nicht benötigt werden.

Neuere AVR-Modelle besitzen für diesen Zweck 3 frei verwendbare Bytes im bitadressierbaren I/O-Bereich: GPIOR0-2.

===Speichern von globalen volatilen Variablen===

Ähnlich wie globale Flags werden in Programmen häufig globale Variablen benötigt um eine Kommunikation zwischen einer Interruptroutine und z. B. der main-Routine zu ermöglichen. Diese Variable muss dann als volatile deklariert werden.

Man könnte diese Variable dazu wieder in einem Register abspeichern, mit z. B.
<c>
register volatile uint8_t counter8_1 asm("r2");
</c>
die Kombination von register und volatile scheint jedoch mit avr-gcc nicht problemlos zu klappen, siehe http://www.mikrocontroller.net/topic/136799#new.

Allerdings kann man genau wie bei den Flags auch hier wieder ein nicht verwendetes SFR Register verwenden, wie die des UARTs oder des EEPROMs, oder die frei verwendbaren Register GPIOR0, GPIOR1, und GPIOR2 (falls vorhanden). Glücklicherweise sind alle SFRs bereits als volatile deklariert (siehe Header-Datei sfr_defs.h), so dass ein #define ausreicht:
<c>
#define counter8_1 GPIOR0

ISR(){
counter8_1++;
}

int main(void){
while(){
if(!counter8_1) put_str("Cool");
}
}
</c>

===Puffern von volatile-Variablen===

Der Compiler behandelt volatile-Variablen bei mehreren Manipulationen wie heiße Kartoffeln. Für jeden einzelnen Vorgang wiederholt sich das Spiel:

* aus dem Speicher holen
* bearbeiten
* zurückspeichern

Unter Umständen ist dieses Verhalten unsinnig. Ein Minimalbeispiel:

<c>
volatile char var;

ISR(){
var++;
if (var>100) var=0;
}

void main (void){
while(1){
printf(var);
}
}
</c>

Hier wird '''var''' in der ISR insgesamt zwei mal aus dem RAM geholt und zurückgeschrieben. Das ist unsinnig, da die Interruptrountine nicht unterbrochen werden kann. Aus Sicht der ISR bräuchte man eigentlich kein volatile, kann es aber wegen dem zurgiff von main herraus nicht weglassen. Eine Lösung findet sich im folgenden Schnipsel:

<c>
volatile char var;

ISR(){
char temp=var;
temp++;
if (temp>100) temp=0;
var=temp;
}

void main (void){
while(1){
printf(var);
}
}
</c>

Hier wird die globale Variable '''var''' in der lokalen Variable '''temp''' gepuffert. Ein Nachteil durch das Anlegen von '''temp''' ergibt sich nicht, da das dafür verwendete Register für die Manipulation sowieso benötigt wird. Wie alle Optimierungen kann dieses Vorgehen auch nach hinten losgehen: Wenn Laden und Zurückspeichern von '''var''' weit auseinanderliegen (extrem lange ISR), müllt man sich die Register zu. Im schlimmsten Fall wird '''temp''' sogar zwischenzeitlich auf dem Stack ausgelagert.

===Schleifen===

Bei Schleifen, die eine bestimmte Anzahl an Durchläufen ausgeführt werden sollen, ist es besser den Schleifenzähler vorher auf einen Wert zu setzen, und am Ende einer Do-While Schleife diesen zu dekrementieren.
So beschränkt sich die Sprungbedingung auf ein brne (branch if not equal).

Beispiel:
<c>
uint8_t counter;
counter = 100;
do
{
// mach irgendetwas
} while (--counter);
</c>

===Ein paar Schlagworte===

Es gibt noch -ffreestanding, soll noch ein pragma für main() geben welches
Prolog/Epilog kappt, vielleicht kann man die Vektortabelle beschneiden.

Mit -mcall-prologues werden die mitunter recht langen push/pop-Sequenzen in komplexen Funktionen durch Hilfsfunktionen ersetzt. Das kann vor allem bei grossen Programmen Platz sparen.

Switch-Statements werden durch -mno-tablejump manchmal deutlich kürzer.

==Optimierung der Ausführungsgeschwindigkeit==

Hierzu gibt es schon eine Application-Note von Atmel:

[http://www.atmel.com/dyn/resources/prod_documents/doc1497.pdf AVR035: Efficient C Coding for AVR ]

Evtl. auf deutsch hier übersetzen?

[[Category:AVR]]

WinAVR

2010-10-04T22:32:30Z

78.42.25.70: /* Passende AVR-Studio Version */

[[Category:AVR]]

WinAVR ist die Windows-Distribution der [[C]] und C++ aus der GNU compiler-collection [[AVR-GCC]] für [[AVR]]-[[Mikrocontroller]]. Der [[AVR-Ada|Ada]]-Compiler war mal enthalten und kann inzwischen nachinstalliert werden. WinAVR enthält neben dem Compiler und den erforderlichen Zusatzprogrammen (sogen. Binutils) noch einige andere Pakete, z. B. die C-Standardbibliothek avr-libc (inkl. Dokumentation), die Programmiersoftware [[AVRDUDE]] und den Editor Programmer's Notepad.

[http://winavr.sourceforge.net/ Download über die WinAVR-Startseite]

== Installation ==

Auf 64bit-Windows darf WinAVR '''nicht''' im Standard-Programmverzeichnis "C:\Program Files (x86)" installiert werden, sonst [http://www.mikrocontroller.net/topic/83517#700417 funktioniert der Compiler nicht]. Es ist entweder das vom Installer vorgeschlagene Defaultverzeichnis zu verwenden, oder z.B. "C:\WinAVR".

Nach dem Installieren sollten Win9X-Rechner neu gestartet werden, um die Erweiterung des Suchpfades um die WinAVR-Verzeichnisse zu aktivieren (autoexec.bat). Bei Windows NT/2000/XP ist üblicherweise kein Neustart erforderlich, sollte aber dennoch ausgeführt werden, wenn Probleme auftreten (Fehler in der Art: ''Der Befehl ist falsch geschrieben/kann nicht gefunden werden...''). Danach kann man sofort im Programmer's Notepad z. B. mit dem Beispielcode anfangen.

Zwei WinAVR Verzeichnisse müssen in der PATH-Umgebungsvariable aufgeführt sein:

<pre>
C:\Dokumente und Einstellungen\willi>path
PATH=[...]C:\WinAVR\bin;C:\WinAVR\utils\bin;[...]
</pre>

== Tipps + Tricks ==

=== Umstieg von AVR-Studio mit avr-gcc zu WinAVR mit AVRISP ===
* Programmer's Notepad 2 hat konfigurierbare Menüpunkte, vorkonfiguriert sind:
**Make all
**Make clean
**Make program
* Man muss sich selbst um ein passendes Makefile kümmern. Dazu kann WinAVR/mfile/mfile.tcl genutzt werden (Achtung, F_CPU ist im Template bereits mit 8 MHz eingestellt und muss ggf. von Hand geändert werden). mfile benötigt TCL/TK ([http://www.activestate.com/Products/Download/Download.plex?id=ActiveTcl Win32 download], ca 20 MB).
* Zum Flashen wird AVRDUDE benutzt.
* Wenn es beim Flashen einen 'out of sync' Fehler gibt, ist nicht der richtige AVRISP eingestellt (unterschiedliche Softwareversionen).

=== WinAVR Version ===

Die aktuelle WinAVR Version ist derzeit (01/2010) WinAVR-20100110.
[http://winavr.sourceforge.net/ SourceForge.net WinAVR Projekt-Seite] und [http://sourceforge.net/projects/winavr/files/ Download]

Bekannte Probleme:
* [http://www.mikrocontroller.net/topic/163022#1554907]: AVRDUDE Fehler: avrdude was compiled without usb support. Abhilfe: Ältere Version nehmen oder selbst kompilieren [http://www.mikrocontroller.net/topic/163675#1561957].

=== Passende AVR-Studio Version ===
Wenn eine WinAVR-Version 2007... mit AVR Studio betrieben wird, ist AVR Studio Version >= 4.13 erforderlich. Beim Projekt Erstellen möglichst einen Leerzeichen freien Pfad nehmen, da es andern falls zu Problemen/Fehlern(z. B. error: 'UBRR' undeclared (first use in this function)) kommen '''kann''' beim compilieren, eine neue Installation behebt den Fehler nicht.

Downloadadressen sind derzeit:
* [http://www.atmel.no/beta_ware AVR Tools Beta Site]
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio 4 Site] (Registrierung notwendig!)

=== MAKE funktioniert nicht ===

==== Richtiges Make Programm? ====
<pre>
> make all
MAKE Version 5.2 Copyright (c) 1987, 2000 Borland
Error makefile 461: Command syntax error
...
</pre>

Wenn make mit dieser oder ähnlichen Fehlermeldung abbricht, ist der Pfad für ausführbare Programme nicht auf das make Programm aus dem GCC/Binutils Paket gesetzt. Es wird ganz banal das falsche Make-Programm (z. B. von Borland C oder Delphi) für das verwendete makefile aufgerufen. In diesem Fall ist die Umgebungsvariable PATH in Autoexec.Bat (Windows 98SE) bzw. in der Systemsteuerung (Windows XP, 2000) anzupassen.

==== gcc plug-in: Error: Object file not found on expected location ====

Diese Fehlermeldung kann nur auftauchen, wenn der GNU C Compiler aus dem AVR-Studio heraus bedient wird. Dass keine weiteren Fehlerursachen genannt werden, ist eigentlich ein [[AVR-Studio Bugs|AVR-Studio Bug]].

Eine Analyse des AVR-Studio Bugs hat [http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=53658 Johan Ekdahl im avrfreaks.net Forum] beschrieben. AVR-Studio erkennt in gewissen Fällen beim '''Build'''-Vorgang auftretende Fehler nicht und erwartet eine nie hergestellte Ausgabedatei.

Auf jeden Fall sollte man in AVR Studio mal zwischen dem Build und Message-Fenster umschalten, ob ein einem von beiden mehr Infos stehen, was wodurch den Fehler produziert.

Wenn nicht mehr Infos aus AVR Studio herauszukitzeln sind, könnte man das Projekt beispielsweise als herkömmliches Make-Projekt aufsetzen, mit WinAVR kompilieren (Kommandozeile oder aus dem Programmers Notepad heraus) und auf Fehlermeldungen achten.

Siehe auch:
* [http://www.mikrocontroller.net/topic/80188 gcc plug-in: Error: Object file not found...] im Forum

==== avr-gcc: _spawnvp: No such file or directory ====

<pre>
> "make.exe" all

-------- begin --------
avr-gcc (GCC) 4.1.1 (WinAVR 20070122)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

Linking: main.c.elf
avr-gcc -mmcu=at90s2313 -I. -gdwarf-2 -DF_CPU=7372800UL -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns= -std=gnu99 -Wundef -MMD -MP -MF
.dep/main.c.elf.d --output main.c.elf -Wl,-Map=main.c.map,--cref
-lm
avr-gcc: _spawnvp: No such file or directory
make.exe: *** [main.c.elf] Error 1

> Process Exit Code: 2
</pre>

Bei WinAVR-20070122 und WinAVR-20070525 kann es unter VISTA und Windows98SE eine ähnliche Fehlermeldung wie oben gezeigt geben.

Verschiedene Binärpatches können diese Probleme beheben:
* [http://www.mikrocontroller.net/topic/61716#508449 Forenbeitrag von MadWizard] und [http://www.madwizard.org/extern/winavr-vista/ Originalseite] für VISTA (32-Bit). Bei der 64-Bit Version von VISTA wird berichtet, dass der Linker mit Fehlermeldung abbricht.
* [http://www.mikrocontroller.net/topic/60163#490161 Forenbeitrag von Stefan] für Windows98SE

WinAVR-20071221 funktioniert unter Windows98SE, wie erste Tests zeigen, wie aus der Tüte, d.h. ohne Binärpatch (Jippy!).

==== ...\WinAVR\utils\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 487 ====

<pre>
> "make.exe" all
AllocationBase 0x0, BaseAddress 0x71590000, RegionSize 0x470000, State 0x10000
E:\WinAVR\utils\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 487

-------- begin --------
avr-gcc (GCC) 3.4.3
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

AllocationBase 0x0, BaseAddress 0x71590000, RegionSize 0x470000, State 0x10000
E:\WinAVR\utils\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 487
make.exe: *** [sizebefore] Error 1

> Process Exit Code: 2
</pre>

Wenn make mit dieser oder ähnlichen Fehlermeldung abbricht, ist es einen Versuch wert, die Hilfsdatei '''msys-1.0.dll''' im Ordner des Tools sh.exe (beim Beispiel E:\WinAVR\utils\bin\) auszutauschen. Eine Anleitung dazu gibt es von Madwizard (http://www.madwizard.org/extern/winavr-vista). Siehe auch im Forum die [http://www.mikrocontroller.net/topic/70505#573305 Frage von Lukas] und die [http://www.mikrocontroller.net/topic/79973#667605 Frage von werdlangsammüde].

==== make: *** [####.eep] Error 1 ====

<pre>
Build started 18.8.2007 at 20:14:23
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load"
--change-section-lma .eeprom=0 -O ihex I2C_Motor.elf I2C_Motor.eep
c:\Programme\WinAVR\bin\avr-objcopy.exe: there are no sections to be
copied!
c:\Programme\WinAVR\bin\avr-objcopy.exe: --change-section-lma
.eeprom=0x00000000 never used
make: *** [I2C_Motor.eep] Error 1
Build succeeded with 0 Warnings...
</pre>

Diese oder eine ähnliche Fehlermeldung erscheint, wenn im erzeugten Programm der [[EEPROM]]-Abschnitt unbenutzt ist. Um die Fehlermeldung zu unterdrücken, kann man vor den Aufruf von avr-objcopy im Makefile ein Minuszeichen schreiben ([http://www.mikrocontroller.net/topic/76369#633387 Forenbeitrag von Jörg]).

Beispielzeilen in einem Makefile '''ohne''' Fehlerunterdrückung:
<pre>
%.eep: %.elf
@echo
@echo $(MSG_EEPROM) $@
$(OBJCOPY) -j .eeprom \
--set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 \
--no-change-warnings -O $(FORMAT) \
$< $@ || exit 0
</pre>

Beispielzeilen in einem Makefile '''mit''' Fehlerunterdrückung:
<pre>
%.eep: %.elf
@echo
@echo $(MSG_EEPROM) $@
-$(OBJCOPY) -j .eeprom \
--set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 \
--no-change-warnings -O $(FORMAT) \
$< $@ || exit 0
</pre>

==== make.exe: *** No rule to make target `main.elf', needed by `elf'. ====

<pre>
-------- begin --------
avr-gcc (GCC) 4.2.2 (WinAVR 20071221rc1)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO warranty;
not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

make.exe: *** No rule to make target `main.elf', needed by `elf'. Stop.

> Process Exit Code: 2
> Time Taken: 00:02
</pre>

Diese oder eine ähnliche Fehlermeldung erscheint, wenn der Quelltest NICHT main.c heisst und ein Makefile OHNE weitere Anpassung an den verwendeten Dateinamen der Quelltextdatei verwendet wird.

Abhilfe ist also die Quelltextdatei in main.c umbenennen oder das Makefile anzupassen (siehe [[AVR-GCC-Tutorial]]).

Eine weitere Fehlerursache könnte auch eine Ordnerstruktur mit Leerzeichen und/oder Sonderzeichen im Pfad sein.

Eine weitere Ursache kann das benutzte Makefile sein. Es ist da anscheinend eins im Umlauf mit falscher Einrückung der Anweisungen ([http://www.mikrocontroller.net/topic/123719#1126830] und [http://www.mikrocontroller.net/topic/116346#1043825])

==== fatal error: opening dependency file .dep/main.o.d: No such file or directory ====

<pre>
avr-gcc (GCC) 4.2.2 (WinAVR 20071221)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

Compiling: main.c
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -Os -funsigned-char
-funsigned-bitfiel
ds -fpack-struct -fshort-enums -Wall -Wstrict-prototypes
-Wa,-adhlns=main.lst -
std=gnu99 -DF_OSC=3686400 -MD -MP -MF .dep/main.o.d main.c -o main.o
main.c:21: fatal error: opening dependency file .dep/main.o.d: No such
file or directory
compilation terminated.
make: *** [main.o] Error 1
</pre>

Sind Leerzeichen oder Sonderzeichen im Verzeichnispfad ([http://www.mikrocontroller.net/topic/99642#864556])?

Wird VISTA 64 benutzt? Obige Fehlermeldung kann als zweite Fehlermeldung nach der eigentlichen VISTA-spezifischen Fehlermeldung (sync_with_child Problem) kommen. Die Lösung hat dann [http://www.madwizard.org/electronics/articles/winavrvista MADWIZARD].

==== make: Interrupt/Exception caught (code = 0xc00000fd, addr = 0x4217b3) ====

WinAVR darf nicht im Standard-Programmverzeichnis "C:\Program Files (x86)" installiert werden, sonst kommt dieser Fehler. Es ist entweder das vom Installer vorgeschlagene Defaultverzeichnis zu verwenden, oder z.B. "C:\WinAVR".

=== Portable Installation ===

Das Hauptproblem beim Ausführen von WinAVR von einem USB-Stick ist der fehlende Eintrag für den Compilerpfad in der Windowsumgebungsvariable PATH.

Die folgende Batchdatei zum Starten des Programmers Notepad extrahiert mit %~dp0 das Laufwerk und den Pfad vom Aufruf der Batchdatei und setzt damit PATH neu.

Zu beachten ist, das die neu gesetzte PATH Variable nicht systemweit etabliert wird, sondern nur für Prozesse gilt, die aus dieser Batch (mit dieser cmd Session) aufgerufen werden (in diesem Fall pn.exe)

....\WinAVR\pn.bat

<pre>

@echo off
echo PN.BAT Version 1.0

set BatchPath=%~dp0
set BinDir=pn\
set BinDir=%BatchPath%%BinDir%
set PATH=%BatchPath%\bin;%BatchPath%\utils\bin;%PATH%

start %BinDir%pn.exe

</pre>

=== Code-Größe anzeigen ===
* [[WinAVR: Code-Größe anzeigen]]
* Das Tool [[AVR-GCC#Tipps_.26_Tricks|avr-nm]]

=== Avrdude findet libusb0.dll nicht (WinAVR-20070525) ===
[http://www.mikrocontroller.net/topic/83524#701461 Forenbeitrag von Paul]: Habe leider noch etwas zu bemängeln, und zwar meckerte avrdude, dass es die "libusb0.dll" nicht fand. Musste dann erst noch manuell den Pfad c:\winavr\utils\libusb\bin in die autoxecec.bat eintragen. Siehe auch [http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=373283 Diskussion bei www.avrfreaks.net]

=== C-Quellcode fehlt im *.LSS Listing (WinAVR-20071221) ===

In WinAVR-20071221 werden im ggf. erzeugten Disassemblerlisting (Dateiendung .LSS) keine Quellcodezeilen angezeigt. Es handelt sich um ein Problem des Programms avr-objdump ([http://www.mikrocontroller.net/topic/87778#744096 Forenbeitrag]). Der User DosMan hat einen [http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=59538 Workaround #1] bei www.avrfreaks.net angegeben (zum Download ggf. kostenlos registrieren). Ein anderer ebenfalls bei www.avrfreaks.net beschriebener [http://www.mikrocontroller.net/topic/87778#774185 Workaround #2] besteht darin, die Zeilenenden im C-Quelltext in "Unix-Zeilenenden" (nur \n statt \n\r) umzuformen bzw. nur mit Editoren zu arbeiten, die solche Unix-Zeilenenden erzeugen.

=== Hilfe! Habe neues WinAVR und das Datensegement ist jetzt riesig! (WinAVR-20071221) ===

Es gibt in der aktuellen Version bereits gemeldete Bugs im Zusammenhang mit '''float''' Variablen bzw. den neu geschriebenen Gleitzahlfunktionen der avr-libc ([http://www.mikrocontroller.net/topic/86837#734278 Forumsbeitrag]). Wir können im Moment nur hoffen (oder besser: mitarbeiten), dass bald ein WinAVR Update herauskommt.

=== WinAVR-2010 soll die letzte Version sein? [http://www.mikrocontroller.net/topic/178763] ===

[http://www.makehackvoid.com/group-projects/mhvavrtools MHV AVR Tools] - A WinAVR Replacement. With WinAVR marked as inactive, and no official release yet from Atmel, we (Make Hack Void, an association of geeks & artists. We are forming a Hackerspace* in Canberra) have built our own set of tools in a WinAVR-like layout suitable for use as a replacement. Please note that no guarantees as to fitness or suitability are being made. In particular,GCC 4.5.1 has not been tested as extensively as GCC 4.4.x, so use our builds at your own risk.

== Siehe auch ==
* [[AVR-GCC-Tutorial]]
* [[AVR-GCC]]
* [[AVR-Studio]]
* [http://www.mikrocontroller.net/forum/gcc GCC-Forum]