Update von Winavr2010 auf gcc 4.8 Howto

Jörg E. OP #3141176
Lesenswert?
• ▲
▼ 
Hallo zusammen,

hoffentlich gibt es überhaupt jemanden den es interessiert.
(Ich würde dann die entsprechenden avr-gcc Artikel erweitern)

Erstmal die nackten Zahlen.
Compilieren gcc 4.3.3 WinAVR 20100110 gegen gcc 4.8 (compiliert von 
Johann Lay)

gcc 4.8
Invoking: Print Size
avr-size --format=avr --mcu=attiny85 C3_Charger.elf
AVR Memory Usage
----------------
Device: attiny85

Program:    2388 bytes (29.2% Full)
(.text + .data + .bootloader)

Data:         52 bytes (10.2% Full)
(.data + .bss + .noinit)


Finished building: sizedummy


gcc 4.3.3 WinAVR 20100110
Invoking: Print Size
avr-size --format=avr --mcu=attiny85 C3_Charger.elf
AVR Memory Usage
----------------
Device: attiny85

Program:    2562 bytes (31.3% Full)
(.text + .data + .bootloader)

Data:         52 bytes (10.2% Full)
(.data + .bss + .noinit)

Hier noch was kleineres:
gcc 4.8
Invoking: Print Size
avr-size --format=avr --mcu=attiny85 E-Kart.elf
AVR Memory Usage
----------------
Device: attiny85

Program:     504 bytes (6.2% Full)
(.text + .data + .bootloader)

Data:          0 bytes (0.0% Full)
(.data + .bss + .noinit)


Finished building: sizedummy


gcc 4.3.3 WinAVR 20100110
Invoking: Print Size
avr-size --format=avr --mcu=attiny85 E-Kart.elf
AVR Memory Usage
----------------
Device: attiny85

Program:     582 bytes (7.1% Full)
(.text + .data + .bootloader)

Data:          0 bytes (0.0% Full)
(.data + .bss + .noinit)


Finished building: sizedummy


Für mich schon ein Grund umzustellen. Ich habe allerdings noch keine 
weiteren Tests gemacht außer das die atiny85 Programme bei mir laufen.
Ich entwickle mit Eclipse Juno SR2 und dem letzten AVR-Plugin.

Nachfolgend das Howto:

Fertig kompiliertes ZIP Paket von Johann Lay von hier herunterladen und 
auf Viren prüfen ;)
http://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/
bzw. zzt. aktuellesten link
http://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/avr-gcc-4.8_2013-03-06_mingw32.zip/download


Entpacken und kurz auf Viren prüfen:
----------- SCAN SUMMARY -----------
Known viruses: 2202385
Engine version: 0.97.6
Scanned directories: 69
Scanned files: 775
Infected files: 0
Data scanned: 149.52 MB
Data read: 208.54 MB (ratio 0.72:1)
Time: 16.198 sec (0 m 16 s)

Nun alle Verzeichnisse vom alten WinAVR2010 sichern.
Bei mir sind das folgende:
avr
bin
lib
share
Ich habe sie einfach umbenannt in:
avr.2010
bin.2010
lib.2010
share.2010

Jetz alle Unterverzeichnisse aus avr-gcc-4.8_2013-03-06_mingw32
in das WinAVR-20100110 kopieren.
Dann noch avrdude.conf,avrdude.exe undlibusb0.dll
von bin.2010 nach bin kopieren

Damit sollte nun alles wieder funktionieren allerdings mit
neuestem avr-gcc

Zu prüfen indem man avr-gcc -v von der Komandozeile aufruft
oder seine Entwicklungsumgebung auf seinen Quellcode losläßt und sich
über kleineren Code freut.


Sollten Fehler drin sein freue ich mich über Anregungen.
Und wenn das jemand gut findet würde ich die einzelnen avr-gcc Artikel
entsprechend anpassen. Denn wer will schon mit alten Werkzeugen arbeiten 
;)


Gruss,

Jörg
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Jens Gast #3141202
Lesenswert?
• ▲
▼ 
Was bietet der neue GCC 4.8 denn noch außer kleineren Code?
Ich habe irgendwo gelesen, dass die neue Version endlich einen 
erweiterten Adersspointer hat. Damit wäre es endlich möglich mehr 
externen Speicher als 64kB zu adressieren. Das würde ein dringendes 
Problem bei mir lösen!
Gibt es da Aussagen dazu?

