Hallo Gemeinde, ich habe vor Jahren mit AVR MCUs gearbeitet. In der letzten Zeit bin ich wieder dazu gekommen. Ich arbeite unter Windows 10, habe winavr installiert und programmiere in C. https://sourceforge.net/projects/winavr/ WinAVR 20100110 version 4.3.3 Fürs Flashen benutze ich Avrdude, als IDE benutze ich Code Blocks (custom Make file project) Alles funktioniert ziemlich gut. Inzwischen habe ich gesehen das es neuere AVR Tollchain-Versionen gibt. 1) http://gnutoolchains.com/avr/ avr-gcc5.3.0.exe 2) http://blog.zakkemble.co.uk/avr-gcc-builds/ avr-gcc-7.3.0-x64-mingw.zip (51.22 MB) Ist es sinnvoll eine neuere Version zu installieren? Was ist verbessert worden? Ist der generierte Code kleiner, bzw. schneller?Ist Make file immer dabei? Würde es mit Code Blocks funktionieren? Bis jetzt war ich zufrieden mit WinAVR 20100110, auch alle MCUs die ich bisher benutze werden von der WinAVR 20100110 Version unterstützt. Danke an Euch im Voraus für Eure Antworten. Gruss, Jan
:
Verschoben durch User
Das Makefiletool aus dem WinAVR-Paket funktioniert mit allen Versionen. make ist nicht immer dabei, aber du hast ja eins aus WinAVR. Im Compiler hat es dank Johann schon einige Verbesserungen gegeben, dazu gibt auch Verbesserungen in der avrlibc. Ob du jetzt den aktuelle 7.3er, oder die von Atmel/Microchip bereitgestellte etwas ältere Version nimmst, ist fast egal. Die 5.3er hat, wenn ich mich nicht irre, einen fiesen Bug bei Strings im Flash, oder sowas in der Art. Oliver
Johann hat verschiedene Versionen hier abgelegt: https://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/ Ich persönlich bevorzuge die 4.7.2. Diese ist sehr stabil und macht auch sehr kleinen Code. Teilweise wird dieser bei den Nachfolgeversionen sogar wieder größer. Zu den neueren Versionen 6.x bis 8.x kann ich nichts sagen, habe ich nie probiert.
Danke für die Antworten. Ich werde die von Frank vorgeschlagene 4.7.2 Version https://sourceforge.net/projects/mobilechessboar/f... ausprobieren und mal die Unterschiede zu WinAVR 20100110 version 4.3.3 was die codegröße angeht hier Posten. Ich bin gespannt, was das ausmacht. Gruß, Jan
Jan schrieb: > Ich bin gespannt, was das ausmacht. Am meisten gewinnst Du, wenn Du sowohl als Compiler- als auch als Linker-Option -flto hinzufügst. Dann musst Du aber auch als Linker-Option dieselbe Optimierung hinzufügen wie beim Compiler. Am sinnvollsten ist hier -Os. Der Grund, warum -Os auch beim Linker hinzugefügt werden muss, liegt daran, dass der Linker dann nochmal alles durch den Compiler schickt - mit der angegebenen Optimierungsstufe. Deshalb darf hier -Os nicht vergessen werden, sonst klappt das nicht. In irgendeiner späteren gcc-Version wurde diese kleine "Macke" weggebügelt. Also: Compiler-Option: -Os -flto Linker-Option: -Os -flto
Ich habe es ausprobiert. Hier der Vergleich Ein einfaches Projekt mit LCD + BM280 + DM3231
1 | avr-gcc v+o 4.3.3 -Os 4.7.2 -Os 4.7.2 -Os -flto |
2 | prog/bytes 8468 7724 6102 |
3 | data/bytes 489 459 459 |
Es spielt aber keine Rolle ob ich bei LDFLAGS "-s -flto" angebe oder nicht. Beides liefert die 3 Spalte (6102 wenn ich den 4.7.2 verwende. 4.3.3 kennt kein -flto) Die Versionen 4.7.2 liefert wirklich einen kleineren Code. Eine Frage hätte ich noch. Manchmal wenn ich die Zeile CFLAGS = -g -O$(OPT) \ gegen CFLAGS = -g -Os \ ersetze bekomme ich einen Fehler. ...Keine optimierung. Aber nur manchmal... seltsam. Gruss, Jan [Mod: Tabelle neu formatiert]
:
Bearbeitet durch Moderator
Wojtek R. schrieb: > Ich habe es ausprobiert. Hier der Vergleich Sieht doch gut aus. > Es spielt aber keine Rolle ob ich bei LDFLAGS "-s -flto" angebe oder > nicht. Bearbeitest Du das Makefile manuell oder gehst Du über die Projekt-Einstellungen? Du meinst "-Os" und nicht "-s", oder? > CFLAGS = -g -O$(OPT) \ > gegen > CFLAGS = -g -Os \ > ersetze bekomme ich einen Fehler. ...Keine optimierung. Das sieht nach manueller Bearbeitung aus. Was für einen Fehler bekommst Du denn? Vielleicht hast Du noch Leerzeichen hinter dem Backslash? Die müssen da weg. > Aber nur manchmal... seltsam. Zeig doch mal so ein Makefile. P.S. Ich habe Deine Tabelle bzgl. Einrückungen neu formatiert, benutze besser für so etwas [ pre ] ... [ /pre ] (ohne die Leerzeichen). Außerdem habe ich -s durch -Os in der Überschrift ersetzt.
:
Bearbeitet durch Moderator
Danke für die nachträgliche Formatierung und die Infos. Ich werde in der Zukunft auf die Formatierung achten . >Bearbeitest Du das Makefile manuell oder gehst Du über die >Projekt-Einstellungen? Du meinst "-Os" und nicht "-s", oder? ich bearbeite es manuell. Ich habe den "seltsamen" Fehler auch gefunden. Ich hatte folgendes im Make file stehen: #CFLAGS = -g -O$(OPT) \ CFLAGS = -g -Os -flto \ > Was für einen Fehler bekommst Du denn? # warning "Compiler optimizations disabled; functions from <util/delay.h> won't work as designed" Der backslash in der auskommentierten Zeile erzeugt das Problem. Folgendes funktioniert : #CFLAGS = -g -O$(OPT) CFLAGS = -g -Os -flto \ Ich konnte noch keinen Effekt beobachten wenn ich die Linker-Option: -Os -flto setze (Zeile 120 im makefile). Ich lade mein makefile hoch Gruss, Jan
Jan W. schrieb: > # warning "Compiler optimizations disabled; functions from > <util/delay.h> won't work as designed" Der Source, welcher delay.h und damit _delay_ms() nutzt, muss zwingend optimiert compiliert werden, sonst kommt es zu dieser Fehlermeldung. > Der backslash in der auskommentierten Zeile erzeugt das Problem. > Folgendes funktioniert : > > #CFLAGS = -g -O$(OPT) > CFLAGS = -g -Os -flto \ Ja, das ist verständlich. Ein Backslash am Ende der Zeile besagt, dass die aktuelle Zeile in der nächsten Zeile fortgesetzt wird. make zieht dann die folgenden Zeilen zusammen und somit steht dann alles folgende mit im Kommentar. > Ich lade mein makefile hoch Da sehe ich noch einen Fehler: Die Optionen in LDFLAGS werden normalerweise mit Leerzeichen getrennt. Es gibt aber Optionen, die weitere Angaben benötigen, wie zum Beispiel -Wl. Diese Parameter gehörend zur Option -Wl werden dann mit Komma getrennt. Du hast geschrieben:
1 | LDFLAGS = -Wl,-Map=$(TARGET).map,--cref,-Os -flto |
Das -Os gehört aber nicht zur Option -Wl, daher darf da kein Komma davor, sondern stattdessen ein Leezeichen. Richtig wäre also:
1 | LDFLAGS = -Wl,-Map=$(TARGET).map,--cref -Os -flto |
Besser wäre aber eine optische und thematische Trennung, dann ist das viel lesbarer und auch verständlicher:
1 | LDFLAGS = -Wl,-Map=$(TARGET).map,--cref |
2 | LDFLAGS += -Os -flto |
Hier wird LDFLAGS um -Os -flto erweitert. Das dazwischen gehörende Leerzeichen macht make dann selbst rein, bevor es den Linker aufruft. Wenn Du im Makefile weiter nach unten blätterst, siehst Du, dass dies auch für alle anderen LDFLAGS genau so gemacht wird.
Danke für den Hinweis mit der Bedeutung von Komma bzw. Leerzeichen bei LDFLAGS. Ich habe folgende Zeile eingefügt : LDFLAGS += -Os -flto es führt aber zu keinen weiteren Optimierung bezüglich Codegröße und Data. Vielleicht ist es diese Linkeroptimierung Programbedingt (nur manchmal möglich). Gruss, Jan
Beitrag #5344737 wurde vom Autor gelöscht.
Jan W. schrieb: > es führt aber zu keinen weiteren Optimierung bezüglich Codegröße und > Data. Ich weiß auch jetzt, warum. In Deinem Makefile wird wie folgt gelinkt:
1 | $(CC) $(ALL_CFLAGS) $(OBJ) --output $@ $(LDFLAGS) |
Dabei stecken in ALL_CFLAGS auch die CFLAGS drin, und darin -Os -flto. Daher funktioniert das bei Dir. Dank ALL_CFLAGS ist alles doppelt gemoppelt. Das ist aber eher nicht typisch. Standardmäßig werden beim Linken nur die LDFLAGS herangezogen.
Jetzt Ich habe die Zeile $(CC) $(ALL_CFLAGS) $(OBJ) --output $@ $(LDFLAGS) durch die folgende Zeile ersetzt $(CC) -mmcu=$(MCU) $(OBJ) --output $@ $(LDFLAGS) Jetzt hat die Zeile LDFLAGS += -Os –flto ein Einfluss auf die Codegröße. Die Vergleichstabelle sieht jetzt so aus :
1 | Avr-gcc 4.3.3 CompOpt –Os 4.7.2 CompOpt –Os 4.7.2 Comp&LinkOpt –Os -flto |
2 | Prog/bytes 8468 7724 6102 |
3 | Data/bytes 489 459 459 |
Die Option –Os –flto hat nur dann Sinn, wenn sie gleichzeitig beim Compiler und Linker angegeben wird. Der Umstieg von avr-gcc 4.3.3 auf avr-gcc 4.7.2 bringt also in diesem Beispiel 28% kleineren Code! Es verhält sich so, wie Frank es beschrieben hat. Danke nochmals für die Infos. Gruss, Jan
Ich habe praktisch die gleichen Schwierigkeiten, wie Jan W.R. (jan_woj) sie hatte, auf einen neuere avr-gcc-Version umzusteigen. Bisher benutzte ich das AVR-Studio 4.19 mit WinAVR-20100110 und avr-gvv 4.3.3. Erste Versuche, den Inhalt des Verzeichnisses WinAVR-20100110 einfach mit einer neueren avr-gcc-Version (4.7.2, 5.4.0 und 8.0.1) zu überschreiben, klappten überraschenderweise recht gut. Ich möchte aber wie Jan gerne die Make-Datei anpassen, aber nicht für jedes Projekt einzeln (in den Projekteinstellungen), sondern am liebsten für die AVR-Studio-Installation. In meinem jugendlichen Leichtsinn habe ich mir gedacht, es müsste da eine Datei geben, aus der dann die Make-Datei erzeugt wird, und habe C:\WinAVR-20100110\mfile\makefile_template gefunden und nach den vorangegangenen Beiträgen abgeändert, jedoch ohne Erfolg. Verwende ich die falsche Datei?
Edi R. schrieb: > C:\WinAVR-20100110\mfile\makefile_template D.h. du verwendest mfile? http://www.sax.de/~joerg/mfile/
Johann L. schrieb: > D.h. du verwendest mfile? Anscheinend nicht, aber die Frage hat mir eventuell schon weitergeholfen. Ich war der Ansicht, das AVR-Studio würde mfile verwenden, aber wenn ich mir diesen Artikel durchlese: https://www.mikrocontroller.net/articles/WinAVR#Umstieg_von_AVR-Studio_mit_avr-gcc_zu_WinAVR_mit_AVRISP, dann vermute ich, dass ich mich zwischen dem AVR-Studio und Programmer's Notepad entscheiden muss. Im AVR-Studio ist es vermutlich nicht möglich, die make-Datei generell (d. h. nicht für jedes Projekt über die Projektoptionen) anzupassen, bei Programmer's Notepad mit mfile und AVRDUDE dagegen schon. Ist das richtig? Oder Holzweg?
Schade, echte Informationen hätten mich weiter gebracht. Aber dann werde ich eben versuchen, selber Licht in mein Dunkel zu bringen.
Angehängte Dateien:
-
CodeBlocks2.png
29 KB
Edi R. (edi_r) schrieb : >..dann vermute ich, dass ich mich zwischen dem AVR-Studio und Programmer's >Notepad entscheiden muss. Im AVR-Studio ist es vermutlich nicht möglich, >die make-Datei generell (d. h. nicht für jedes Projekt über die >Projektoptionen) anzupassen, bei Programmer's Notepad mit mfile und >AVRDUDE dagegen schon. Ist das richtig? Oder Holzweg? PProgrammer's Notepad braucht ein Makefile. AVRDUDE ist ein Tool zum flashen des Mikrocontrollers und hat mit Makefile und den ganzen Build-Prozess nichts zu tun. Falls Du AVRDUDE zum flashen nutzt, dann Empfehle ich Dir Code Blocks als IDE (open source). Bei Code Blocks lässt sich AVRDUDE einbinden, so das man aus der IDE den Mikrocontroller Flashen kann. Sehe bitte das Angehängte Screenshot. Der Editor von Code Blocks ist ganz gut und die ganze IDE ist recht einfach zu bedienen. Es ist denke ich eine relative schlanke IDE im Vergleich zu anderen IDEs. http://www.codeblocks.org/ Bei der Projekterzeugung kann man einstellen das ein Makefile benutzt wird. Dieses liegt dann in deinem Projektverzeichnis. Unter Bild options muss man als target main einstellen. Sehe bitte das zweite Screenshot AVR-Studio (4.19) nutze ich sehr selten, nur für die Simulation. Gruß, Jan
Vielen Dank für die Infos und die Screenshots. Dann werde ich mich mal näher mit Code Blocks befassen, obwohl ich eigentlich beim AVR-Studio (und ohne AVRDUDE) bleiben wollte. Aber das bietet mir vermutlich nicht die Flexibilität, die ich haben will.
>obwohl ich eigentlich beim AVR-Studio >(und ohne AVRDUDE) bleiben wollte. Aber das bietet mir vermutlich nicht >die Flexibilität, die ich haben will. Was meinst Du eigentlich mit Flexibilität ? Was genau möchtest Du machen?
Edi R. schrieb: > obwohl ich eigentlich beim AVR-Studio > (und ohne AVRDUDE) bleiben wollte. Aber das bietet mir vermutlich nicht > die Flexibilität, die ich haben will. Auch beim AVR-Studio kannst du ein externes (also eigenes) Makefile verwenden.
Jan W. schrieb: > Was meinst Du eigentlich mit Flexibilität ? > Was genau möchtest Du machen? Ich wollte die Erstellung des Makefiles beeinflussen, und zwar so, dass sowohl beim Compiler als auch beim Linker das Flag -flto zusätzlich gesetzt wird. Aber soweit ich das sehe, geht das nur, indem ich ein externes Makefile erzeuge, oder indem ich die Projektoptionen entsprechend setze. Das heißt aber, für jedes Projekt drandenken zu müssen, diese Option zu setzen, und für jedes bestehende Projekt, das ich anfasse, diese Option nachzutragen. Stefan E. schrieb: > Auch beim AVR-Studio kannst du ein externes (also eigenes) Makefile > verwenden. Ja, das weiß ich. Aber das wäre für mich noch umständlicher als das Flag -flto in den Projektoptionen zu setzen. Inzwischen habe ich mir nach der Empfehlung von Jan einmal Code Blocks angeschaut, und bis jetzt gefällt es mir recht gut. Damit habe ich eigentlich alles, was ich brauche. Nun ja, ich muss zwar jedes Projekt, das ich anfasse, erst mal umstellen auf Code Blocks, aber der Aufwand hält sich in Grenzen, dafür habe ich dann ein gewartetes System (das AVR-Studio hat ja doch schon ein paar Jahre auf dem Buckel, und mit dem Atmel Studio kann ich mich einfach nicht anfreunden) und viel mehr Erweiterungsmöglichkeiten. Nachdem ich mich sowieso auch mal mit ARM beschäftigen will, bin ich mit Code Blocks vielleicht auf dem richtigen Weg.
Wenn Du Dich mit ARM beschäftigen möchtest dann empfehle ich die folgende Seite http://stefanfrings.de/ Gruss, Jan
Vielen Dank :-). Die Seite ist echt interesant und (für mich) praxisgerecht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.