mikrocontroller.net

Forum: Compiler & IDEs Update von Winavr2010 auf gcc 4.8 Howto


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Jörg E. (jackfritt)
Datum:

Bewertung
1 lesenswert
nicht 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

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Jörg E. (jackfritt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube das musst du selbst ausprobieren.
Soviel passt nich in meinen atiny ;)

Gruss,

Jörg

Autor: Felix P. (fixxl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um die oben gepostete Anzeige mit den Prozentangaben zu erhalten, wurde 
wahrscheinlich auch die "alte" avr-size.exe aus dem 2010er-Ordner in den 
bin-Ordner verschoben, oder?

Autor: Jörg E. (jackfritt)
Datum:

Bewertung
0 lesenswert
nicht 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 ;)

Autor: Bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das eigentlich eine Final oder noch Beta? Oder Alpha... irgendwelche 
bekannten schlimmen Bugs drin, die in der 4.7.2 noch nicht drin waren?

Autor: Jörg E. (jackfritt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also das Changelog musst du dann schon selber lesen :)
Und das mit neuer Software neue Bugs kommen können liegt wohl auf der 
Hand.

Autor: Bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, leider war in den heruntergeladenen Archiv kein Changelog... sonst 
hätte ich natürlich nicht gefragt. :)

Autor: Bernd M. (bernd_m)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Jörg E. (jackfritt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok hier noch mehr Infos für unentschlossene.
http://gcc.gnu.org/gcc-4.8/changes.html
http://gcc.gnu.org/wiki/avr-gcc

Ich hoffe damit sind alle Fragen beseitigt ;)
Gruss,
Jörg