Gruß, Jens
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jörg E. OP #3141624
Lesenswert?
• ▲
▼ 
Ups du hast mich erwischt. Ja stimmt. Das hat mich auch noch ein wenig
nerven gekostet dies herauszufinden.
Also zusätzlich noch avr-size.exe aus dem bin.2010 Verzeichnis in das
neue bin Verzeichnis kopieren (vorher noch avr-size.exe im neuen bin 
Verzeichnis in avr-size-2013.exe umbenennen für die die beide Versionen 
behalten wollen) dann erhält man auch die schöne avr-size Ansicht

Gruss,
Jörg

P.S.: Wenigstens schonmal zwei die es interessiert ;)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bernd M. #3142938
Lesenswert?
• ▲
▼ 
ja, das hatte ich auch schon mal ausprobiert. allerdings hat das AVR 
Studio 4.19 knips den output nicht gut vertragen. beim umstellen auf 5 
oder 6 hat mich irgwndwas tierisch genervt. war es die winzigweich (500 
- 750 MB?) Umgebung? oder das ich mich nicht so schnell an die neue 
Oberfläche gewöhnen wollte?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
tom Gast #3294430
Lesenswert?
• ▲
▼ 
Hallo Jörg,

danke für den Tipp !
Mein aktuelles Bastelprojekt, der AVR-Transistortester, passte mit
16436 Byte gerade nicht mehr in den alten M168, nach der Umstellung
wurden nur noch 15870 Byte belegt, ich kann also mit dem Umstieg
auf den M328 noch warten ;-).

Gruß

tom
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Mike Gast #3308393
Lesenswert?
• ▲
▼ 
>Kann man nicht einfach das aktuelle AvrStudio installieren und sich dann
>die ganze Compiler-Toolchain aus dieser Installation rauskopieren?

Doch, hat bei mir funktioniert: Habe mir einfach den Inhalt vom 
Verzeichnis "avr8-gnu-toolchain" vom AvrStudio-6 ins WinAvr-20100110 
Verzeichnis kopiert und es tut. AvrStudio enthält aber noch nicht den 
GCC-4.8 sondern noch den GCC 4.7.2:
- AVR 8-bit GNU Binutils 2.23.1
- AVR 8-bit GNU Compiler Collection (avr-gcc) 4.7.2
- AVRLibC 1.8.0

Ist trotzdem einiges aktueller als der letzte Winavr-20100110 mit:
- AVR GNU Binutils 2.19
- AVR GNU Compiler Collection (GCC) 4.3.3
- avr-libc 1.6.7cvs
Antwort Zitieren Bearbeiten Löschen Beitrag melden
bla Gast #3432305
Lesenswert?
• ▲
▼ 
Danke. Wenn ich folgendes mit -flto compiliere, kriege ich eine Warning:

1
#include <avr/interrupt.h>

2


3
ISR(USART_RX_vect) {

4
}

5


6
int __attribute__((OS_main)) main() {

7
  sei();

8
  while(1);

9
}



1
C:\>avr-gcc -xc *.c -mmcu=atmega328p -flto -Wl,-Map=main.map -o main.elf

2
In function '__vector_18':

3
main.c:3:1: warning: '_vector_18' appears to be a misspelled signal handler [ena

4
bled by default]

5
 ISR(USART_RX_vect) {

6
 ^


Das war mit der alten Version kein Problem. Wie macht man es richtig?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
bla Gast #3433331
Lesenswert?
• ▲
▼ 
Danke. Irgendwie habe ich immer Pech mit Updates. ;) Kaum ausprobiert 
bin ich am Verzweifeln und suche die halbe Nacht nach meinem Fehler und 
dann ist es ein Bug. :)
Das Prerelease von deiner Seite war damals noch in Ordnung. Hätte es 
dort nochmal einen Download einer neueren Version gegeben, wäre es mir 
früher aufgefallen. Ich kompiliere immer mit -flto, weil es mir oft 15% 
Ersparnis einbringt!
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Johann L. Persönliche Seite #3433435
Lesenswert?
• ▲
▼ 
Reingekommen ist das Problem wohl hiermit:

http://gcc.gnu.org/PR57631

d.h. es wird asm ("name") auch für ISRs unterstützt: Die Warnung bzgl. 
__vector bezieht sich, falls ein asm-Label angegeben ist, auf dieses und 
nicht auf den Funktionsnamen der ISR.  Seeehr speziell diese 
Anforderung, und blöderweise auch zurückportiert auf 4.7.4+ sowie 
4.8.2+.

