Ich hab mal die Toolchain auf Windows neu kompiliert (endlich erfolgreich ^^) Beinhaltet: - AVR GCC Version 4.7.0 (Stand 17. Februar 2012 !!! experimental aber ganz sicher weniger Bugs als die anderen "offiziellen" Toolchains) - Binutils 2.22 - AVR-Libc 1.8.0 - Sprachen: C, C++ Vielleicht kann ja der Ein oder Andere auch davon profitieren. Wer C++ programmieren will, muss im AVR Studio 5 unter Extras->Erweiterungsmanager das AVRGCC C++(Beta) Plugin installieren. Alles andere, wie man installiert usw. und der Link steht hier: http://cve.lan-crew.de/board/viewtopic.php?t=27 Dort kann man sich leider nicht registrieren deswegen Fragen bitte hier stellen :) Stefan
Ich habe versucht diese experimentelle AVR Toolchain mit einem AVR-Studio 4 zu verwenden. Das scheiterte bei mir zunächst daran, dass in diesem Paket kein make vorhanden ist (normalerweise im Ordner bin\). Ich habe dann eine ältere WinAVR Installation kopiert und dann die exp. AVR Toolchain inkl. Ordner in diese Installation reinkopiert (OK, etwas zu viel Brute Force :) Anschließend konnte ich ein "Hello world" ohne Probleme übersetzen.
Krapao schrieb: > Ich habe dann eine ältere WinAVR Installation kopiert und dann die exp. > AVR Toolchain inkl. Ordner in diese Installation reinkopiert (OK, etwas > zu viel Brute Force :) Ja es ist etwas "Brute Force" aber genau so wie du es gemacht hast, ist es gedacht. Ich wollte kein Komplettpaket anbieten, da ich mich mit den anderen Komponenten nicht beschäftigt habe. Es ist also eher als Update zu verstehen. Im Paket ist auch keine size.exe enthalten, sonst sollte es aber relativ komplett sein. Schön das es auch mit WinAVR funktioniert!
Stefan Re schrieb: > Ich hab mal die Toolchain auf Windows neu kompiliert Als Canadian Cross oder nativ unter Windows? > Beinhaltet: > - avr-gcc Version 4.7.0 Hast du die Multilibs für tiny-stack und avr25/tiny-stack drinne? http://savannah.nongnu.org/bugs/?35407 Funktioniert LTO? > - Binutils 2.22 Mit oder ohne relax-bug? http://sourceware.org/PR12161 > Vielleicht kann ja der Ein oder Andere auch davon profitieren. Vor allem könnte avr-gcc selbst davon profitieren, falls gefundene Bugs auch reportet werden. Siehe http://gcc.gnu.org/bugs Bitte Bugs nich mehrfach reporten! Für eine Liste bekannter Bugs siehe Avr-gcc Bugs. Ausserdem interessant: Die GCC Release-Notes http://gcc.gnu.org/gcc-4.7/changes.html
> Hast du die Multilibs für tiny-stack und avr25/tiny-stack drinne? > http://savannah.nongnu.org/bugs/?35407 Das kann ich nachstellen. Es sieht nicht danach aus aus. d:/winavr/bin/../lib/gcc/avr/4.7.0/../../../../avr/bin/ld.exe: cannot find crttn24a.o: No such file or directory Gleicher Fehler wie im Bugreport.
Johann L. schrieb: > Stefan Re schrieb: >> Ich hab mal die Toolchain auf Windows neu kompiliert > > Als Canadian Cross oder nativ unter Windows? nativ unter Windows -MinGW32 > > Hast du die Multilibs für tiny-stack und avr25/tiny-stack drinne? Ich habe dazu geschrieben, dass Tinys nicht supported sind (auf der Download Seite). > Funktioniert LTO? keine Ahnung. Wie gesagt habe ich den Trunk am 17.02 also gestern geladen. > Mit oder ohne relax-bug? Ich habe das Binutils-Sourcepackage am 15.02. geladen. Keine Ahnung ob der Fix da mit drin war. Ich kann ja nachsehen. > Vor allem könnte avr-gcc selbst davon profitieren, falls gefundene > Bugs auch reportet werden. Siehe http://gcc.gnu.org/bugs Ich kann mich darum kümmern, wenn mir jemand Bugs meldet, sie weiterzuleiten. Für das Beheben bin ich vielleicht der falsche Ansprechpartner. Wie wäre es, wenn Du mir sagst, welche Patches ich einfügen soll, und ich mache das und stelle dann hier die aktuelle Version für uns Windows User bereit? Dank Dir haben wir in dem Trunk seit ein paar Tagen den XMega Support. Sonst hätte ich mir die Mühe nie gemacht. Vielen Dank an dieser Stelle.
Stefan Re schrieb: > Johann L. schrieb: >> Stefan Re schrieb: >> >> Hast du die Multilibs für tiny-stack und avr25/tiny-stack drinne? > Ich habe dazu geschrieben, dass Tinys nicht supported sind (auf der > Download Seite). Das hat nichts mit brain-dead Tiny zu tun, sondern daß´-mtiny-stack partielle Multilib-Option ist. ATtiny24A wirz zB supported (ist kein brain-dead). >> Vor allem könnte avr-gcc selbst davon profitieren, falls gefundene >> Bugs auch reportet werden. Siehe http://gcc.gnu.org/bugs > Ich kann mich darum kümmern, wenn mir jemand Bugs meldet, sie > weiterzuleiten. Für das Beheben bin ich vielleicht der falsche > Ansprechpartner. Es geht nicht ums Beheben oder Analysieren, sondern daß Bugs überhaupt berichten werden! Übliche Vorgehensweise bei vielen Anwendern ist nämlich: Bugs nicht zu reporten und statt dessen Hacks auszutüfteln, die sie dann bei jeder Gelegenheit präsentieren und lieber jahrelang über die miesen Tools meckern anstatt wenigstens Bug-Reports zu machen. In einem Bug-Report erwartet niemend eine Analyse oder ein Korrektur oder einen Patch oder was auch immer. Aber wie soll ein Problem behoben werden, wenn es den GCC-Entwicklern nicht bekannt ist? Das Medium dafür ist ein Bug-Report. Die Kritik geht natürlich nicht an dich. Ich finde es prima daß du einen Snapshot erzeugt hast, so daß die Tools breiter getestet werden können. Übrigens vermisse ich avr-size. Wo ist das geblieben?
Ich meinte es in dem Sinne, dass ich zwar die Patches einfügen kann, aber es wär schön wenn mir Jemand mit Ahnung (Du zB) sagt welche Patches ich überhaupt einbauen sollte. Deshalb werde ich mal schauen was es mit dem Relax, LTO und tiny auf sich hat. > Übrigens vermisse ich avr-size. Wo ist das geblieben? Ja die hab ich wie erwähnt weg gelassen, da AVR Studio 5 mit einer modifizierten Variante davon arbeitet. Deren size bekommt von der IDE den command -C mit auf den weg, aber das originale size versteht diesen Command nicht und deshalb arbeitet AVR Studio damit nicht. Ich hab (noch) keine Ahnung was der -C Parameter bewirken soll... Ich gehe aber davon aus, dass sich an size nichts wichtiges geändert hat, weshalb man seine alte Version weiter nutzen kann/soll. Ich bin übrigens selbst gerade einem Bug auf der Spur, im Bereich AVR-C++. Dazu später mehr.
Stefan Re schrieb: > Ja die hab ich wie erwähnt weg gelassen, da AVR Studio 5 mit einer > modifizierten Variante davon arbeitet. Deren size bekommt von der IDE > den command -C mit auf den weg, aber das originale size versteht diesen > Command nicht und deshalb arbeitet AVR Studio damit nicht. > Ich hab (noch) keine Ahnung was der -C Parameter bewirken soll... -C ist das Gleiche wie --format=avr, und erzeugt genau die gewohnte Ausgabe mit den Prozentangaben. Das ist nichts, was mit Studio5 neu dazu gekommen ist. Nachtrag: Einen entsprechenden Patch für binutils 2.19 findest du im WinAVR-Repository.
Mit der avr-size Version von GCC-4.7.0 bekomme ich folgende Meldung: >C:/Program Files (x86)/Atmel/AVR Studio 5.0/AVR ToolChain/bin/avr-size.exe: >invalid option -- C > Usage: C:/Program Files (x86)/Atmel/AVR Studio 5.0/AVR >ToolChain/bin/avr-size.exe [option(s)] [file(s)] > Displays the sizes of sections inside binary files > The options are: > -A|-B --format={sysv|berkeley} Select output style >(default is berkeley) > -o|-d|-x --radix={8|10|16} Display numbers in octal, decimal >or hex > -t --totals Display the total sizes (Berkeley only) > --common Display total size for COM syms > --target=<bfdname> Set the binary file format > @<file> Read options from <file> > -h --help Display this information > -v --version Display the program's version und in der Folge: >make: *** [size] Error 1 mit der avr-size Version aus Atmels Toolchain funktioniert alles. Was mache ich falsch?
Stefan Re schrieb: > Mit der avr-size Version von GCC-4.7.0 bekomme ??? Ich dachte "size" ist Bestandteil der binutils. Stefan Re schrieb: > Was mache ich falsch? Anscheinend ist dieser AVR spezifische Code nicht in den offiziellen binutils-Quellen enthalten, dann musst du eben selber Patchen.
Achja Binutils-2.22 > Anscheinend ist dieser AVR spezifische Code nicht in den offiziellen > binutils-Quellen enthalten, dann musst du eben selber Patchen. Ich vermute einfach mal das sich an avr-size seit binutils-2.19 nix relevantes geändert hat, also werde ich es so beibehalten: avr-size.exe kommt von atmel oder von WinAVR, nicht von mir.
Der "binutils-relax-bug" sowie der "tiny-stack-bug" werden in der nächsten Version behoben sein. Dann werde ich noch die avr-size von Atmel einfügen und eben make. Ebenfalls werde ich die neueste Version von AVR-DUDE einfügen, dank Martin e. C. Beitrag "AVRDUDE für Windows kompilieren - Anleitung !" Dann haben wir schonmal das nötigste für eine "Stand-Alone-Version", außer, es werden noch mehr Wünsche geäußert :)
Stefan Re schrieb: > ... welche Patches ich überhaupt einbauen sollte. > Deshalb werde ich mal schauen was es mit dem Relax, > LTO und tiny auf sich hat. Für die meisten Sachen gibt es keine Patches oder die sind noch in der Testphase/im Review. Meine Windows-Tool hab ich bislang immer unter Linux als Canadian Cross erzeugt, aber damit funktioniert LTO nicht. Irgendein Problem mit Plugin-Callbacks von ld aus und Handling von shared libraries. Weil ich LTO als Canadian Cross nicht zum laufen bekam hab ich LTO für meine Builds deaktiviert und hab's dementsprechend nicht getestet — und andere, die meinen Build antesteten natürlich auch nicht. Dein Build bringt übrigens auch >> lto1.exe: internal compiler error: invalid resolution in the >> resolution file Um die fehlenden Multilibs kann man folgendermassen hacken. Ist '.' die Multilib-Wurzel (je nach Gusto im Build oder Install) dann müssen Objekte (*.o, *.a) kopiert (nicht: verschoben) werden von ./ -> ./tiny-stack ./avr25 -> ./avr25/tiny-stack >> Übrigens vermisse ich avr-size. Wo ist das geblieben? > Ja die hab ich wie erwähnt weg gelassen, da AVR Studio 5 mit einer > modifizierten Variante davon arbeitet. Deren size bekommt von der IDE > den command -C mit auf den weg, aber das originale size versteht diesen > Command nicht und deshalb arbeitet AVR Studio damit nicht. > Ich hab (noch) keine Ahnung was der -C Parameter bewirken soll... Er macht eine %-Angabe der Speichnutzung. -C ist aber ein dermassener Hack, daß das Patch wohl nie den Weg in die offiziellen Tools finden wird.
Das Problem mit den avr-tiny multilibs sowie den Relax-Bug kann ich in meinem Snapshot fixen. Wegen LTO, würde ich deine Meinung gerne wissen, ob ich diesen Fix anwenden kann: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50616#c6 (Comment #6)
Stefan Re schrieb: > Das Problem mit den avr-tiny multilibs sowie den Relax-Bug kann ich in > meinem Snapshot fixen. Der relax-Bug (PR12161) ist in 2.22 gefixt, allerdings gab es seit dem Fix noch eine Release. Also 2.22 branch oder 2.23 HEAD aus dem SVN ziehen. > Wegen LTO, würde ich deine Meinung gerne wissen, ob ich diesen Fix > anwenden kann: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50616#c6 Im PR wird von einem Host-Problem gesprochen, nicht von einem Build-Problem, d.h. Problem ist die Plattform, auf der GCC/LTO laufen, nicht die, auf der sie generiert werden. Ob der vorgeschlagene Fix das Problem behebt und/oder sinnvoll ist, dazu kenne ich mich mit Windows nicht genug aus. Hat dein Build-Compiler (4.6.2 wohl) den Patch integriert?
Johann L. schrieb: > Hat dein Build-Compiler (4.6.2 wohl) den Patch integriert? Wie kann ich das testen?
Stefan Re schrieb: > Johann L. schrieb: >> Hat dein Build-Compiler (4.6.2 wohl) den Patch integriert? > > Wie kann ich das testen? Falls LTO funktioniert sollte zumindest
1 | int main(){return 0;} |
übersetzbar seit mit >> avr-gcc main.c -mmcu=atmega8 -flto -v -save-temps was aber einen ICE wirft: >> lto1.exe: internal compiler error: invalid resolution >> in the resolution file Momentan ist mir auch nicht klar, ob das ein Problem des erzeugten COmpiler ist oder weil Problem des Build-Compilers, bzw. weil die Version des erzeugten Compilers sich von der Version des Build-Compilers unterscheidet bzw. weil der Build-Compiler auf/für ein 32-Bit System erzeugt wurde oder weil du mit einem 64-Bit Compiler einen Compiler für einen 32-Bit Host erzeugen willst, etc. Vielleicht kannst du ja einen Kommentar an PR50616 machen für den Einzeiler von oben mit • C-Quelle von oben • Console-Ausgabe wenn das Programm übersetzt wird wie oben • .res File, evtl. auch .s File • Angabe welche Build-Plattform du verwendest • Ausgabe des Build-Compilers, d.h. wie der 4.6.2 den du einsetzt configuret wurde, h.h. seine Ausgabe mit -v --version Wenn ich mir das .res anschaue dann steht da " (null) " drinne, als Text. Übrigens sind --disable-libada und --disable-libssp überflüssig. Und der empfohlene Weg, GMP, MPFR und MPC zu verwenden ist deren Quelle in die GCC-Source zu klinken: http://gcc.gnu.org/install/download.html Dafür gibt es ./contrib/download_prerequisites http://gcc.gnu.org/viewcvs/trunk/contrib/download_prerequisites?content-type=text%2Fplain&view=co
>>> avr-gcc main.c -mmcu=atmega8 -flto -v -save-temps ruft bei mir keinen Fehler hervor. Die Zeile in der .res Datei sieht so aus: 160 9609bfef PREVAILING_DEF main Es geht ja um den 2. Wert, der ist bei mir korrekt 4Byte groß. Der Bug kommt also wohl auf 32Bit Windows zustande. So wird auch klar warum %llx -> %I64x den Fehler wohl behebt. Wenn ich übrigens meinen Build Compiler(4.6.2) mit der Zeile gcc main.c -flto -v -save-temps füttere, kommt auch kein Fehler zustande. Die Zeile in .res sieht dann so aus: 75 571b6e2a PREVAILING_DEF _main Leider habe ich kein 32-Bit System in Reichweite um weiter zu testen. Weist du von welcher Datei in 50616 die Rede ist, also welche geändert werden soll? > Und der empfohlene Weg, GMP, MPFR und MPC zu verwenden ist > deren Quelle in die GCC-Source zu klinken: > http://gcc.gnu.org/install/download.html Aus mehreren Gründen bin ich den anderen Weg gegangen: * Binutils benötigt (glaube ich) ebenfalls GMP,MPFR,MPC deswegen muss dies vorher bereit stehen (zumindest habe ich binutils auch kompiliert mit --use-gmp=...) * die ./contrib/download_prerequisites Variante liefert GMP 0.8.1 anstatt 0.9 * Das größte Problem bei make (gcc) ist dass es ein Memory Leak in Mingw32 gibt. Ich musste nach jedem make meinen PC neustarten um den RAM freizugeben, da sonst irgendwann vonn make ein Fehler kommt soetwas wie "Error: No Free Memory". Man kann auch nicht nach einem Neustart mit make an der Stelle weiterkompilieren, es kommt dann zu Fehlern. Es muss also in einem Durchgang fehlerfrei funktionieren. Ich habe 6GB Ram und habe make (gcc) direkt nach dem Neustart (1,5 GB RAM benutzt) gestartet und bei Fertigstellung (ca 60 min) waren 5,7GB belegt und das System fast unbenutzbar langsam. Ich kann einfach nur davon abraten, selbst zu versuchen avr-gcc unter mingw32 zu erstellen. Man verzweifelt fast unweigerlich. Canadian Cross stelle ich mir nicht minder komplex vor. Stefan
Stefan Re schrieb: >>>> avr-gcc main.c -mmcu=atmega8 -flto -v -save-temps > ruft bei mir keinen Fehler hervor. > Die Zeile in der .res Datei sieht so aus: > 160 9609bfef PREVAILING_DEF main > Es geht ja um den 2. Wert, der ist bei mir korrekt 4Byte groß. > Der Bug kommt also wohl auf 32Bit Windows zustande. > So wird auch klar warum %llx -> %I64x den Fehler wohl behebt. > > Wenn ich übrigens meinen Build Compiler(4.6.2) mit der Zeile > gcc main.c -flto -v -save-temps > füttere, kommt auch kein Fehler zustande. Die Zeile in .res sieht dann > so aus: > 75 571b6e2a PREVAILING_DEF _main > > Leider habe ich kein 32-Bit System in Reichweite um weiter zu testen. Ja, das 32/64-Systeme Thema ist ein leidiges; vor allem auch was C angeht und wie groß int, long und void* sind. Sieht du eigentlich den ICE von http://gcc.gnu.org/PR52305 ? Ich würd mal schätzen nein, weil die Konstante als const_int dargestellt wird; sichtbar zB mit -S -dP im s-File. > Weist du von welcher Datei in 50616 die Rede ist, also welche geändert > werden soll? Nö, kein Plan in der Ecke von GCC. Muss irgendwo im lto-streamer sein. Ich sehe Kai Tietz im CC des PR, der kennt sich aus mit mingw32 und schreibt vielleicht was. >> Und der empfohlene Weg, GMP, MPFR und MPC zu verwenden ist >> deren Quelle in die GCC-Source zu klinken: >> http://gcc.gnu.org/install/download.html > Aus mehreren Gründen bin ich den anderen Weg gegangen: > * Binutils benötigt (glaube ich) ebenfalls GMP, MPFR, MPC Nö. > * die ./contrib/download_prerequisites Variante liefert GMP 0.8.1 > anstatt 0.9 Ist nicht unbedingt ein Grund. Ich hatte mit neueren Versionen teilweise Probleme (weiß nicht mehr bei welchem Paket). > * Das größte Problem bei make (gcc) ist dass es ein Memory Leak in > Mingw32 gibt. *Autsch* Das ist allerdings übel und ein Grund möglichst wenig zu generieren. > Ich musste nach jedem make meinen PC neustarten um den RAM > freizugeben, da sonst irgendwann vonn make ein Fehler kommt soetwas wie > "Error: No Free Memory". Man kann auch nicht nach einem Neustart mit > make an der Stelle weiterkompilieren, es kommt dann zu Fehlern. Es muss > also in einem Durchgang fehlerfrei funktionieren. Teilweise helfen vielleicht auch sub-targets wie * make all-gcc * make instell-gcc * make all-target-libgcc * make install-target-libgcc * etc. > Ich kann einfach nur davon abraten, selbst zu versuchen avr-gcc unter > mingw32 zu erstellen. Man verzweifelt fast unweigerlich. Ok, danke für den Hinweis; ich dachte schon es wäre eine echte Alternative zu Canadian Cross. > Canadian Cross stelle ich mir nicht minder komplex vor. Easy going; geht genauso wie ein normaler Cross-Compiler. Haken an der Sache ist allersings, daß man einen linux -> mingw32 Cross braucht. Der Cross selbst ist nicht so das große problem aber das ganze Bibliotheksgeraffel und windows.h und die ganze Umgebung muss ja auch da sein. Wirklich aktuell ist mein Build-Cross nicht; es ist ein 3.4.5.
Stefan Re schrieb: >> Übrigens vermisse ich avr-size. Wo ist das geblieben? > Ja die hab ich wie erwähnt weg gelassen, da AVR Studio 5 ... Ah, ok. Du schriebst nur was von eine "size.exe", nix von avr-size. > Ich bin übrigens selbst gerade einem Bug auf der Spur, im Bereich > AVR-C++. Dazu später mehr. Hilft -fno-dse? Stefan Re schrieb: > Dank Dir haben wir in dem Trunk seit ein paar Tagen den XMega Support. > Sonst hätte ich mir die Mühe nie gemacht. Vielen Dank an dieser Stelle. Das ist alles "tentative". Bisher hat der Code noch keine Hardware gesehen und noch nichtmal einen Simulator, denn der hat keine XMega-Support. Oder kennst du einen tauglichen Simulator mit XMega-Unterstützung?
So ich habe die neue Version fertig zusammengestellt. Änderungen: - Binutils 2.23 (fix relax-Bug) - avr-gcc fix für LTO Bug (50616) - @Krapao und gjl - Bitte testen! - enthält avr-size.exe von Atmel (mit Option -C) - enthält den Tiny-Stack fix (bitte auch testen) - AVR-Dude 5.11.1 - enthält make Ich konnte diese Version erfolgreich als Stand-Alone Version mit AVR Studio 5 nutzen, es ist also nicht mehr nötig die alte Toolchain zu überschreiben, sondern kann in einen eigenen Ordner entpackt werden. Wenn man es als WinAVR Ersatz nutzt, muss evtl. die PATH Variable angepasst werden. Der Link aus dem ersten Post führt zum Download - oder hier: http://www.melzer-electronic.de/avr/AVR-Toolchain-2012-02-19.7z Anderes: - Mit dem Simulator hab ich noch nie gearbeitet - da kann ich leider nicht helfen. - Ich werde in den nächsten Tagen die XMega Funktionen auf xmega128A1 testen. - Den ICE von http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52305 sehe ich auch. Genau die gleiche Meldung wie im Ticket.
Der Compiler erzeugt mit meinem aktuellen ca. 16kb großen Projekt mit -Os 4,1% kleinere ELF, mit -O2 1,4% kleiner. Das ist nicht zu vernachlässigen und wie ich finde ein richtig guter Fortschritt. Das Programm läuft einwandfrei auf dem xmega128A1. Ich bin gespannt auf eure Ergebnisse. Stefan
> - enthält den Tiny-Stack fix (bitte auch testen) Das klappt jetzt. Die oben beschriebene Fehlermeldung kommt nicht mehr beim Attiny24a Minimalprogramm. > - enthält make Mit diesem make habe ich_ auf _meinem Rechner Probleme. Innerhalb AVR-Studio 4 wird der Ordner dep in Default nicht angelegt und es kommt eine Fehlermeldung beim Build. http://www.mikrocontroller.net/articles/WinAVR#fatal_error:_opening_dependency_file_.dep.2Fmain.o.d:_No_such_file_or_directory Wenn ich mit identischem Makefile ein anderes make (gleiche Version, andere Dateigröße) benutze, klappt es. Das Problem hatte ich wohl schon bei WinAVR-2010, denn dort hatte ich das make.exe auch schon ersetzt. > - avr-gcc fix für LTO Bug (50616) - @Krapao und gjl - Bitte testen! Das muss ich noch mal prüfen. Beim ersten Test gestern gab es Fheler beim LD, aber nicht den bekannten sondern etwas mit nicht gefundenen Zwischendateien. Ich werde den Test auf einem zweiten Rechner wiederholen. > - Binutils 2.23 (fix relax-Bug) > - enthält avr-size.exe von Atmel (mit Option -C) > - AVR-Dude 5.11.1 Noch Ungetestet. In AVR-Studio 4 fielen mir gestern drei neue Zeilen bei der Ausgabe des GCC-Plugins auf, die ich noch prüfen muss (Parameter-Warnung, Echo-OFF-Ausgabe, Systaxfehler-Warnung).
Hier der LTO Test auf einem XP SP2 32-Bit. Der andere Rechner (mit Windows 98SE, nicht lachen) hat Probleme mit dem Zugriff auf Daten in Temp (ala avr-gcc @C:\DOKUME~1\krapao\LOKALE~1\Temp\ccOFOX5k.args). Möglicherweise ist die @-Schreibweise das Problem.
@Stefan: Wenn dich "wichtige" PRs interessieren kann ich dich
zum CC hinzufügen.
>Mit diesem make habe ich_ auf _meinem Rechner Probleme. Kann mir das im Moment nicht erklären. Ich habe das make aus der AVR-Toolchain (AVR Studio 5) kopiert. Vermutung wäre ein Problem in der MinGW oder Cygwin Library bezüglich der Pfadnamen. Welches make funktioniert bei Dir? >Hier der LTO Test auf einem XP SP2 32-Bit. Super! Außer mit dem Win98, ich schätze der Support dafür ist irgendwo aufgegeben worden. > @Stefan: Wenn dich "wichtige" PRs interessieren kann ich dich zum CC hinzufügen. Das wäre super! Meine Email kannst du der CC-List von hier entnehmen: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52261 In der letzten Version habe ich einen kleinen Fehler gemacht, und zwar die MinGW-DLL nicht in jedes Verzeichnis kopiert welches .exe Dateien enthält. Wenn man seinen /bin Ordner nicht zu PATH hinzufügt kann es dadurch zu Problemen kommen (nicht gefundene Datei libiconv-2.dll) oder bei lto1.exe: Internal error:Segmentation fault. Ich habe hier den Fehler behoben: http://www.melzer-electronic.de/avr/AVR-Toolchain-2012-02-22.7z
Inzwischen hab ich den Simulator gepimpt so daß er xmega-Code verdauen kann. Sieht soweit ganz gut aus.
Stefan Re schrieb: > is das n patch für gcc? Nein, der Simulatur wird unter WinAVR gehostet. > war das der tippo? Nein, der Tippo ermöglichte einen Glitch beim Schreiben von SP.
kriegen wir damit auch den AS5 Simulator zum laufen?
Stefan Re schrieb: > kriegen wir damit auch den AS5 Simulator zum laufen? *hüstel* Was willst du mit dem Klotz? Ohe den je benutzt zu haben würd ich behaupten, daß er für den Zweck absolut untauglich ist.
Bin eben so n Windows Mensch und Visual Studio auch noch dazu :) Hab ihn vorhin mal angetestet und festgestellt dass es im Prinzip so funktioniert wie der Debugger von Visual Studio, geht nur leider auch nich mit dem xmega.
Du hast Atmels AVR-Simulator in der GCC testsuite verwendet??? Nicht wirklich...
Du hattest ja schon vorher angedeutet dass kein Simulator mit dem XMega funktioniert. Aber da ich im Leben noch Keinen getestet habe, wollt ich mir mal einen Überblick verschaffen. Dabei hab ich eben festgestellt, dass es wohl tatsächlich für mich persönlich eine Option wäre den zu benutzen da ich vom Prinzip her die Funktionsweise kenne (durch Visual Studio). Vllt. teste ich auch mal den Simulator, der unter WinAVR gehostet wird. Voraussetzung wäre, der von Dir mit xmega support ausgestattete wäre zugänglich ?
Stefan Re schrieb: > Du hattest ja schon vorher angedeutet dass kein Simulator mit dem XMega > funktioniert. Eher das: Ich kenne keinen für den Zweck taugenden Simulator, der mit xmega funktioniert. Programmierer, die ihre Anwendung im Simulator/Debugger entwickeln, wollen ja eine GUI und bunte blinkende Bits und Bytes, die bei jeder Instruktion die Farbe wechseln; Register-, Speicher- und I/O-Ansichten sowie möglichst genaues Nachbilder der internen I/O. Für den Simluator von oben sind die Ansprüche aber ganz anders: Er muss nativ unter Linux verfügbar sein: GCC unter Windows zu entwickeln ist was für Masochisten; siehe deine Probleme von oben. Er muss von Kommandozeile aus bedienbar sein: Bedienung über GUI ist ein Killer-Kriterium. Denkbar ist auch eine Anbindung über ein GDB-Interface; etwa über TCP/IP. Er muss schnell sein: Es gibt 70000 C-Tests. Wenn alleine das Starten des Simularors 1 Sekunde dauert, hast du schon einen ganzen Tag Totzeit; da ist noch kein Programm compiliert, gelinkt, hochgeladen oder ausgeführt. Und die C++ Tests sind noch nicht mitgezählt. Er muss virtuelle I/O unterstützen: Ein Testprogramm, das printf testet und ein printf("Hallo") enthält, tested ob das Programm eine Ausgabe auf Console macht. stdout auf UART abzubilden und die AVR-I/O simulieren zu lassen bringt hier herzlich wenig: Wenn der Simulator dann nur an einem Port-Pin rumklimpert, hat man ja noch lange keine printf-Ausgabe gemacht gegen welche die Skripte der Testsuite testen können. > Aber da ich im Leben noch Keinen getestet habe, wollt ich mir mal einen > Überblick verschaffen. Dabei hab ich eben festgestellt, dass es wohl > tatsächlich für mich persönlich eine Option wäre den zu benutzen da ich > vom Prinzip her die Funktionsweise kenne (durch Visual Studio). Für's praktische Arbeiten ist avrtest eher weniger geeignet. Es ist ein ISA-Simulator, der nix von I/O weiß, und das ist auch nix, wo sich ein Compiler drum zu kümmern hat. Nett wäre es, wenn ISRs testbar wären, aber momentan hab ich keine schlüssige Idee, wie das abzuwickeln wäre. Durch die virtuelle I/O-Unterstützung kann ich mir so ein Simulator allerdings vorstellen, um Benchmaks zu machen und Profiling-Info zu bekommen. Auf echter Hardware ist es ja nicht so einfach, aussagekräftige Profile-Infos in Echtzeit aus dem Silizium zu bringen. Und natürlich kann man mit dem Simulator ein in Quelle unverändertes Hallo Welt laufen lassen, daß die Ausgabe wie ain PC-Programm auf die Console macht :-) > Vllt. teste ich auch mal den Simulator, der unter WinAVR gehostet wird. > Voraussetzung wäre, der von Dir mit xmega support ausgestattete wäre > zugänglich ? Ja, ist alles schon upstream. Ich hab Schreibrechte. Einfach WinAVR → Code
Hab eben seit längerer Zeit mal wieder eine Windows-Toolchain als Canadian-Cross erzeugt mit Build = i686-pc-linux-gnu Host = i386-pc-mingw32 Target = avr-unknown-none aus GCC und binutils trunk. Damit funktioniert LTO unter Windos (Win2000).
Seit gestern gibt's GCC 4.7.0: http://gcc.gnu.org/ml/gcc/2012-03/msg00347.html Für die Interessierten: Ein avr-gcc 4.7.1 (prerelease) für Windows gibt's hier: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=938043#938043
Hallo zusammen, ich warte schon lange auf diese Release, weil ich gern "Named Address Spaces" verwenden würde, aber irgendwie kennt auch die letzte Compiler-Version kein "__flash". Gibt es da irgend eine Option, die ich angeben muß? Ich benutze avr-gcc unter Eclipse auf Win7.
gcc_user schrieb: > ich warte schon lange auf diese Release, weil ich gern "Named Address > Spaces" verwenden würde, aber irgendwie kennt auch die letzte > Compiler-Version kein "__flash". > Gibt es da irgend eine Option, die ich angeben muß? Das ist kein Standard-C. Hilft -std=gnu99 ?
Johann L. schrieb: > Das ist kein Standard-C. Hilft -std=gnu99 ? Ja, das hilft. Ist aber auch standard, nur eben für den C-Compiler. Da werde ich als C++ Fan noch warten müssen, bis auch der g++ soweit ist. Schade ;-(
gcc_user schrieb: > Da werde ich als C++ Fan noch warten müssen, > bis auch der g++ soweit ist. Keine Ahnung ob was geplant ist für g++. Für Objective-C ist es verfügbar. Im Gegensatz zu C++ ist das eine Obermenge von C :-)
Hallo, ich habe bei mir noch ein AVRStudio 4.19 laufen. Bei verwenden der Toolchain von Stefan Re Stürtzt das Programm beim laden des Simulators/Debugger ab. Musste also wieder auf die letzte WINAvr version. Ist das ein Bugreport Wert oder nicht weiter im Fokus von avr-gcc. MfG Stefan
Absturz beim Aufruf des Simulators ist bei mir gestern auch mit der neuen Version von Johann (4.7.1) aufgetreten. AVR-Studio 4.16 Build 628 (Nicht lachen!)
Stefan D. schrieb: > Bei verwenden der Toolchain von Stefan Re Stürtzt das Programm beim > laden des Simulators/Debugger ab. > > Ist das ein Bugreport Wert oder nicht weiter im Fokus von avr-gcc. Ein Bugreport für GCC ist es dann wert, wenn es ein GCC-Bug ist. Wenn es ein Bug im Simulator/Debugger ist, ist der Bugreport dorthin zu senden. Ein GCC-Bug wäre es z.B. dann, wenn der Compiler falsche Debug-Infos erzeugt, die nicht dem eingestellten Debug-Format entsprechen. Ein Simulator/Debugger Bug wäre es, wenn diese mit den Debug-Infors nicht zurechtkommen, diese überhaupt nicht auswerten und stattdessen z.B. nicht-zutreffende Annahmen über die Anatomie von Funktions-Prologen und die Abfolge der darin enthaltenen Instruktionen machen. 4.7 kann andere Prologe ausgeben als ältere Versionen; gleichwohl werden jedoch nach wie vor dazu passende und dem eingestellten Debug-Format entsprechende Debug-Infos erzeugt. Erst Hinweise könnte es geben, wenn unterschiedliche Debug-Einstellungen verwendet werden wie: -g0 bz. keine -g -gdwarf-2 -gdwarf-2 -gstrict-dwarf -gstabs etc. und Debugger/Simulator unterschiedlich reagieren. Ditto für Minimalprogramme ohne ohne einen Prolog vs. Programm, das nicht-triviale Prologe erfordert. Oder eine Frage an den Atmel-Support zusammen mit einem elf, das den Debugger aus dem Gleis wirft.
Das ist richtig. Aus Zeitmangel (war gestern Nacht) und Scham (über mein Uraltsystem) konnte ich der Sache noch nicht auf den Grund gehen. Im Prinzip war mein Beitrag nur ein "Du bist nicht allein" bzw. "Da könnte was sein, das man beobachten sollte" Feedback.
Hallo Johann, ich habe etwas rungespielt, es klappt auch mit anderen Degub informationen nicht. ich habe aber ein kleine Projekt erstellt, das ging, dann aus einem anderen ein File dazu, wieder abgeschmiert. scheinbar passiert das ab einer gewissen granularität. Gennauer habe ich auch noch nix. MfG Stefan
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.