AVR unter Windows in C, welche Toolchain?

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.

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]

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.

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

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.

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

hier noch das erste Screenshot nachträglich

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.