Wobei PR59396 bzw. die Implementierung von PR57631 nicht ein Fehler im 
avr-Teil von GCC zu sein scheint, auch wenn er sich dort einfach beheben 
ließe...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
bla Gast #3433546
Lesenswert?
• ▲
▼ 
Es gibt Leute, die ignorieren Warnungen, weil Warnungen != Fehler. Ich 
persönlich stelle den gcc lieber scharf, also -W -Wall -Wextra 
-Wstrict-overflow (letztens hier auch so ein Thema gewesen) und 
beseitige alle Auffälligkeiten. Denn wenn ich etwas ändere und aus 147 
Warnings werden 148 merke ich das vielleicht nicht und vielleicht auch 
nicht, warum. Und schon gar nicht, welche neu ist. Die meisten Warnungen 
kann man sicher ignorieren, aber es gibt eben einige, die darauf 
hindeuten, dass man irgendwo schlampig war. Ist sicher 
Geschmackssache...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jörg W. Moderator Persönliche Seite #3433597
Lesenswert?
• ▲
▼ 
Oliver schrieb:
> Nur blöd, wenn die toolchain dann einen Bug hat.

Es gibt auch Warnungen, bei denen der Compiler sich einfach irrt.
Habe sowas schon bei "possibly used uninitialized" erlebt, da ist die
statische Codeanalyse des Compilers zuweilen nicht in der Lage zu
erkennen, dass die entsprechende Variable in der Tat sicher einen Wert
besitzt, bevor sie benutzt wird.

Gut, die kann man zumindest per #pragma mittlerweile selektiv
ausschalten, die Warnung mit dem ISR-Namen offenbar leider nicht.

Warnungen zu beachten ist gut und schön, aber man sollte auch eine
Policy haben, die einzelne Warnungen ggf. gestattet.  Ich habe schon
Code erlebt, der mit -Werror im Makefile ausgeliefert worden ist
und dann bei einer neuen Compilerversion nicht mehr compilierbar
war, weil der neue Compiler mehr gewarnt hat.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Johann L. Persönliche Seite #3578695
Lesenswert?
• ▲
▼ 
horst schrieb:
> Gibt's eigentlich schon einen Fix für diesen Bug

Ja.

http://gcc.gnu.org/r208564

> und auch eine entsprechende aktuelle Windows-Toolchain fertig
> zum Download?

Wohl kaum.  Der Fix ist ab 4.8.3, die bekanntlich noch nicht releast 
ist.  Die Warnung tritt ausschießlich mit 4.8.2 auf, du kannst also 
auch auf eine ältere Version gehen wenn du nicht speziell was aus der 
4.8.2 brauchst.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Blubb Gast #3808812
Lesenswert?
• ▲
▼ 
Getestet nur mit einem Projekt:

4.8.1:
Program:   15340 bytes (93.6% Full)

4.9.2:
Program:   15484 bytes (94.5% Full)

Sind "nur" 0,9%, aber der Quellcode ist extremst optimiert, weil da noch 
ein Bootloader rein musste. Also nur 15 kB Platz. Mit der neuen Version 
passt es nicht mehr.

Kann aber auch an der zusätzlichen Optimiererei mit Compilerschaltern 
liegen. Auch da habe ich viele Stunden zugebracht, um die richtige 
Kombination für das Projekt zu finden.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Blubb Gast #3808842
Lesenswert?
• ▲
▼ 
Mit -fno-move-loop-invariants wird es hier bei der 4.9.2 kleiner (16 
Bytes), bei der 4.8.1 größer (32 Bytes). Wie gesagt, unterschiedliche 
Versionen optimieren unterschiedlich.
Auch -morder2 bringt bei der neuen Version eine Verkleinerung.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Blubb Gast #3828661
Lesenswert?
• ▲
▼ 
Und? Schon andere Tester unterwegs?
Ich habe die Erfahrung gemacht, dass es leider sehr oft zu einem 
"Segmentation fault" kommt- scheint allgemein noch sehr early beta zu 
sein. Deswegen nehme ich weiterhin die Letzte- die 4.8.1.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jörg E. OP #3881197
Lesenswert?
• ▲
▼ 
So ich habe mich mal an die letzte Version gewagt.
Es sind 2 Verzeichnisse dazu gekommen.
include und libexec.
Nur libexec existierte schon, also in libexec.2010 umbenannt.
include gabs noch nich somit reinkopiert.

Ich bekomme immer folgende Warnung:
bash.exe: warning: could not find /tmp, please create!

Liegt das am Build?
Oder kann Johann beim nächsten Build einfach was dran ändern?

Ansonsten scheinen alle meine bisher getesteten Programme ohne Fehler zu
kompilieren.

Danke für die Arbeit!


