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
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
Ich glaube das musst du selbst ausprobieren. Soviel passt nich in meinen atiny ;) Gruss, Jörg
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?
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 ;)
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?
Also das Changelog musst du dann schon selber lesen :) Und das mit neuer Software neue Bugs kommen können liegt wohl auf der Hand.
Also, leider war in den heruntergeladenen Archiv kein Changelog... sonst hätte ich natürlich nicht gefragt. :)
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?
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
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
Hallo allerseits! Kann man nicht einfach das aktuelle AvrStudio installieren und sich dann die ganze Compiler-Toolchain aus dieser Installation rauskopieren?
>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
Die toolchains gibt's doch bei Atmel auch einzeln zum Download. Den Umweg übers Studio kann man sich damit sparen. Oliver
>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
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.
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
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?
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!
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...
bla schrieb: > Danke. Irgendwie habe ich immer Pech mit Updates. ;) Naja, so tragisch ist die Warnung ja nun auch nicht.
Was ist denn mit den "mhvavrtools"? die sind doch angetreten WINAVR zu ersetzen.
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...
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
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.
Gibt's eigentlich schon einen Fix für diesen Bug und auch eine entsprechende aktuelle Windows-Toolchain fertig zum Download?
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.
4.8.2? Sicher?? Ich habe den Fehler ja mit der offiziellen 4.8.1 von der Atmel-Seite...
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
Für alle von GCC unterstützten Architekturen, 44 wenn ich mich nicht verzählt hab. Für einen avr-gcc dann:
1 | $PATH-TO-GCC/configure --prefix=$PATH-TO-INSTALL --enable-languages=c,c++ --target=avr --disable-nls |
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
Jaaaa, das wäre super. Diesem Wunsch schließe ich mich an. :D
Was hat 4.9.0 denn tolles, was 4.8.2 nicht hat?
hallo, gibt es schon was neues zum Thema avr gcc 4.9.0 für Windows? hab bis jetzt leider nix finden können.
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...
auch mich interessiert ob es hier etwas Neues gibt. Habe noch immer WinAVR installiert - die alte eben.
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 ;)
Danke Jörg für den Link. Bevor ich das teste schaue ich erst mal daß ich den Fehler in meinem einfachen Beispiel finde.
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. ;)
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?
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.
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
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.
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.
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.
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
>bash.exe: warning: could not find /tmp, please create!
Dann mach doch halt ein scheiss /tmp Verzeichnis.
Wo ist dein Problem?
Mein Problem ist das ich unter SCHEISS Windows arbeite und dort bringt das nix ;) Und wo ist dein Problem?
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?
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
Ok dann werde ich mal eine TMP Variable anlegen. Denn mit einfachem Verzeichnis anlegen ist es natürlich nicht getan. Zumindest nicht bei mir :)
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
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
Angehängte Dateien:
-
AVRGDB.PNG
3,3 KB
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
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.