Autor: tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Peter S. (psavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseits!

Kann man nicht einfach das aktuelle AvrStudio installieren und sich dann 
die ganze Compiler-Toolchain aus dieser Installation rauskopieren?

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die toolchains gibt's doch bei Atmel auch  einzeln zum Download. Den 
Umweg übers Studio kann man sich damit sparen.

Oliver

Autor: Peter S. (psavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die toolchains gibt's doch bei Atmel auch  einzeln zum Download

Tatsächlich, hier der Link:
http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORWINDOWS.aspx

Leider noch nicht mit dem 4.8er GCC

Autor: Bäh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt's eigentlich irgendwo die aktuellen Windows-Binaries für 4.8.1? Auf
http://sourceforge.net/projects/mobilechessboar/files/avr-gcc snapshots 
(Win32)/
liegen leider noch immer die alten auf dem Prerelease 4.8.0 Basierenden.

Autor: Felix P. (fixxl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt jetzt eine neue auf GCC 4.8.1 basierende AVR-GCC-Toolchain für 
Windows, die man bei Atmel herunterladen kann: 
http://atmel.com/images/avr8-gnu-toolchain-installer-3.4.3.12-win32.any.x86.exe

Autor: bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke. Wenn ich folgendes mit -flto compiliere, kriege ich eine Warning:
#include <avr/interrupt.h>

ISR(USART_RX_vect) {
}

int __attribute__((OS_main)) main() {
  sei();
  while(1);
}

C:\>avr-gcc -xc *.c -mmcu=atmega328p -flto -Wl,-Map=main.map -o main.elf
In function '__vector_18':
main.c:3:1: warning: '_vector_18' appears to be a misspelled signal handler [ena
bled by default]
 ISR(USART_RX_vect) {
 ^

Das war mit der alten Version kein Problem. Wie macht man es richtig?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bla schrieb:
> Danke. Irgendwie habe ich immer Pech mit Updates. ;)

Naja, so tragisch ist die Warnung ja nun auch nicht.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist denn mit den "mhvavrtools"?  die sind doch angetreten WINAVR zu 
ersetzen.

Autor: bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bla schrieb:
> Ist sicher
> Geschmackssache...

Ist keine Geschmackssache. Warnungen sind grundsätzlich ernst zu nehmen. 
Eigentlich sollte man gleich zu -Werror greifen.
Nur blöd, wenn die toolchain dann einen Bug hat.

Oliver

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt's eigentlich schon einen Fix für diesen Bug und auch eine 
entsprechende aktuelle Windows-Toolchain fertig zum Download?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
4.8.2? Sicher?? Ich habe den Fehler ja mit der offiziellen 4.8.1 von der 
Atmel-Seite...

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
horst schrieb:
> 4.8.2? Sicher??

Ja, sicher.

> Ich habe den Fehler ja mit der offiziellen 4.8.1 von der Atmel-Seite...

Sicher weil: Ich hab den Fehler eingebaut und auch korrigiert (im GCC).

Was Atmel so treibt und welche Patches die alle einspielen oder nicht, 
musst du die fragen.

: Bearbeitet durch User
Autor: horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
4.9 ist draußen. ;)

Autor: Ferdi C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für AVR?? Wo kann ich die runterladen? Link?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für alle von GCC unterstützten Architekturen, 44 wenn ich mich nicht 
verzählt hab.

Für einen avr-gcc dann:
$PATH-TO-GCC/configure --prefix=$PATH-TO-INSTALL --enable-languages=c,c++ --target=avr --disable-nls

Autor: Felix P. (fixxl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wärst du eventuell bereit, von der GCC 4.9 für AVR eine Windows-Version 
analog wie bei 4.8 anzubieten?

: Bearbeitet durch User
Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jaaaa, das wäre super. Diesem Wunsch schließe ich mich an. :D

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was hat 4.9.0 denn tolles, was 4.8.2 nicht hat?

Autor: horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
z.B. deinen Bug nicht. SCNR

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
gibt es schon was neues zum Thema avr gcc 4.9.0 für Windows?
hab bis jetzt leider nix finden können.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es hier inzwischen eigentlich etwas Neues? Denkanstoß: Gäbe es 
neuere Binaries, gäbe es auch mehr Tester und mehr Augen, die Fehler 
finden könnten...

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
auch mich interessiert ob es hier etwas Neues gibt. Habe noch immer 
WinAVR installiert - die alte eben.

Autor: Jörg E. (jackfritt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal nachgeschaut und Johann hat heimlich eine aktuellere 
Version reingestellt. Hier der link für 4.9.2
http://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/avr-gcc-4.9.2_2014-09-12_mingw32.zip/download

Ich habe aber noch nix getestet, keine Zeit. Wird wohl jemand anderes 
schaffen ;)

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Jörg für den Link. Bevor ich das teste schaue ich erst mal daß ich 
den Fehler in meinem einfachen Beispiel finde.

Autor: Blubb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super, also die neue Version kompiliert zumindest fehlerfrei. In der Tat 
ist das Kompilat aber größer als noch mit der 4.8.1. Das war ja hier 
letztens irgendwo eine Frage. ;)

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Blubb schrieb:
> In der Tat ist das Kompilat aber größer als noch mit der 4.8.1.

das klingt nicht so schön. Hast Du dazu Zahlen?

Autor: Blubb (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für das Beispiel. Ich hatte mal ein ähnliches Problem mit 
dem AVR Butterfly. Wenn ich den Code im Studio erzeugt habe passte er 
nicht rein. Mit WinAVR jedoch schon. Der Unterschied wurde mir damals 
nicht klar.

Seitdem verzichte ich auf das Studio und versuche mein Glück mit WinAVR. 
Da ist noch der GCC 4.3.3 aktiv.

: Bearbeitet durch User
Autor: Blubb (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Hinweise Blubb !

Autor: Blubb (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Matthias W. (matt007)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für den Hinweis Blubb. Ich nehme erst mal noch das alte 
WinAVR. Es ist zu viel anderes zu tun als eine neue Baustelle 
aufzumachen. Das kleine AD-Wandler-Programm läuft auch mit dem WinAVR 
von 2010 noch gut.

Autor: Jörg E. (jackfritt)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>bash.exe: warning: could not find /tmp, please create!

Dann mach doch halt ein scheiss /tmp Verzeichnis.
Wo ist dein Problem?

Autor: Jörg E. (jackfritt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein Problem ist das ich unter SCHEISS Windows arbeite
und dort bringt das nix ;)
Und wo ist dein Problem?

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Esser schrieb:
> Mein Problem ist das ich unter SCHEISS Windows arbeite
> und dort bringt das nix ;)

Sicher, dass ein mkdir C:\tmp das Problem nicht beseitigt?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

: Bearbeitet durch User
Autor: Jörg E. (jackfritt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok dann werde ich mal eine TMP Variable anlegen.
Denn mit einfachem Verzeichnis anlegen ist es natürlich nicht getan.
Zumindest nicht bei mir :)

Autor: Jörg E. (jackfritt)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hmm mein Windows 7 hat aber diese Umgebungsvariablen. Vorschläge?
Bitte 2. Temp.png beachten kann den ersten Anhang leider nicht mehr 
löschen.

: Bearbeitet durch User
Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist alles ein Problem der Bash, nicht von GCC.  Siehe z.B.:

http://cygwin.com/ml/cygwin/2006-12/msg00484.html

Hier half das Setzen der Umgebungsvariablen nebst Reboot:

http://www.avrfreaks.net/comment/73423#comment-73423

Autor: 900ss D. (900ss)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.