Building file: ../helper.c
Invoking: AVR Compiler
avr-gcc -Wall -Os -fpack-struct -fshort-enums -std=gnu99 -funsigned-char 
-funsigned-bitfields -mmcu=attiny85 -DF_CPU=8000000UL -MMD -MP 
-MF"helper.d" -MT"helper.d" -c -o "helper.o" "../helper.c"
bash.exe: warning: could not find /tmp, please create!
Finished building: ../helper.c

Building file: ../main.c
Invoking: AVR Compiler
avr-gcc -Wall -Os -fpack-struct -fshort-enums -std=gnu99 -funsigned-char 
-funsigned-bitfields -mmcu=attiny85 -DF_CPU=8000000UL -MMD -MP 
-MF"main.d" -MT"main.d" -c -o "main.o" "../main.c"
bash.exe: warning: could not find /tmp, please create!
../main.c: In function 'Sec':
../main.c:308:26: warning: unused variable 'o_tcnt0' [-Wunused-variable]
  volatile static uint8_t o_tcnt0 = 0;
                          ^
../main.c: In function 'CalMaxStrom':
../main.c:596:20: warning: variable 'GMax' set but not used 
[-Wunused-but-set-variable]
  uint8_t GMin = 0, GMax = 0; // Anfangswerte um Potistellung von min 
und max zu ermitteln.
                    ^
Finished building: ../main.c

Building file: ../uart.c
Invoking: AVR Compiler
avr-gcc -Wall -Os -fpack-struct -fshort-enums -std=gnu99 -funsigned-char 
-funsigned-bitfields -mmcu=attiny85 -DF_CPU=8000000UL -MMD -MP 
-MF"uart.d" -MT"uart.d" -c -o "uart.o" "../uart.c"
bash.exe: warning: could not find /tmp, please create!
Finished building: ../uart.c

Building target: E-Kart.elf
Invoking: AVR C Linker
avr-gcc -Wl,-Map,E-Kart.map -mmcu=attiny85 -o "E-Kart.elf"  ./helper.o 
./main.o ./uart.o
bash.exe: warning: could not find /tmp, please create!
Finished building target: E-Kart.elf

Invoking: AVR Create Extended Listing
avr-objdump -h -S E-Kart.elf  >"E-Kart.lss"
bash.exe: warning: could not find /tmp, please create!
Finished building: E-Kart.lss

Create Flash image (ihex format)
avr-objcopy -R .eeprom -O ihex E-Kart.elf  "E-Kart.hex"
bash.exe: warning: could not find /tmp, please create!
Finished building: E-Kart.hex

Create eeprom image (ihex format)
avr-objcopy -j .eeprom --no-change-warnings --change-section-lma 
.eeprom=0 -O ihex E-Kart.elf  "E-Kart.eep"
bash.exe: warning: could not find /tmp, please create!
Finished building: E-Kart.eep
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Johann L. Persönliche Seite #3881642
Lesenswert?
• ▲
▼ 
GCC legt während des Compilierens temporäre Dateien an, für die 
natürlich ein Verzeichnis zu bestimmen ist.

Das ist OS abhängig, und GCC versucht zunächst Werte unterschiedlicher 
Umgebungsvariablen wie TMP, TEMP, TMPDIR oder Standardverzeichnisse wie 
/tmp, /var/tmp, /use/tmp etc.  Für Windos verwendet er die 
Systemfunktion GetTempPath die ebenfalls Werte von TMP und TEMP und auch 
USERPROFILE abtestet.

Die Meldung bedeutet also, daß is deinem System kein Ordner für 
temporäre Dateien bestimmt werden kann.

Übrigens kommt die Meldung nicht von GCC, der würde melden "Cannot 
create temporary file in ...".

Das Problem wird auch ausführlich im Web besprochen und tritt auch für 
andere Tools wie GIT auf.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
900ss #3905070
Lesenswert?
• ▲
▼ 
Moin,

ich benutze zur Zeit die GCC-4.8.1 (von Georg) in Eclipse mit dem 
AVR-Plugin. Läuft soweit gut bis auf die Debugging-Infos(?) im ELF-File.

Ich habe "dwarf-2" eingestellt und erhalte beim Aufruf von AVR-GDB (über 
Eclipse ) die Meldung ... (siehe Snapshot im Anhang).
Wenn ich "stabs" oder "stabs+" einstelle, ändert sich die Fehlermeldung 
nicht. Verwende ich WinAVR_20100110 mit "dwarf-2" funktioniert es.

Ich kann zwar erstmal mit WinAVR_20100110 debuggen und wenn es läuft auf 
GCC-4.8.1 wechseln. Aber vielleicht gibt es ja Abhilfe?

Danke,
900ss
Angehängte Dateien:
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren