Ich habe bis jetzt immer mit dem WinAVR-Paket, auf das vom Tutorial verwiesen wird (http://sourceforge.net/projects/winavr/files/), 'gearbeitet'. Nun habe ich mir GCC 4.7.2 installiert und bekomme beim Build die im Betreff genannte Fehlermeldung. Wie kann ich mir jetzt das Makefile mit korrekten Optionen für avr-size erzeugen lassen?
Die Option -C war ein grässlicher Hack, den Eric Weddington in WinAVR eingebracht hat und sich nicht ausreden ließ. (Ihm war dabei von vornherein klar, dass eine solche Option zumindest in der gewählten Implementierung keine Chance hat, es jemals in die offiziellen Binutils zu schaffen.) Benutze die Option -B und ggf. den avr-size.sh Script, den es zuvor für diesen Zweck gab.
Danke erstmal. Jörg Wunsch schrieb: > Benutze die Option -B Das will ich ja probieren, aber wo ersetzt man jetzt das -C in -B? Ich habe ja kein selbst erstelltes Makefile.
Ralf G. schrieb: > Ich habe ja kein selbst erstelltes Makefile. Dann entweder ein solches benutzen, oder das Kommando avr-size durch einen Wrapper ersetzen, der das -C einfach ignoriert und das richtige (umbenannte) avr-size.exe mit -B aufruft.
Oder richtig Quick&Dirty ein älteres avr-size (mit -C Support) drüber kopieren.
Jörg Wunsch schrieb: > Dann entweder ein solches benutzen, oder das Kommando avr-size durch > einen Wrapper ersetzen, der das -C einfach ignoriert und das richtige > (umbenannte) avr-size.exe mit -B aufruft. Hmm. Ich glaube, ich hab' noch was vergessen: Build wird vom AVR-Studio (4.18) gestartet. Wenn ich das richtig verstanden habe, wird aus den Projekteinstellungen ein Makefile gebastelt. Heißt das jetzt: Fehlermeldung erstmal ignorieren und avr-size extra aufrufen! Oder kann da in einer Konfigurationsdatei einfach fix was geändert werden?
Stefan Ernst schrieb: > Oder richtig Quick&Dirty ein älteres avr-size (mit -C Support) drüber > kopieren. Sowas wollte ich erst machen! War nur zu blöd, mal richtig nachzusehen wo avr-size ist :-( Jetzt geht's... Hmm... GCC 4.7.2 genehmigt sich gleich noch ein paar Bytes mehr Flash...
Ralf G. schrieb: > Wenn ich das richtig > verstanden habe, wird aus den Projekteinstellungen ein Makefile > gebastelt. Ja, man kann aber auch ein eigenes drunterlegen und ihm sagen, dass er jenes benutzt.
Jörg Wunsch schrieb: > Ja, man kann aber auch ein eigenes drunterlegen und ihm sagen, dass > er jenes benutzt. Später vielleicht ;-) Durch eure Anstöße funktioniert's jetzt erstmal. Danke.
Ralf G. schrieb: > Hmm... GCC 4.7.2 genehmigt sich gleich noch ein paar Bytes mehr Flash... Da lässt sich einiges durch Optionen nachtrimmen, bei mir bis zu 7% besseren Code (beide Varianten mit -Os aber weiteren Optionen).
Johann L. schrieb: > Da lässt sich einiges durch Optionen nachtrimmen, bei mir bis zu 7% > besseren Code (beide Varianten mit -Os aber weiteren Optionen). Welche weiteren optionen verwendest du? Danke, michi
Johann L. schrieb: > Da lässt sich einiges durch Optionen nachtrimmen, bei mir bis zu 7% > besseren Code (beide Varianten mit -Os aber weiteren Optionen). Kann schon sein. Ich habe bei dem Projekt, was ich mir zum Vergleich rausgesucht habe, an den Optionen erstmal nichts geändert. Optionen = wie von AVR Studio vorgegeben + -fno-inline-small-functions + -Os GCC 4.3.3 -> 1018 bytes (99.4% Full) GCC 4.7.2 -> 1048 bytes (102.3% Full) ohne -fno-inline-small-functions GCC 4.3.3 -> 1114 bytes (108.8% Full) GCC 4.7.2 -> 1048 bytes (102.3% Full) ??
Ohne was über die Quelle zu wissen, lann man dazu kaum was sagen. Einige Optimierungsschalter sind in AVR-GCC-Codeoptimierung: GCC-Optionen erklärt. Aber GCC kennt hunderte von Optonen... Ralf G. schrieb: > GCC 4.3.3 -> 1018 bytes (99.4% Full) Naja, wenn der Code schon bis Unterkante Oberkiefer steht...
Johann L. schrieb: > Ohne was über die Quelle zu wissen, lann man dazu kaum was sagen. Ist mir klar. > Naja, wenn der Code schon bis Unterkante Oberkiefer steht... Ich habe nicht gemeckert. Es ist mir nur aufgefallen. Und wenn sonst alle anderen meinen: 'Dafür ist das Programm aber jetzt viiiel schneller!', dann haben sich die Compilerentwickler was dabei gedacht und ich kann damit gut leben. Vielleicht muss ich mich ja nur mal mit der 'Feinabstimmung der Optimizer' beschäftigen (falls ich das mal will!). Okay, eins hab' ich ja bereits rausgefunden: '-fno-inline-small-functions' nützt schon mal nichts.
Johann L. schrieb: > Naja, wenn der Code schon bis Unterkante Oberkiefer steht... Ach ja: Das ganze ist ein funktionierendes Programm. Es war reines Interesse da mal den neuen Compiler ranzulassen.
Wenn es mehr als 100% belegt kann man aber nicht testen, ob es funktioniert... Compiler sind nicht perfekt, und werden es wohl auch nie werden...
[krümelkack] Johann L. schrieb: > Wenn es mehr als 100% belegt kann man aber nicht testen, ob es > funktioniert... [/krümelkack] Die 99.4%-Variante vom GCC 4.3.3 meinte ich natürlich.
Was ich damit meinte ist: Es wäre interessant, den mit avr-gcc 4.7.2 erzeugten Code so klein zu bekommen, daß er auch ausführbar wird. Wenn man so an der "bleeding edge" der Codegröße ist, muss man natürlich an alles Stellen punkten. Im C-Code zu sündigen und dann vom Compiler Ablass zu erwarten, funktioniert i.d.R. nicht.
Johann L. schrieb: > Im C-Code zu sündigen und dann vom Compiler Ablass zu erwarten, > funktioniert i.d.R. nicht. Ich erwarte gar nichts! Ich wollte einfach nur mal sehen, was passiert! Und ob das gesündigt ist, kannst du doch gar nicht einschätzen mit deiner Glaskugel. Und wenn's schlampig programmiert sein sollte, dann mach ich doch den Compiler nicht dafür verantwortlich. Ich hab' mal weiter probiert (http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#GCC-Optionen ): '-fno-split-wide-types' ist die einzige Option, die bei beiden Compilerversionen 2 Bytes spart. '-fno-inline-small-functions' nützt nur in Version 4.3.3 was Ralf G. schrieb: > GCC 4.3.3 -> 1018 bytes (99.4% Full) > GCC 4.7.2 -> 1048 bytes (102.3% Full) > > ohne -fno-inline-small-functions > GCC 4.3.3 -> 1114 bytes (108.8% Full) > GCC 4.7.2 -> 1048 bytes (102.3% Full) Johann L. schrieb: > Was ich damit meinte ist: Es wäre interessant, den mit avr-gcc 4.7.2 > erzeugten Code so klein zu bekommen, daß er auch ausführbar wird. GCC 4.3.3 nehmen :-)
Ralf G. schrieb: > Johann L. schrieb: >> Im C-Code zu sündigen und dann vom Compiler Ablass zu erwarten, >> funktioniert i.d.R. nicht. > Und ob das gesündigt ist, kannst du doch gar nicht einschätzen mit > deiner Glaskugel. Das was ich schrieb ist eine allgemeine Binsenweisheit, unabhängig von dir und von deinem Code. Ob du in deinem Code Böcke schiesst oder nicht weißt nur du selbst.
Ralf G. schrieb: > GCC 4.3.3 nehmen :-) Das halte ich für den falschen Weg. Ich habe mit dem gcc 4.7.2 ein Dutzend Projekte neu compiliert und musste feststellen, dass das Binary in den meisten Fällen gegenüber dem 4.3.3er kleiner wurde. Aber es gab durchaus auch Programme, die minimal größer wurden. Ich habe mir dann die betreffenden Stellen durch Analyse der lss-Datei im Code angeschaut und konnte da durch diverse Codeumstellungen bzw. Optimierungen dem 4.7.2er Compiler noch etwas unter die Arme greifen, so dass letztendlich auch diese Programme kleiner wurden. Es lohnt sich also durchaus, mal nach den betreffenden Stellen zu schauen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.